Hi Clara,
> * They will likely require a network wide upgrade: when a sender > makes a payment, the full path will need to understand the new > feature bit for it to be used. I believe the upgradeability dimension is different both for circuit breaker and staking credentials -- Circuit breaker is a point-level deployment and can be rolled out without cooperation of the channel peers. Staking credentials is end-to-end and just requires cooperation between endpoints (HTLC senders and routing hops, not even all on the payment paths). And I think upfront fees is a link-level one, probably the one requesting the most cooperation between the community of developers/node operators. Point-to-point/end-to-end deployment already provides benefits with "half-state" deployment, I think. However, you might have "holistic" beneficial effects of link-level solutions (in terms of economic engineering not in terms of software compatibility), I don't know. > * Sending nodes are unlikely to be incentivised to upgrade to > support a channel jamming mitigation, as jamming mitigations incur > additional cost (be it in the form of upfront fees, tokens or some > other mechanism). As with any "unpatched" security risks we're encumbering on Lightning (pinnings, time-dilation, etc), beyond clearly describing the attack in reference documents and proof-of-concept of the attack against implementations, the next step to keep raising awareness is a live demo as much near as one can from really mainet conditions. While we were patching CVE-2021-41591 and friends, I've been testing the solidity of the fixes on the Eclair-side in a "black-box" manner. Always worth it, you learn on the attack bounds. We could do the same with jamming attacks, as there is a wide-range of scenarios to consider (network-wide/merchant/routing hops) and few optimizations tricks like looping. Just have to be super careful with any demo exploits toolchain, there is always a question of ethics here. > * Routing nodes have no way of knowing whether a payment comes from > a node that is not upgraded, or simply doesn't want to pay the > additional cost introduced by a jamming mitigation. I think a routing node able to know if the payment sender has upgraded could constitute a version/implementation fingerprint and a downgrade in HTLC traffic privacy, ideally a routing node should not be able to link payeer/payee. If a sender does not want to pay the jamming mitigation cost, it might be a flaw in the incentive-compatibility benefit of a mitigation. (And in terms of evaluating the incentives-compatibility/economic-efficiency of any solution, we're going to run quickly in hard questions of economic methodology, a bit beyond the software engineering realm). > It was generally agreed that the network is still in an early enough > stage that it is fair for relaying nodes to initially upgrade but not > enforce the feature, and later look at forwarding traffic to determine > whether it is appropriate to require the feature. If we look at the recent history of mempool policy upgrades on the Bitcoin Core-side, I think it's best practice to be more conservative in terms of "smooth feature" deployment, even feature-gated beyond some node operator setting. At time of feature enforcement, some node operators might claim an established claim on other flows of HTLC traffic, and there would be a question of backward-compatibility arising. Independently, there is the fact on how discrepancies in feature activation could be exploited (privacy-wise or economically-wise). Same issue we have on the Bitcoin Core-side, when we update the mempool policy, and old nodes might not see new types of outputs (e.g Taproot spends being non-standard before the activation iirc). > This will require sending nodes to opt-in to the new feature before the network can > widely enforce it, as no rational routing node will require a feature > which would reduce its ability to serve un-upgraded traffic (unless > under attack, which is not the case at present). I think the corollary holds -- A rational routing node will not require a feature which would reduce its ability to serve upgraded traffic. Note, I think the "rational" routing node could be better defined, otherwise I think we'll run quickly in the same bottlenecked discussions about "policy rules" compatible with miners incentives, as we're seeing on the Core-side. So far, I don't think we have a consistent model of miners incentives. > A note was also made that wallets tend to upgrade less frequently, in > part because some providers run forked versions of LN implementations, > so this horizon may be quite long. It was emphasized that this type of > network upgrade would require input from wallets, designers and > application developers anyway, so hopefully by the time we look to > deploy a change there is rough consensus among the Lightning community > already. Yeah, we have the same issues with transaction-relay/mempool policy or even the non-really specified addr-relay strategy of Bitcoin Core, when there is an upgrade there. It sounds to me there are no well-maintained public and open communication channels where protocol developers can reach out to wallet softwares vendors for protocol upgrades feedback (and vice-versa). I don't know if it's one goal of the LSP spec effort. If you're building a wallet, you're probably going to assemble and maintain components from the two layers. > * Nodes can advertise custom upfront fee rates if desired, but to > save gossip bandwidth we assume a network-wide default of 1%. I think you will have an additional issue here. The routing convergence delay network-wide might be a bottleneck in how much fee rate variances you have flexibility as a routing node operator. Routing convergence delays have been studied in the past at 2,500 seconds for the worst-audience, I don't think it's going to hold with network graph growth. > * Upfront fees accumulate along the route (as htlc payment amounts > do), and are simply pushed to the `to_remote` balance on > `update_add_htlc`. I wonder if there is a concern of an "upfront fee" extraction issue at the channel-level. You have Alice and you have Bob, Bob circular loop to accumulate max `upfront_fee` on his `to_remote` balance on Alice's commitment transaction. Then provoke a force-close by Alice to have her paying the on-chain fees in the post-anchor output model. There can be an interesting "upfront fees" siphoning issue here. > The interaction between upfront fees and possible future protocol > changes such as inbound fees and negative fees was briefly discussed, > specifically the case where a node sets low (or negative) fees to > attract traffic then fails payments to accumulate upfront fees. As is, > all implementations’ algorithms optimize for factors other than fees - > specifically avoiding a node once it's produced failures - and we > suspect that careful sender-side behavior will mitigate this risk. > However, it was also acknowledged that a node that attempts this attack > may be able to fool multiple individual senders and still be able to > accumulate some fees. Correcting upfront fees abuses sounds simple as long as you assume the scoring is done by the endpoint. When you start to have gossip and routing scoring delegation, you might be hijacked by an "accumulating fees" adversary. E.g, one could sybil the rapid-gossip-sync servers, if their deployment becomes ubiquitous [1]. Same issue with Electrum servers lack of incentives alignment. > However, Bob has no real incentive to forward the HTLC to Carol and > push her the 4100 msat because that value is more than the fees he'll > earn from successfully forwarding and settling the HTLC (10 msat > upfront fees + 1000 msat success case fees). It's worth noting that > this type of fee differential already exists in the network today - I > got these example numbers by looking at the fee rates of the Loop > node's peers [4]. Yes, "fee differential" issues have been discussed affecting upfront fees and all the hold fees variants in the past. I'm not sure they're acceptable fee risks, if you can exploit them by setting correctly the channel topologies around a victim routing hop. > * Whether we should look into a more complicated approach that > includes a "proof of forward" secret in the next node's onion which > must be supplied to claim the upfront fee. One of the hard things with a "proof of forward" is a hop colluding with the next counterparty in way non-provable to the HTLC sender. I don't think more reliable onion errors will save the mechanism, as you might always masquerade your routing node offliness (sure -- it might be penalized by routing algorithms still probably a period of grace exploitable) > * Whether Bob _would_ steal the upfront fee by dropping the payment, > as it'll impact nodes' desire to route through them in future. And if you have "floating" upfront fees to adjust to routing node opportunity cost and the routing algorithms historical buckets are not correcting the variations, a "upfront fee" adversary might be able to steal the amount, in a proportion not corrected by the penalty. > * Is there a way to deliver upfront fees to nodes along the route > *without* them adding up along the route (other than the naive > version of sending each hop a payment, which comes with its own > problems)? Seems not, but bright ideas are wanted and welcome! I think the latest update of the Staking Credentials could answer such description of "delivering the upfront fees to nodes along the route *without* them adding up along the route" as the credential issuance is separated from its redemption. On a few other ideas, "magically" teleporting the fee payment to the routing hops, it has been browsed in the past [2]. > * That nodes will decide where they fall in the trade-off of setting > upfront fees to cover their opportunity cost for high routing fees > and market pressure to keep these fees low for the sake of > remaining competitive. They will probably need to do real-time monitoring of the congestion rates and outcome results of their HTLC forwarding to adjust in consequence their routing fees. > * A taproot tree for all HTLCs where each leaf has a subset of HTLCs, > and fees could be incorporated here (summary note: apparently some > work has been done here, but I couldn't find the link). The idea of summing up the taproot tree for all HTLCs is discussed here with past references [3]. I don't know if it's really a viable direction, as aggregating the claim of HTLCs of different values in the same witness claims might open the door to transaction-relay games. > * If we're confident that a more complicated solution will solve many > problems, then we should pursue them, otherwise a simple solution > is possibly a _good enough_ first step. If the "proof of forward" can be solved by "magic" covenant is still an open issue. I don't know if it's a viable solution as it's more a hard synchronicity issue between chain of contracts. However from exploring issue we might learn interesting design considerations for contracting protocols (at the very least some semi-formal proof it's not possible) > * Should our first attempt at solving this issue be for a future > steady state where nodes have significant traffic and nodes face > real opportunity cost (in the form of lost revenue) if they are > targeted by a jamming attack? Deferring the most economically-efficient solution we can come from, we might run into a bunch of incentives-misallignment between generation of nodes operators and Lightning use-cases. Maybe same as we have seen with lack of transaction replacement, first-seen RBF, opt-in RBF, mempoolfullrbf, I believe. On the other-side, the deployment of a simple solution would enable us to start to build a consistent model of how the economics of channel congestion, that we can "transpose" for more advanced solutions (ideally -- all other things being equal). > * While circuit breaker isn't necessarily *the* solution to solving > jamming on LN, it provides us with some data points and a > practical way for individual operators to address spamming of > their nodes. As mentioned above, it sounds like the congestion monitoring and HTLCs resolution tracking is going to be a standard task among LN implementations, and that you'll would probably need a piece of infrastructure like circuit breaker for all implementations. > Since our last discussion an architecture document was added to the > proposal [6], details in the mailing list post [7]. The main goal is > to try to dissociate the people paying the fees from those gaining the > benefits from the credentials, so that credentials can be paid by a > LSP (for example). I think there is a missing footnote, I believe the mail thread might have been this one: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003822.html Beyond delegation as mentioned, there are few other design goals targeted: - strong economic-efficiency due to credentials accumulation - fungibility of their credentials between their issuance and redemption - dynamic-management of liquidity risks - contract-agnostic (e.g can cover dual-opening) Probably, we'll have the credential issuance flow and extension gossip more speced out before next meetings. > 4. Reputation discussions in LSP Specification > Some attendees have been working on a reputation system for the LSP > specification group [8]. This system is intended to provide standard > metrics about what makes a node good/bad to connect to in the context > of a decentralized marketplace. While this work looks at the problem > from a different perspective, there's a possibility to consolidate > the efforts. It seems particularly useful in the anti-jamming case > where a node has newly connected to you, and needs a "start state" > reputation score. The idea of defining what qualifies as good > behavior in the Lightning Network is useful across the board. The > LSP specification group also has bi-weekly calls, and welcomes > additional participants! Effectively, I think distributed market infrastructure design could benefit from the lessons of the Lightning Network. It could be fruitful for the LSP specification group to have its own mailing list at some point in the future. > There's a lot to discuss - brave readers who made it all the way to > the bottom of this email will notice a fair number of question marks > scattered about - and we're going to continue to break the problem > down into smaller parts to discuss in the hope of making progress. Beyond archiving well the problem space, there is also an effort of documenting well any protocol design decisions to preserve future evolvability and achieve interoperability between implementations. > Any change to the Lightning Network that aims to address channel > jamming attacks will be a significant (but necessary) change to the > protocol For sure, this is a significant change to the protocol, beyond that we should be careful to not downgrade the throughput or operations of the base-layer. If the original Stakes Certificates would have been implemented, it would have constituted a mempool congestion risk, where the node operators under jamming would have forced attackers to pay for fresh UTXOs. If we have to envision such cross-layer mitigation design in the future, I think we might have to do cross-layer consensus building. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-May/003594.html [1] https://github.com/lightningdevkit/rapid-gossip-sync-server [2] https://jamming-dev.github.io/book/4-design_space.html [3] https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/26 [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html Le lun. 30 janv. 2023 à 15:25, Carla Kirk-Cohen <kirkcoh...@gmail.com> a écrit : > Hi list, > > On Monday last week we resumed our fortnightly channel jamming > mitigation calls for 2023. > > Details for the next call: > * Monday 02/06 @ 18:00 UTC > * https://meet.jit.si/UnjammingLN > * Agenda: https://github.com/ClaraShk/LNJamming/issues/2 > > # Meeting Summary > This email attempts to summarize the discussion, but is of course > subject to my errors and opinions so the full transcript is available > at [1]. It is (imperfectly) AI generated, so please reach out to myself > or Clara if you'd like clarification for a specific section. > > 1. Upgrade Mechanisms > The first topic of discussion was around how we would go about > upgrading the network to support an anti-jamming mitigation. Most > solutions share the following characteristics: > * They will likely require a network wide upgrade: when a sender > makes a payment, the full path will need to understand the new > feature bit for it to be used. > * Sending nodes are unlikely to be incentivised to upgrade to > support a channel jamming mitigation, as jamming mitigations incur > additional cost (be it in the form of upfront fees, tokens or some > other mechanism). > * Routing nodes have no way of knowing whether a payment comes from > a node that is not upgraded, or simply doesn't want to pay the > additional cost introduced by a jamming mitigation. > > It was generally agreed that the network is still in an early enough > stage that it is fair for relaying nodes to initially upgrade but not > enforce the feature, and later look at forwarding traffic to determine > whether it is appropriate to require the feature. This will require > sending nodes to opt-in to the new feature before the network can > widely enforce it, as no rational routing node will require a feature > which would reduce its ability to serve un-upgraded traffic (unless > under attack, which is not the case at present). > > A note was also made that wallets tend to upgrade less frequently, in > part because some providers run forked versions of LN implementations, > so this horizon may be quite long. It was emphasized that this type of > network upgrade would require input from wallets, designers and > application developers anyway, so hopefully by the time we look to > deploy a change there is rough consensus among the Lightning community > already. > > 2. Upfront Fees > Next, we discussed the draft proposal for upfront fees [2] that > implements the first of a two-part jamming mitigation described in [3]. > As it stands, the PR describes the simplest possible way to introduce > upfront fees to the protocol: > * Upfront fees are expressed as a ppm of a channel's success-case > fees, and charged on the outgoing link of a route. > * Nodes can advertise custom upfront fee rates if desired, but to > save gossip bandwidth we assume a network-wide default of 1%. > * Upfront fees accumulate along the route (as htlc payment amounts > do), and are simply pushed to the `to_remote` balance on > `update_add_htlc`. > * Final hop nodes advertise an upfront fee policy in bolt 11 invoices > (or bolt 12 blinded routes) which is sufficiently padded to > obfuscate their location in the route. > > The interaction between upfront fees and possible future protocol > changes such as inbound fees and negative fees was briefly discussed, > specifically the case where a node sets low (or negative) fees to > attract traffic then fails payments to accumulate upfront fees. As is, > all implementations’ algorithms optimize for factors other than fees - > specifically avoiding a node once it's produced failures - and we > suspect that careful sender-side behavior will mitigate this risk. > However, it was also acknowledged that a node that attempts this attack > may be able to fool multiple individual senders and still be able to > accumulate some fees. > > We then discussed the shortcomings of the "simplest possible" upfront > fees in [2], specifically focused on the following scenario where > nodes receive 1% of their success-case fees as an upfront payment: > * Alice is sending a payment to Dave, who is a popular sink node in > the network. > * Bob -> Carol has low/default routing policy: 1000 msat success > case / 10 msat upfront fee > * Carol -> Dave has high fees: 400,000 msat success case / 4000 msat > upfront fee > * Dave advertises no success case fee (is recipient) / 100 msat of > upfront fee chosen for his invoice. > > Alice ------ Bob ------ Carol ------ Dave > > Since we need to source all of these funds from the sender (Alice), the > forwarding of funds is as follows: > * Alice pushes 4110 msat to Bob. > * Bob _should_ push 4100 msat to Carol, claiming his 10 msat upfront > fee. > * Carol _should_ push 100 msat to Dave, claiming her 4000 msat > upfront fee. > > However, Bob has no real incentive to forward the HTLC to Carol and > push her the 4100 msat because that value is more than the fees he'll > earn from successfully forwarding and settling the HTLC (10 msat > upfront fees + 1000 msat success case fees). It's worth noting that > this type of fee differential already exists in the network today - I > got these example numbers by looking at the fee rates of the Loop > node's peers [4]. > > There were a few points discussed around this issue: > * Whether we should look into a more complicated approach that > includes a "proof of forward" secret in the next node's onion which > must be supplied to claim the upfront fee. > * Discussion about whether these order of magnitude fee differences > will exist in an efficient market (differing opinions). > * Whether Bob _would_ steal the upfront fee by dropping the payment, > as it'll impact nodes' desire to route through them in future. > * Is there a way to deliver upfront fees to nodes along the route > *without* them adding up along the route (other than the naive > version of sending each hop a payment, which comes with its own > problems)? Seems not, but bright ideas are wanted and welcome! > * That nodes will decide where they fall in the trade-off of setting > upfront fees to cover their opportunity cost for high routing fees > and market pressure to keep these fees low for the sake of > remaining competitive. > > A few people mentioned the desire to keep an upfront fee solution as > simple as possible, but generally it seemed that a solution where the > accumulated upfront fees at any point along a route exceed any single > hop's expected success case fees is unacceptable because incentives > are misaligned (even if we can properly attribute errors with [5]). > > We touched briefly on a few "proof of forwarding" solutions for > upfront fees: > * Using a locking mechanism that relies on a secret that is provided > by the next node's onion. > * A taproot tree for all HTLCs where each leaf has a subset of HTLCs, > and fees could be incorporated here (summary note: apparently some > work has been done here, but I couldn't find the link). > * If we're confident that a more complicated solution will solve many > problems, then we should pursue them, otherwise a simple solution > is possibly a _good enough_ first step. > > There was some discussion about how we want to go about addressing > spamming in the network: > * Is it good enough to deploy something today that just charges a > simple, capped upfront fee (eg 1 sat per hop) that solves jamming > for the current state of the network and allows us to learn > something then iterate? > * Should our first attempt at solving this issue be for a future > steady state where nodes have significant traffic and nodes face > real opportunity cost (in the form of lost revenue) if they are > targeted by a jamming attack? > > 3. Circuit Breaker Update > * Circuit breaker has a UI now, and some issues are being opened in > the repo so people have at minimum gone through the effort to spin > it up. > * It's still pretty manual, but it does provide node operators with > information about the payment failures on their nodes (not easily > surfaced in many LN UIs). > * Hoping to get insights into stuck HTLCs and spam HTLCs so that we > can learn from real life experience. > * Circuit breaker is generally pushing in the same direction as the > reputation scheme in [3], just a more manual one. We could > possibly use it to visualize the endorsement system in [3] before > enforcing it. > * While circuit breaker isn't necessarily *the* solution to solving > jamming on LN, it provides us with some data points and a > practical way for individual operators to address spamming of > their nodes. > > 3. Tokens Update > Since our last discussion an architecture document was added to the > proposal [6], details in the mailing list post [7]. The main goal is > to try to dissociate the people paying the fees from those gaining the > benefits from the credentials, so that credentials can be paid by a > LSP (for example). > > 4. Reputation discussions in LSP Specification > Some attendees have been working on a reputation system for the LSP > specification group [8]. This system is intended to provide standard > metrics about what makes a node good/bad to connect to in the context > of a decentralized marketplace. While this work looks at the problem > from a different perspective, there's a possibility to consolidate > the efforts. It seems particularly useful in the anti-jamming case > where a node has newly connected to you, and needs a "start state" > reputation score. The idea of defining what qualifies as good > behavior in the Lightning Network is useful across the board. The > LSP specification group also has bi-weekly calls, and welcomes > additional participants! > > 5. Call Cadence > Attendees agreed to continue with calls every two weeks. General > consensus was that we would aim for a 30 minute meeting with the > option to extend to an hour if discussion warrants it. > > # What's next > Thanks to everyone who attended last week's meeting, we hope to see > more folks in the next one! > > There's a lot to discuss - brave readers who made it all the way to > the bottom of this email will notice a fair number of question marks > scattered about - and we're going to continue to break the problem > down into smaller parts to discuss in the hope of making progress. > > Any change to the Lightning Network that aims to address channel > jamming attacks will be a significant (but necessary) change to the > protocol, and it's going to need input from many different > stakeholders. Please reach out here or in private > (ca...@chaincode.com / cl...@chaincode.com) if you have any questions > / concerns / comments! > > Cheers until next time, > Carla and Clara > (Yes, our names are confusing. No, you won't get used to it) > > [1] > https://github.com/ClaraShk/LNJamming/blob/main/meeting-transcripts/23-01-23-transcript.md > [2] https://github.com/lightning/bolts/pull/1052 > [3] https://eprint.iacr.org/2022/1454.pdf > [4] > https://mempool.space/lightning/node/021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d > [5] https://github.com/lightning/bolts/pull/1044 > [6] https://github.com/lightning/bolts/pull/1043 > [8] https://github.com/BitcoinAndLightningLayerSpecs/lsp/issues/12 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
