Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-31 🗒️ Summary of this message: The Lightning ...
đź“… Original date posted:2023-01-31
🗒️ Summary of this message: The Lightning Network faces challenges with upfront fees, including the risk of theft and adding up along the route, but potential solutions are being explored.
đź“ť Original message:
(Reply 2/2)
> * 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 interoperabilitybetween 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
[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 <kirkcohenc at 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
> (carla at chaincode.com / clara at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230131/e171e031/attachment-0001.html>;
🗒️ Summary of this message: The Lightning Network faces challenges with upfront fees, including the risk of theft and adding up along the route, but potential solutions are being explored.
đź“ť Original message:
(Reply 2/2)
> * 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 interoperabilitybetween 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
[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 <kirkcohenc at 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
> (carla at chaincode.com / clara at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230131/e171e031/attachment-0001.html>;