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: lightningdevkit/rust-lightning#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.

[joostjager]

Thanks for making a start here with anti-jamming changes!

The paper linked in your rust-lightning pr about privacy pass I also found useful for background info.

[joostjager]

Hold invoice may have a longer cltv, but I don't think that that is a suitable way to recognize and pay for them. Also quick-resolving htlcs on longer routes may have high cltv deltas. What makes hold invoices costly is their actual hold time.

[ariard]

I think effectively we don't have a suitable, "quantifiable" way to dissociate between short-term held HTLCs and long-term held HTLCs, other than an arbitrary protocol/implementation-defined value. On the LDK-side, we reject a any outgoing HTLC with a CLTV superior to 2016 blocks from our tip. I don't think it's even opportune to introduce a "discrete" approach but rather design an anti-jamming solution covering both "continuously".

Making the HTLC upfront fees/reputation cost actually paid on the "actual hold time" would be more valuable. A HTLC sender would only have to cover cost for effective duration, not worst-case CLTV scenario. I think this could be possible if update_fulfill_htlc paid back routing fee scaled on a new fee_base_block to encompass the time dimension.

[joostjager]

Yes, or in the credentials case let the routing node sign a number of credentials that varies based on the actual hold time? If the sender causes a lot of holding, they will keep sending out more credentials than they get back, bringing their credentials balance down. The onion payload is limited in size though, so it seems that it can't be very granular.

[ariard]

If you assume there is a satoshi-cost behind each credential unit, I think you should scale the quantity of credentials requested on the outbound CLTV duration as expressed in the Script during the forward phase. There is no a priori knowledge of the HTLC actual hold time.

Then at settlement, if the observed actual hold time is above some average/median, the routing node can return less credentials, leading the sender to pre-pay for more credentials if it would like to keep doing a lot of holding.

I think this alternative also work, rather than paying routing fee scaled on the time dimension, however I think this more risky for the routing node, as the actual holding time of a HTLC might be far above your median. Requesting credentials to cover the worst-scenario is zero-risk for the routing node, at the trade-off of more expensive for the HTLC senders.

About the granularity, if the onion communication channel are detached from the payment paths, you could send multiple onions, overreaching beyond the 32kb limit. The granularity wished between msat/sat and credentials is a good question.

[joostjager]

Yes, the difference in hold time between a regular payment and a hold payment is massive. Hard to bridge that gap using credentials without requiring more trust.

Routing fee scaling on a time dimension - I think it only works for the success case? Seems we also need something for the slow-failed case.

[ariard]

For the slow-failed case, under the credentials paradigm, a routing node would have to scale the quantity of credentials requested to accept the HTLC forward. E.g, if the HTLC sender requests a 2-month outgoing CLTV, a routing node policy should be to have previously satisfied enough 4*2016 block period (2016 max standard allowed outgoing CLTV). The HTLC sender should have either "harvest" the credentials from previous satisfied routing success, or pre-paid 4 block period.

[joostjager]

I believe this is a lossy data structure. Does that create issues with false positives or negatives?

[ariard]

I think this is correct, if we don't make the merkle branch to the root deterministic on the signature itself. E.g the X first bit of the signature could give you the left-right of merkle path from the root to the leaf. More efficient accumulators, with less studied assumptions, could be used as it can be upgraded in a non-coordinated fashion, this is purely internally to the node.

[joostjager]

This is indeed probably something that can be solved in the implementation phase. With the expiry, the set cannot grow indefinitely. Is that expiry actually encoded inside the 32 byte credential?

[ariard]

See the new gossip in BOLT7 routing_policy with the field credential_expiration_height. Encoding directly the height in the credentials could be a correlation vector, I believe. Failure to respect its own routing policy by a hop should be likely penalized by routing algorithms.

[joostjager]

So credential_expiration_height is a delta height that both sender and router use to expire tokens? Can the router do this when it gets presented the unblinded token, or how does the router know when the token was produced?

[ariard]

Yes, both the sender and the router should consider the credentials as expired once the credential_expiration_height is reached. Without assigning signing key per expiration period, I don't think there is a way for the router to dissociate credentials across expiration periods. However, rotating signing key might be undesirable as raised in another comment. Another direction could be to request the senders to "tag" all the credentials starting within said expiration period. For global visibility, the tag should be part of the routing_policy (without introducing traffic correlation).

For now, I think the only clear rational to introduce a credential_expiration_height is effectively to bound the anti-replay accumulator size. Though key rotation, upgrading the credential format, or updating core fields of the routing policy could be justification. Sounds more for later consideration.

[joostjager]

Can the router still verify the tag after unblinding? I'd think it has become unreadable for the router when it is presented as a forward credential?

[ariard]

