draft: Staking Credentials token issuance/redemption

[ariard]

A formalization of a reputation-based scheme to solve channel jamming is proposed. The system relies on "credentials" issued by routing hops and requested to be attached to each HTLC forward request. The "credentials" can be used by a reputation algorithm to reward/punish payment senders and allocate channel liquidity resources efficiently. The "credentials" initial distribution can be boostraped leveraging one-time upfront fees paid toward the routing hops. Afterwards, the "credentials" subsequent distribution can rely on previous HTLC traffic.

See corresponding mailing list thread for more context. There is also a PoC in LDK: https://github.com/lightningdevkit/rust-lightning/pull/1848 (though now code is behind the description)

Feedback very welcome,.This is a really rough sketch aiming to offer a sound reputation-based proposal to be compared against all the jamming mitigations alternatives: upfront fees/unconditional fees/forwarding pass/etc.

This proposal is inspired by IETF's Privacy Pass from original @naumenkogs suggestion.

[naumenkogs]

Good stuff overall. I kinda feel this document is too in-depth for now, and should be simplified to:

1. Focus on the simplest version first.
2. Focus attention on high-level abstract justifications instead of debatable ideas like key rotation

[ariard]

Thanks for the feedback so far. Working on a simplified protocol description: "one credential per HTLC", without the complexity of the onions or accounting for accounting HTLC amount/time.

The main motivation of this "staking"/"reputational" credentials is to save on unconditional fees paid by HTLC senders. They benefit of their past HTLC routing success in term of more credentials allocated to them, and as such minimize the overhead cost of their future HTLC sends, or allow them to lock liquidity for longer periods. From a routing node viewpoint, a 0-risk HTLC forwarding acceptance can be maintained, by requesting strict binding between credentials acquisition cost and channel liquidity routed.

[ariard]

PR has been updated at c9f7b71 with: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html Oldest proposal should be available under history/.

[ariard]

Thanks for the review! Comments should have been fixed at aa8ac0e.

[ariard]

Updated at 36553d1e with only the architecture / issuance / redemption flows documented. Working on a Rust implementation.

As a reminder Staking Credentials is an anonymous user-authentication mechanism based on “proof of scarce assets” challenges (e.g Bitcoin transaction or Lightning invoice, or successful previous redeemed service). The primary goal is to use those anti-DoS tokens to mitigate channel jamming though additional use-cases could be to protect LSPs service APIs.

Moving forward, I think I’ll split the documentation in many components:

• the token issuance / redemption flows as BOLT recommendations or extensions
• the blinding cryptography as BIPs
• the communication channels as BOLTs or NIPs (e.g tokens-over-websocket)

For reference, the Privacy Pass documentation (architecture, key discovery, rate-limitation, architecture) is available here: https://datatracker.ietf.org/wg/privacypass/documents/ I’ll look if some IETF draft can be reused as it is in the Bitcoin context, or if we have to submit modifications for the Bitcoin context.

There is a goal for the anti-DoS tokens issuance mechanism to be compatible with reputation algorithms as laid out in #1071, when counterparty / users reputation is substituted for proof of scarce assets, for economic efficiency.

[ariard]

There is a working v0.0.1ish proof-of-concept of the Staking Credentials implemented here: https://github.com/civkit/civkit-node All the p2p msgs staking credentials code is implemented as a separate rust library to be re-used in Lightning and other Bitcoin systems. Next step will be probably to add the blinding crypto itself.