draft: Staking Credentials token issuance/redemption #1043
Conversation
There was a problem hiding this comment.
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.
| leverage EC [blinded signatures](https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF). | ||
|
|
||
| Additionally, this proposal is extending the `channel_update` message to announce routing fees paid on the | ||
| CLTV duration, therefore allowing compensation of the routing hops for the transport of long-term held |
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
|
||
| To prevent replay usage of slashed forward credentials or previously used forward credentials, the signature should be | ||
| logged by the routing hop in an [accumulator data structure](https://link.springer.com/content/pdf/10.1007/3-540-48285-7_24.pdf), | ||
| allowing efficient test membership. Merkle tree can constitute such accumulator. To limit the growing size of this accumulator, |
There was a problem hiding this comment.
I believe this is a lossy data structure. Does that create issues with false positives or negatives?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
|
||
| In this diagram: | ||
| 1. Caroll settles the HTLC back to Bob with either a success or a failure. | ||
| 2a. If it's a success, Bob sign the blinded backward credentials stored during the previous phase. |
There was a problem hiding this comment.
What happens if upstream nodes along the path corrupt the signed credentials somehow? They are part of the update_fulfill_htlc message, right?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
Nice to have another reason to work on #1044 😉
| 1. Alice discovers Caroll's `routing_policy` gossip. | ||
| 2. Alice fetches an offer from Caroll to pay the `credential_to_liquidity_unit` announced. | ||
| 3. Alice sends a HTLC to Caroll, the onion payload contains unsigned credentials. | ||
| 4. Caroll receives the HTLC, counter-signed the credentials and send them back to Alice by onions. |
There was a problem hiding this comment.
Why are these sent back via a separate onion message and not in the update_fulfill_htlc as described for ongoing signing below?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| allowing efficient test membership. Merkle tree can constitute such accumulator. To limit the growing size of this accumulator, | ||
| all credentials issued can be expired according to a `routing_gossip::credential_expiration_height` field. | ||
|
|
||
| Once Alice receives the countersigned and still blinded backward credentials, she can unblind them and rely on them |
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
Is it necessary to do key rotation at all?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
Sounds like rotation is something for later reconsideration, with node keys currently being static.
| To preserve the confidentiality of the HTLC senders (or payers), the credentials should be anonymized, | ||
| a routing hop should not be able to link between a credential issuance at dissemination and its usage | ||
| at the reception of a HTLC forward request. A cryposystem satisfying those requirements could be to | ||
| leverage EC [blinded signatures](https://sceweb.sce.uhcl.edu/yang/teaching/csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF). |
There was a problem hiding this comment.
Will this be the VOPRF method that is also used for privacy pass?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
Ok. At least good to know that with VOPRF we have one option that seems reasonably well fitting.
There was a problem hiding this comment.
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?"
- 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.
- 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
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| also can offer the traffic shapping tooling for node operators to improve the quality of their inbound HTLC | ||
| across time. | ||
|
|
||
| # Proposed solution |
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
For the simplest version, I'd think that you need one credential per htlc, regardless of amount and cltv.
There was a problem hiding this comment.
This would make up a good section for this document :)
| in the Lightning community, aims to a fair distribution of the HTLC forward risk among all the chain of | ||
| contracts counterparties. While there is a concern this risk distribution doesn't capture well the | ||
| shenanigans of a HTLC forward (e.g offline routing hop, spontaneously congestioned channel), there is a | ||
| major drawback as it introduces a permanent overhead fee for the network participants. |
There was a problem hiding this comment.
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)
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
| communication channels. The credentials acquisition method and cost are defined by the routing | ||
| hops. For this version of the protocol, we propose upfront fees as a credential acquisition | ||
| method. Payment HTLC are sent to the routing hop and credentials are returned back to the sender | ||
| with a onion reply path. The credentials are counter-signed by the issuer to authenticate their |
There was a problem hiding this comment.
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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
There was a problem hiding this comment.
But how this is different from issuing a secret only the issuer and the receiver knows?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
|
||
| ``` | ||
|
|
||
| In this diagram, Alice would like to send a 1 BTC HTLC to Eve. Bob, Caroll, Dave are all intermediary valid |
There was a problem hiding this comment.
nit: eve is usually evil, so i was actually seeking for the attack description somewhere :)
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
Good stuff overall. I kinda feel this document is too in-depth for now, and should be simplified to:
|
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
| shenanigans of a HTLC forward (e.g offline routing hop, spontaneously congestioned channel), there is a | ||
| major drawback as it introduces a permanent overhead fee for the network participants. | ||
|
|
||
| In contract, another type of reputation-based solution can be introduced by formalizing a new assumption |
| acquisition cost and the amount of resources credited in function of said reputation". This assumption is | ||
| in fact analoguous to the one underpining routing scoring algorithms incentiving the routing hops reliability. | ||
| A reputation system attached to the HTLC forward, not only can protect against malicious jamming entity but | ||
| also can offer the traffic shapping tooling for node operators to improve the quality of their inbound HTLC |
|
|
||
| The credentials are wrapped inside the HTLC onion `credentials_payload`. There are two types of credentials: forward/backward. | ||
| The forward credentials are covering the ongoing HTLC forward, they should have been counter-signed by the target routing hop | ||
| during the dissemination phase or a previous HTLC forward/settlement pahse with the same target routing hop. The backward |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
|
I haven't seen much progress on this for the past year, so I'm closing this in favor of #1071. Feel free to re-open once someone actively works on developing such a protocol. |
This comment was marked as abuse.
This comment was marked as abuse.
|
Gotcha, I hadn't seen that this had moved to the civkit organisation! Good to see that you're still working on this. |
This comment was marked as abuse.
This comment was marked as abuse.
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.