The HTLC sender generates a credentials, concatenate the current tag for the period, blind and send it to the routing hop for signature. The counter-signed blinded credential is sent back to the HTLC sender, which can unblind both the credential/signature. I think the tag should still bind.

[joostjager]

What happens if upstream nodes along the path corrupt the signed credentials somehow? They are part of the update_fulfill_htlc message, right?

[ariard]

Yes I think the description should be fixed, the signed credentials should be wrapped into an onion. The onion can be attached to the update_fulfill_htlc or they could send back with a reply_path as the onion message proposal introduces. This reply_path could have been exchanged during the dissemination phase. I still have to catchup with the latest state of onion messages to see what works the best.

[joostjager]

Attached to update_fulfill_htlc as an onion, I'd think that nodes can still delete it? And stand-alone onion messages may not arrive either. If there is a way to somehow atomically deliver upstream together with the preimage, that seems to be better. Or use something like #1044 so that the sender can penalize the node that deleted the in-flight credentials.

[ariard]

That's a good point, stand-alone onion messages are not reliable. I think effectively you would like the credentials to be part of the hmac chain as proposed by #1044 and the sender should be able to detect tampering. Especially, if the credentials have a satoshi-cost, you open the way to damage by intermediary nodes.

[joostjager]

Nice to have another reason to work on #1044 😉

[joostjager]

Why are these sent back via a separate onion message and not in the update_fulfill_htlc as described for ongoing signing below?

[ariard]

The quantity of signed credentials, and as such the size of the wrapping onion, could be a leak of Alice expected future usage of the payment paths. Therefore, dissociating the backward communication channel from the payment routing hops could improve privacy. The signed credentials could be fan-out in multiple 32k-byte onions.

[naumenkogs]

Another option is to make the payload same size for any number of creds somehow... Maybe a static big payload (part of which could be empty), or some fancy compressed data structure with the size independent from the number of creds.

[ariard]

I think there is two constraint here, the bandwidth consumption if we use the max onion payload size, whatever the number of credentials delivered. Another constraint, the information efficiency of the credentials. Introducing multiple ranges of credentials could be a correlation traffic vector.

[joostjager]

Would it be possible for routing nodes to sign with different keys to do some traffic correlation? Or can Alice just verify the signatures and ensure herself that they are all signed with the routing node key?

[ariard]

I think this is a really good point and Alice should verify the signatures are all signed with the known routing node key. In the current PoC implem, the credential key is not tied to the node one though indeed to avoid this correlation issue this should. The key rotation should be visible by the HTLC sender.

[joostjager]

Is it necessary to do key rotation at all?

[ariard]

That's a good question, I prefer to say yes e.g if you would like to refresh the shares of your musig2 aggregated key. Note, I don't think we have a protocol-mechanism to inherit a LN node_id pubkey to a new one, with all its known channel_announcements and as such conserve the reputation staked in routing algorithms.

[joostjager]

Sounds like rotation is something for later reconsideration, with node keys currently being static.

[joostjager]

Will this be the VOPRF method that is also used for privacy pass?

[ariard]

See the answer on this ML post: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003756.html

For now, just thinking unlinkability between the blinded credentials and unblinded ones/signatures. In function of if we would like to have secondary transfers of the credentials, or the sender committing to the credentials, we study more advanced cryptosystem. From a UX viewpoint, it might be good to defer the credentials harvesting to the LSPs.

[joostjager]

Ok. At least good to know that with VOPRF we have one option that seems reasonably well fitting.

[naumenkogs]

I see how it can be easily done when credentials are mixed among a set of users (maybe private mixing is hard, but probably not — it's like Tor 2.0 stuff).
But this would be unfortunate, it likely converges to CoinJoin anonymity set stuff, which, again, relies on reputation... Seems like a recursive problem, but maybe I'm missing the fact that we can solve both at the same time somehow?

Now, fancier schemes, I still don't have a good sense of how they should be applied to our problem.
When I think about this, my first question is "what if there was only one client who received the credential, is there a way to protect them?"

1. This is probably solvable either with mixing (see above), or a trusted third party server (like a mix coordinator, but more flexible — and hopefully provably private towards everything) like a watchtower.
2. Maybe this is fine — we assume privacy only if a routing node served 100 clients a day or something. Then, maybe some minimal technology would be sufficient to help those 100 to make sure they get mixed among each other. Possibly something a routing node publishes every day, or maybe even something about burning the collateral of a routing node if cheating happens :P

[ariard]

If the credentials do not bind to the sender key material, it should be pretty flexible to have them exchanged in a secondary-market, or even harvested by a LSP.

I think this is a good point, if the credentials do not bind to the sender key material, or any secret with strict cost to share, they can be exchanged in a cleartext secondary-market. However a cleartext secondary-market would allow the initial credential issuer to collude with the routing hop to deanonymize the "second-hand" HTLC senders. Therefore, if credential transfer is allowed, they should be exchanged in a privacy-anonymizing way mixnet-style. I think this is good to be aware of but a subject for future considerations.

[joostjager]

I think it may be useful too - if only as a thought experiment - to envision the simplest possible version of the scheme. So maybe just a single credential per htlc, no introduction of liquidity units and avoiding the use of onion messages?

[ariard]

I think this is a good point, to work out the simplest possible version of the scheme.

A single credential per HTLC with a fixed cost-to-liquidity (10 sat of pre-paid for 1 BTC of liquidity for 2016 blocks). I wonder if in fact you really need liquidity unit if we can have global agreement on the credential granularity-level.

[joostjager]

For the simplest version, I'd think that you need one credential per htlc, regardless of amount and cltv.

[naumenkogs]

This would make up a good section for this document :)

