Solving Lightning Jamming and beyond with Staking Credentials: a Protocol Walkthrough

Summary:

A proposed solution to mitigate jamming attacks over the Lightning Network involves introducing credentials that must be acquired by HTLC senders to lock each hop liquidity along the forwarding path. These credentials can be privacy-preserving to mask the identity of the HTLC senders towards the routing hops and serve as a monetary hedge in case of default of the HTLC sender on the payment of the routing fees. The framework, called "Staking Credentials," can also be deployed to mitigate other liquidity timevalue DoS in the Lightning landscape and can act as an enhanced paywall to access Nostr relay services. The protocol relies on basic mechanisms of the Lightning Network such as onion messages, blinded paths, and gossips, which are information dissemination protocols not relying on third parties. New abstractions are introduced, including credentials, scarce assets, requester/issuer entities, and client/provider entities. The protocol phases begin with the discovery of the `credentials_policy` and `service_policy` gossips originating from issuers and providers, respectively. A requester commits a scarce asset as announced by the issuer's `credentials_policy`, attaches the scarce asset proof with a set of blinded credentials, finds an onion path to the issuer, and sends the whole inside an onion message. The issuer verifies the proof, countersigns the blinded credentials, and sends the signatures back to the requester using a blinded path. The requester receives the issuer's signature and unblinds the credentials, which can then be consumed for the satisfaction of a service or correct the transactional asymmetries of a Bitcoin financial contract. The user in the role of the client forwards the unblinded credentials and the corresponding issuer signatures to a target service provider, and the provider satisfies the client's service request and provides back authentication signatures for a new set of blinded credentials. An example is provided for Lightning jamming, where Alice, the routing hop, cumulates both the role of issuer and provider. Bob the HTLC sender discovers Alice's `credentials_policy`, sends a Lightning payment to Alice, collects signed blinded credentials during an issuance dance with Alice, builds a payment path going through Alice where her hop's onion payload includes an identifier Z, and transfers the signed unblinded credentials with the same identifier Z through onion routing to Alice node. Upsides of the protocol include allowing a service provider to establish a dynamic risk-management policy, preserving the privacy of the HTLC senders, enabling an emergent discount effect in case of "honest" behavior of the client in the usage of the service, being generic enough to adapt to multiple Bitcoin flows beyond HTLC forwarding and the Lightning jamming issue, and having a Rust implementation in early progress.

Updated on: 2023-06-01T19:21:51.217586+00:00