L402: implement more DoS protection mechanisms

[guggero]

At its inception, the L402 protocol was mainly designed with three use cases in mind:

1. Allow servers to directly charge their users per request, making it possible to monetize content or APIs.
2. Provide a form of DoS protection for applications: Attackers need to be able to pay an LN invoice before their requests can get through to the backend application (requiring time and monetary value to be invested, making an attack more expensive).
3. Pseudonymous identification: Returning visitors to a web service can be identified by their L402 token ID (which is drawn at random when the token is created), without needing any other identification information (e.g. no e-mail, name or other data required).

Using L402 as a DoS protection mechanism works and has the desired effect.
But it can also lead to an onboarding problem: If a service that is intended to help users onboard to the Lightning Network (e.g. buying a first Lightning Channel from Lightning Pool) requires the user to be able to pay an LN invoice first, that creates a circular dependency.

It would therefore be good if the L402 protocol could allow different (potentially tiered) mechanisms alongside LN invoices.

Potential additional PoW mechanisms

UTXO ownership proof

This mechanism is currently implemented in tapd for its authenticated mailbox server.
A user needs to prove they have created an on-chain P2TR output (revealing the Taproot internal key and merkle root to prove they know the internals of that output). Such an output is single-use, meaning an on-chain output can only be claimed once.

This mechanism could be useful for users (or their wallet software) that already have on-chain funds but require access to LN onboarding services that are protected by a L402 proxy.

Generic Proof-of-work

Access to less critical API endpoints could simply be put behind a Proof-of-work barrier. Meaning a client would need to invest a certain (configurable, potentially dynamic) amount of work before an endpoint can be accessed.
This would make attacking that endpoint merely CPU intensive but wouldn't require an attacker to also invest monetary value.
Therefore this mechanism should only be used for API endpoints that aren't computationally expensive on the server side, otherwise an attack might still be a beneficial tradeoff as seen by a potential attacker.

The design of the difficulty configuration and re-targeting of the required Proof-of-work could be re-used from existing solutions such as Bitmessage: https://wiki.bitmessage.org/index.php/Protocol_specification

Proposed implementation

The current L402 protocol specification currently specifies two fields in its WWW-Authenticate response header:

WWW-Authenticate: L402 macaroon="...", invoice="..."

The new fields could simply be:

WWW-Authenticate: L402 macaroon="...", utxo-proof="<mechanism specific parameters>"

or

WWW-Authenticate: L402 macaroon="...",  pow="<mechanism specific parameters>"

respectively.

If multiple of the possible fields are returned (e.g. macaroon="...", invoice="...", utxo-proof="...") it means the user can choose what mechanism to use.
The server can still decide to treat the macaroon differently depending on what mechanism was used.

The client software is expected to add a caveat to the macaroon once the UTXO proof or Proof-of-work has been created.

The response would then only contain the macaroon, as the caveat would be the main transportation mechanism for the actual proof.

For example, the UTXO proof caveat could looks something like this:

utxo-proof <block-hash>:<tx_index>:<outpoint>:<taproot_internal_key>[:<taproot_merkle_root>]

Or, using the macaroon's unique ID (the LSAT token ID) as the challenge and the PoW specific target parameters from the L402 response, the hash that satisfies the PoW could be added with:

pow <pow_params>:<hash>

Configuration in aperture

Today, each configured backend service in aperture as an auth field, that allows to turn L402 on or off.
In addition to that field, a new field could be added that allows specifying a comma-separated list of allowed auth methods.