[fiatjaf]

From what I understand these reputation tokens are being sent as a form of upfront/unconditional monetary payment from the sender to each node in a route. Is this right?

Considering that, aside from these concerns you cite here, is there anything that makes paying these upfront fees with sats inherently harder or worse than paying with reputation tokens?

For example, in a route A->B->C->D is there something that prevents A from sending some extra msats unconditionally to B and C?

(I couldn't find anything that makes that a no-go on https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md)

[ariard]

This is correct these reputation tokens are sent as a form of upfront/unconditional monetary payments. As noted on the mailing list, they might in fact belong more to the upfront/unconditional family of schemes rather than "pure reputation".

The major difference, minimizing the permanent overhead fee, is to stake the credentials across the HTLC sends. In the optimistic case (no HTLC failure), you only pay for few credentials once, then you should get more of them as your HTLC sends succeed, rather than spending a small upfront fee each time.

There is nothing that prevents A from sending extra msats unconditionally to B and C. The reason of the dissemination phase is for privacy reasons, otherwise you're disclosing to the routing hop this is the first time you're requesting a HTLC forward.

[joostjager]

In a way, things look simpler without a dissemination phase. For each hop you either attach a valid token, or pay an unconditional upfront fee. Either way, you'll get a new free token back for the next payment attempt - assuming no misbehavior.

On the other hand this does require different changes to allow these unconditional fees.

[joostjager]

All though yes, this is probably the same as always requiring an upfront fee and lowering the routing fee slightly. In both cases, you pay a little bit for a failure and more for a success.

In that regard it is different from privacy pass. In lightning we are going to pay anyway for a success, so instead of returning a token it could just as well be a discount on the success fee to cover the next payment's upfront fee. Of course that discount won't be explicit, there's just a routing fee. With privacy pass, there is no payment for the success case. The website is opened for free.

[ariard]

The main motivation of introducing "reputational" credentials is to stake/accumulate them across time, therefore making your future HTLC sends cheaper, optismistically without introducing traffic correlation between your HTLC forward requests. Instead of using a credential, a discount in function of actual hold time could be applied on the success fee to cover next payment's upfront fee, though I think you're limited to accumulate discounts across a period. For long-term held payments, this is an issue as the upfront fees should probably scale up to cover the corresponding routing hop risk.

There is also another advantage of introducing credentials, if they can be transferred, a LSP could pay for the upfront fees/unconditional fees of its spokes, therefore covering the jamming risk they represent for routing hops in the network.

[naumenkogs]

The credentials are counter-signed by the issuer to authenticate their origin.

First I thought that a secret (without a signature) should be sufficient. But then I realized, because of onions, you get a signature "for free", right?

[ariard]

The rational of the signature, it allows credentials authentication by the routing hop, otherwise one is free to forge credential to cover HTLC routing requests. The signature means "This credential has been endorsed by myself during a previous round in its blinded version". I can see how using the phrasing "authenticate their origin" is confusing, should say more to endorse their "endorsement".

[naumenkogs]

But how this is different from issuing a secret only the issuer and the receiver knows?

[ariard]

I understand, if the issuer can map the secret to a given receiver, you loss privacy of the credentials. Blinded signature is a simple scheme providing unlinkability. We might have other cryptosystems to consider.

[naumenkogs]

nit: eve is usually evil, so i was actually seeking for the attack description somewhere :)

[ariard]

Run out of my stack of English names starting by E. Eliot, Ethan, Eric, yeah...okay.

[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/.

[saubyk]

nit: do you mean 'In contrast'?

[saubyk]

nit: traffic shaping tool

[saubyk]

nit: HTLC forward/settlement phase

[ariard]

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

[ariard]

Updated at 36553d1 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.