Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning t-bast, > > An issue with the bidirectional upfront/hold fees is related to trustless > > offchain-to-onchain swaps, like Boltz and Lightning Loop. > > As the claiming of the offchain side is dependent on claiming of the > > onchain side of the trustless swap mechanism, which is *definitely* slow, > > the swap service will in general be forced to pay up the hold fees. > > Yes, that is a good observation. > But shouldn't the swap service take that into account in the fee it collects > to > perform the swap? That way it is in fact the user who pays for that fee. The user can wait for the swap service to put an onchain HTLC and then time it out. Thus, the offchain/onchain swap service will pay for both the onchain HTLC and the hold fee. This is fixed in e.g. Boltz by having a separate mining-fee invoice as well that must be paid before the offchain/onchain swap service will create the onchain HTLC. This is why I thought it would be better to include the hold fee in the mining-fee invoice as well. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost and Z, So in your proposal, an htlc that is received by a routing node has the > following properties: > * htlc amount > * forward up-front payment (anti-spam) > * backward up-front payment (anti-hold) > * grace period > The routing node forwards this to the next hop with > * lower htlc amount (to earn routing fees when the htlc settles) > * lower forward up-front payment (to make sure that an attacker at the > other end loses money when failing quickly) > * higher backward up-front payment (to make sure that an attacker at the > other end loses money when holding) > * shorter grace period (so that there is time to fail back and not lose > the backward up-front payment) That's exactly it, this is a good summary. An issue with the bidirectional upfront/hold fees is related to trustless > offchain-to-onchain swaps, like Boltz and Lightning Loop. > As the claiming of the offchain side is dependent on claiming of the > onchain side of the trustless swap mechanism, which is *definitely* slow, > the swap service will in general be forced to pay up the hold fees. Yes, that is a good observation. But shouldn't the swap service take that into account in the fee it collects to perform the swap? That way it is in fact the user who pays for that fee. Cheers, Bastien Le mer. 28 oct. 2020 à 02:13, ZmnSCPxj a écrit : > Good morning Bastien, Joost, and all, > > An issue with the bidirectional upfront/hold fees is related to trustless > offchain-to-onchain swaps, like Boltz and Lightning Loop. > > As the claiming of the offchain side is dependent on claiming of the > onchain side of the trustless swap mechanism, which is *definitely* slow, > the swap service will in general be forced to pay up the hold fees. > > It seems to me that the hold-fees mechanism cannot be ported over in the > onchain side, so even if you set a "reasonable" grace period at the swap > service of say 1 hour (and assuming forwarding nodes are OK with that > humongous grace period!), the onchain side of the swap can delay the > release of onchain. > > To mitigate against this, the swap service would need to issue a separate > invoice to pay for the hold fee for the "real" swap payment. > The Boltz protocol supports a separate mining-fee invoice (disabled on the > Boltz production servers) that is issued after the invoice is "locked in" > at the swap service, but I think that in view of the use of hold fee, a > combined mining-fee+hold-fee invoice would have to be issued at the same > time as the "real" swap invoice. > > Regards, > ZmnSCPxj > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Bastien, Joost, and all, An issue with the bidirectional upfront/hold fees is related to trustless offchain-to-onchain swaps, like Boltz and Lightning Loop. As the claiming of the offchain side is dependent on claiming of the onchain side of the trustless swap mechanism, which is *definitely* slow, the swap service will in general be forced to pay up the hold fees. It seems to me that the hold-fees mechanism cannot be ported over in the onchain side, so even if you set a "reasonable" grace period at the swap service of say 1 hour (and assuming forwarding nodes are OK with that humongous grace period!), the onchain side of the swap can delay the release of onchain. To mitigate against this, the swap service would need to issue a separate invoice to pay for the hold fee for the "real" swap payment. The Boltz protocol supports a separate mining-fee invoice (disabled on the Boltz production servers) that is issued after the invoice is "locked in" at the swap service, but I think that in view of the use of hold fee, a combined mining-fee+hold-fee invoice would have to be issued at the same time as the "real" swap invoice. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hi Bastien, I brought up the question about the amounts because it could be that >> amounts high enough to thwart attacks are too high for honest users or >> certain uses. > > > I don't think this is a concern for this proposal, unless there's an > attack vector I missed. > The reason I claim that is that the backwards upfront payment can be made > somewhat big without any > negative impact on honest nodes. > Yes, that makes sense. > But what happens if the attacker is also on the other end of the >> uncontrolled spam payment? Not holding the payment, but still collecting >> the forward payments? > > > That's what I call short-lived `controlled spam`. In that case the > attacker pays the forward fee at > the beginning of the route but has it refunded at the end of the route. If > the attacker doesn't > want to lose any money, he has to release the HTLC before the grace period > ends (which is going to > be short-lived - at least compared to block times). This gives an > opportunity for legitimate payments > to use the HTLC slots (but it's a race between the attacker and the > legitimate users). > I think indeed that this short-lived controlled spam also needs to be brought under control. Otherwise it is still easy to jam a channel, although it would need a continuous process to do it rather than sending a bunch of 2000-block expiry htlcs. For the short-lived controlled spam there is still a multiplier possible by making loops in the route. It is a race with legitimate users, but if the spammer is efficient the probability of a legitimate payment coming through is low. Similar to DDoS attacks where a legitimate web request could make it to the server but probably doesn't. > It's not ideal, because the attacker isn't penalized...the only way I > think we can penalize this > kind of attack is if the forward fee decrements at each hop, but in that > case it needs to be in the > onion (to avoid probing) and the delta needs to be high enough to actually > penalize the attacker. > Time to bikeshed some numbers! > So in your proposal, an htlc that is received by a routing node has the following properties: * htlc amount * forward up-front payment (anti-spam) * backward up-front payment (anti-hold) * grace period The routing node forwards this to the next hop with * lower htlc amount (to earn routing fees when the htlc settles) * lower forward up-front payment (to make sure that an attacker at the other end loses money when failing quickly) * higher backward up-front payment (to make sure that an attacker at the other end loses money when holding) * shorter grace period (so that there is time to fail back and not lose the backward up-front payment) On a high level, it seems to me that this can actually work. - Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Bastien, > > C can trivially grief D here, making it look like D is delaying, by > > delaying its own `commitment_signed` containing the *removal* of the HTLC. > > You're right to dive into these, there may be something here. > But I think your example doesn't work, let me know if I'm mistaken. > D is the one who decides whether he'll be refunded or not, because D is the > first to send the > `commit_sig` that removes the HTLC. I think we would extend `commit_sig` with > a tlv field that > indicates "I refunded myself for HTLC N" to help C compute the same commit tx > and verify sigs. D sending `commitment_signed` simply means C has the option to use either the previous commitment or the new one. C can still drop the previous commitment, which has the hold fee still owned by C. C only loses that option by sending `revoke_and_ack`, so C can still unfairly delay this, and at this point D is holding the previous commitment (which, as mentioned, has the hold fee still owned by C). So C can still delay by not revoking its previous commitment (`revoke_and_ack`) and not signing the D-side next commitment (`commitment_signed`). On the *other* hand if C can only *take* the hold fee at this point by dropping onchain, then the onchain fees and the loss of a viable channel (meaning the funds of C in that channel need to be put back into a new channel, again onchain fees) might very well dominate. Is this enough of a deterrent? On the other *other* hand, rules which involve "SHOULD/MUST fail the channel" have classically caused headaches in interop, xref. the mass channel closes between C-Lightning and lnd nodes some years ago due to sudden onchain fee movements. - On a mildly related note I have this old crap I wrote earlier this year, it might be possible to glean something from it: * https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002608.html Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hey Joost and Z, I brought up the question about the amounts because it could be that > amounts high enough to thwart attacks are too high for honest users or > certain uses. I don't think this is a concern for this proposal, unless there's an attack vector I missed. The reason I claim that is that the backwards upfront payment can be made somewhat big without any negative impact on honest nodes. If you're an honest intermediate node, only two cases are possible: * your downstream peer settled the HTLC quickly (before the grace period ends): in that case you refund him his upfront fee, and you have time to settle the HTLC upstream while still honoring the grace period, so it will be refunded to you as well (unless you delay the settlement upstream for whatever reason, in which case you deserve to pay the hold_fee) * your grace period has expired, so you can't get a refund upstream: if that happens, the grace period with your downstream node has also expired, so you're earning money downstream and paying money upstream, and you'll usually even take a small positive spread so everything's good The only node that can end up loosing money on the backwards upfront payment is the last node in the route. But that node should always settle the HTLC quickly (or decide to hodl it, but in that case it's normal that it pays the hold_fee). But what happens if the attacker is also on the other end of the > uncontrolled spam payment? Not holding the payment, but still collecting > the forward payments? That's what I call short-lived `controlled spam`. In that case the attacker pays the forward fee at the beginning of the route but has it refunded at the end of the route. If the attacker doesn't want to lose any money, he has to release the HTLC before the grace period ends (which is going to be short-lived - at least compared to block times). This gives an opportunity for legitimate payments to use the HTLC slots (but it's a race between the attacker and the legitimate users). It's not ideal, because the attacker isn't penalized...the only way I think we can penalize this kind of attack is if the forward fee decrements at each hop, but in that case it needs to be in the onion (to avoid probing) and the delta needs to be high enough to actually penalize the attacker. Time to bikeshed some numbers! C can trivially grief D here, making it look like D is delaying, by > delaying its own `commitment_signed` containing the *removal* of the HTLC. You're right to dive into these, there may be something here. But I think your example doesn't work, let me know if I'm mistaken. D is the one who decides whether he'll be refunded or not, because D is the first to send the `commit_sig` that removes the HTLC. I think we would extend `commit_sig` with a tlv field that indicates "I refunded myself for HTLC N" to help C compute the same commit tx and verify sigs. I agree with you that the details of how we'll implement the grace period may have griefing attacks depending on how we do it, it's worth exploring further. Cheers, Bastien Le ven. 23 oct. 2020 à 12:50, ZmnSCPxj a écrit : > Good morning t-bast, > > > > > And in this case C earns. > > > > > Can C delay the refund to D to after the grace period even if D > settled the HTLC quickly? > > > > Yes C earns, but D has misbehaved. As a final recipient, D isn't > dependent on anyone downstream. > > An honest D should settle the HTLC before the `grace_period` ends. If D > chooses to hold the HTLC > > for a while, then it's fair that he pays C for this. > > > Okay, now let us consider the case where the supposedly-delaying party is > not the final destination. > > So, suppose D indicates to C that it should fail the HTLC. > In this case, C cannot immediately propagate the `update_fail_htlc` > upstream, since the latest commitment transaction for the C<->D channel > still contains the HTLC. > > In addition, our state machine is hand-over-hand, i.e. there is a small > window where there are two valid commitment transactions. > What happens is we sign the next commitment transaction and *then* revoke > the previous one. > > So I think C can only safely propagate its own upstream `update_fail_htlc` > once it receives the `revoke_and_ack` from D. > > So the time measured for the grace period between C and D should be from C > sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case > the HTLC fails. > This is the time period that D is allowed to consume, and if it exceeds > the grace period, it is penalized. > > (In this situation, it is immaterial if D is the destination: C cannot > know this fact.) > > So let us diagram this better: > > C D > |update_add_htlc--->| --- > |---commitment_signed-->| ^ > ||<--commitment_signed---| | > |-revoke_and_ack--->| | > | | grace period > |<--update_fail_htlc| | > |<--commitment_signed---| | >
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning t-bast, > > And in this case C earns. > > > Can C delay the refund to D to after the grace period even if D settled the > > HTLC quickly? > > Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on > anyone downstream. > An honest D should settle the HTLC before the `grace_period` ends. If D > chooses to hold the HTLC > for a while, then it's fair that he pays C for this. Okay, now let us consider the case where the supposedly-delaying party is not the final destination. So, suppose D indicates to C that it should fail the HTLC. In this case, C cannot immediately propagate the `update_fail_htlc` upstream, since the latest commitment transaction for the C<->D channel still contains the HTLC. In addition, our state machine is hand-over-hand, i.e. there is a small window where there are two valid commitment transactions. What happens is we sign the next commitment transaction and *then* revoke the previous one. So I think C can only safely propagate its own upstream `update_fail_htlc` once it receives the `revoke_and_ack` from D. So the time measured for the grace period between C and D should be from C sending `update_add_htlc` to C receiving `revoke_and_ack` from D, in case the HTLC fails. This is the time period that D is allowed to consume, and if it exceeds the grace period, it is penalized. (In this situation, it is immaterial if D is the destination: C cannot know this fact.) So let us diagram this better: C D |update_add_htlc--->| --- |---commitment_signed-->| ^ || | | | grace period |<--update_fail_htlc| | |<--commitment_signed---| | |-revoke_and_ack--->| | |---commitment_signed-->| v <--- grief point! | `update_fail_htlc`->C and the corresponding C->`commitment_signed`->D becomes too long: * D drops the channel onchain. * The dropped commitment tx still contains the HTLC, since it is the "previous" commitment that D happens to hold that has not yet had the `update_fail_htlc` committed. If D performs the above, then C is forced to wait *even longer* (it has to wait out the HTLC timelock) before it can safely propagate the `update_fail_htlc`: D could be fooling with it and actually knows the preimage and claim it onchain, so C for its own safety *must* wait out the onchain timelock. Does that make sense? Does it sensibly protect against this griefing? Is it too much of a punishment and could potentially hurt D more than it hurts C if C is a heavily-connected node that will not miss the channel while D has fewer channels and opened the C<->D channel in the first place? -- For success case `update_fulfill_htlc`, I believe C can immediately propagate this back to its upstream since it can now. Thus, in that case, we can stop the timer at the `update_fulfill_htlc`. So at least for the *end point* of the grace period, I think the end point should be: * If the HTLC failed: * When both participants have sent `revoke_and_ack`. * If the HTLC succeeded: * When the downstream participant has sent `update_fulfill_htlc`. For the *start point*, it seems the C->`commitment_signed`->D containing the HTLC would work as the start point. In particular, it seems to me that C can also deliberately defer its own C->`revoke_and_ack`->D: C D |update_add_htlc--->| |---commitment_signed-->| --- | | | <--- grief point! | | grace period |<--update_fail_htlc| | |<--commitment_signed---| | |-revoke_and_ack--->| | |---commitment_signed-->| v |
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > It is interesting that the forward and backward payments are relatively >> independent of each other > > > To explain this further, I think it's important to highlight that the > forward fee is meant to fight > `uncontrolled spam` (where the recipient is an honest node) while the > backward fee is meant to fight > `controlled spam` (where the recipient also belongs to the attacker). > Yes, that was clear. I just meant to say that we could choose to first only implement the easier uncontrolled spam protection via the forward payment. Not that any type of protocol upgrade is easy... What I'd really like to explore is whether there is a type of spam that I > missed or griefing attacks > that appear because of the mechanisms I introduce. TBH I think the > implementation details (amounts, > grace periods and their deltas, when to start counting, etc) are things > we'll be able to figure out > collectively later. > I brought up the question about the amounts because it could be that amounts high enough to thwart attacks are too high for honest users or certain uses. If that is the case, we don't need to look for other potential weaknesses. It is just a different order to explore the feasibility of the proposal. The forward payment can indeed be small, because uncontrolled spam can only be in-flight for a short time. To get to that annual return of 5% on a 1 BTC / 483 slot channel, it needs to be approx 1 sat/hour (if I calculated that correctly). Let's say the spam payment is in-flight on average 30 seconds on a 20 route hop (60 sec at the start, 0 sec at the end). The total "damage" would then be 600 hop-seconds, requiring a forward payment of 150 msat to cover that. Still seems acceptable to me. If an honest user makes a payment and needs 10 attempts, they will pay an additional 1.5 sats for that. Might be a ux-challenge to communicate that cost to a normal user for a failed payment though. But what happens if the attacker is also on the other end of the uncontrolled spam payment? Not holding the payment, but still collecting the forward payments? For the backward payment the pricing is different. The max expiry of the htlc is 2000 blocks, 1000 blocks on average along the route. 1000 blocks is about 160 hours. So ideally the attacker at the far end of the route should pay 20 * 160 * 1sat/hr = 3200 sat. This will also be the cost for a hold invoice then, but not everybody liked them anyway. The net cost for a regular (fast) payment will be nothing as you described. - Joost > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Thanks for your answers, My first instinct is that additional complications are worse in general. > However, it looks like simpler solutions are truly not enough, so adding > the complication may very well be necessary. I agree with both these statements ;). I'd love to find a simpler solution, but this is the simplest I've been able to come up with for now that seems to work without adding griefing vectors... The succeeding text refers to HTLCs "settling". As you noted, settling means getting the HTLC removed from the commitment transaction. It includes both fulfills and fails, otherwise the proposal indeed doesn't penalize spam. If we also require that the hold fee be funded from the main output, then > we cannot use single-funded channels, except perhaps with `push_msat`. I see what you mean, the first payment cannot require a hold fee since the fundee doesn't have a main output. I think it's ok, it's the same thing as the reserve not being met initially. But you're right that there are potentially other mechanisms to enforce the fee (like your suggestion of subtracting from the HTLC output), I chose the simplest for now but we can (and will) revisit that choice if we think that the overall mechanisms work! And in this case C earns. Can C delay the refund to D to after the grace period even if D settled the > HTLC quickly? Yes C earns, but D has misbehaved. As a final recipient, D isn't dependent on anyone downstream. An honest D should settle the HTLC before the `grace_period` ends. If D chooses to hold the HTLC for a while, then it's fair that he pays C for this. it is the fault of the peer for getting disconnected and having a delay in > reconnecting, possibly forfeiting the hold fee because of that. I think I agree with that, but we'll need to think about the pros and cons when we get to details. Is 1msat going to even deter anyone? I am wondering though what the values for the fwd and bwd fees should be. I > agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be > enough. These values are only chosen for the simplicity of the example's sake. If we agree the proposal works to fight spam, we will do some calculations to figure a good value for this. But I think finding the right base values will not be the hard part, so we'll focus on this if we're convinced the proposal is worth exploring in full details. It is interesting that the forward and backward payments are relatively > independent of each other To explain this further, I think it's important to highlight that the forward fee is meant to fight `uncontrolled spam` (where the recipient is an honest node) while the backward fee is meant to fight `controlled spam` (where the recipient also belongs to the attacker). The reason it works is because the `uncontrolled spam` requires the attacker to send a large volume of HTLCs, so a very small forward fee gets magnified. The backward fee will be much bigger because in `controlled spam`, the attacker doesn't need a large volume of HTLCs but holds them for a long time. What I think is nice is that this proposal has only a tiny cost for honest senders (the forward fee). What I'd really like to explore is whether there is a type of spam that I missed or griefing attacks that appear because of the mechanisms I introduce. TBH I think the implementation details (amounts, grace periods and their deltas, when to start counting, etc) are things we'll be able to figure out collectively later. Thanks again for your time! Bastien Le ven. 23 oct. 2020 à 07:58, Joost Jager a écrit : > Hi Bastien, > > We add a forward upfront payment of 1 msat (fixed) that is paid >> unconditionally when offering an HTLC. >> We add a backwards upfront payment of `hold_fees` that is paid when >> receiving an HTLC, but refunded >> if the HTLC is settled before the `hold_grace_period` ends (see footnotes >> about this). >> > > It is interesting that the forward and backward payments are relatively > independent of each other. In particular the forward anti-spam payment > could quite easily be implemented to help protect the network. As you said, > just transfer that fixed fee for every `update_add_htlc` message from the > offerer to the receiver. > > I am wondering though what the values for the fwd and bwd fees should be. > I agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be > enough. > > Maybe a way to approach it is this: suppose routing nodes are able to make > 5% per year on their committed capital. An aggressive routing node could be > willing to spend up to that amount to take down a competitor. > > Suppose the network consists only of 1 BTC, 483 slot channels. What should > the fwd and bwd fees be so that even an attacked routing node will still > earn that 5% (not through forwarding fees, but through hold fees) in both > the controlled and the uncontrolled spam scenario? > > - Joost > ___ Lightning-dev mailing list
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hi Bastien, We add a forward upfront payment of 1 msat (fixed) that is paid > unconditionally when offering an HTLC. > We add a backwards upfront payment of `hold_fees` that is paid when > receiving an HTLC, but refunded > if the HTLC is settled before the `hold_grace_period` ends (see footnotes > about this). > It is interesting that the forward and backward payments are relatively independent of each other. In particular the forward anti-spam payment could quite easily be implemented to help protect the network. As you said, just transfer that fixed fee for every `update_add_htlc` message from the offerer to the receiver. I am wondering though what the values for the fwd and bwd fees should be. I agree with ZmnSCPxj that 1 msat for the fwd is probably not going to be enough. Maybe a way to approach it is this: suppose routing nodes are able to make 5% per year on their committed capital. An aggressive routing node could be willing to spend up to that amount to take down a competitor. Suppose the network consists only of 1 BTC, 483 slot channels. What should the fwd and bwd fees be so that even an attacked routing node will still earn that 5% (not through forwarding fees, but through hold fees) in both the controlled and the uncontrolled spam scenario? - Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning t-bast, > Sorry in advance for the lengthy email, Come on, ZmnSCPxj writes lengthier. > but I think it's worth detailing my hybrid proposal > (bidirectional upfront payments), it feels to me like a workable solution > that builds on > previous proposals. You can safely ignore the details at the end of the email > and focus only on > the high-level mechanism at first. > > Let's consider the following route: A -> B -> C -> D > > We add a `hold_grace_period_delta` field to `channel_update` (in seconds). > We add two new fields in the tlv extension of `update_add_htlc`: > > * `hold_grace_period` (seconds) > * `hold_fees` (msat) > > We add an `outgoing_hold_grace_period` field in the onion per-hop payload. > > When nodes receive an `update_add_htlc`, they verify that: > > * `hold_fees` is not unreasonable large > * `hold_grace_period` is not unreasonably small or large > * `hold_grace_period` - `outgoing_hold_grace_period` >= > `hold_grace_period_delta` > > Otherwise they immediately fail the HTLC instead of relaying it. > > For the example we assume all nodes use `hold_grace_period_delta = 10`. > > We add a forward upfront payment of 1 msat (fixed) that is paid > unconditionally when offering an HTLC. > We add a backwards upfront payment of `hold_fees` that is paid when receiving > an HTLC, but refunded > if the HTLC is settled before the `hold_grace_period` ends (see footnotes > about this). My first instinct is that additional complications are worse in general. However, it looks like simpler solutions are truly not enough, so adding the complication may very well be necessary. Possibly one of the issues with previous proposals is that we considered the source as the payer of upfront fees always, without considering the possibility of the destination paying upfront fees. We should consider *why* we did so. Is it only because of lack of imagination? The succeeding text refers to HTLCs "settling". What does this mean exactly? Does it refer to the preimage being revealed only? Or does it refer to *either* `update_fulfill_htlc` **OR** `update_fail_htlc`? If "settling" does not include failing the HTLC, I can extract hold fees from my peers by giving them HTLCs to random hashes that with very high probability has a preimage unknown to my peer. Thus, "settling" here must also include failing the HTLC. Can we arrange the HTLC as below? * The HTLC is lower by the from-destination hold fee than what it "should" be. * So in your example, A would offer an HTLC that is 5 msat lower than what it "should" be, to represent the from-destination hold-fee. * When the HTLC is fulfilled offchain, we move the hold fee amount from offerrer to acceptor, thus "refunding" the hold fee. * If the HTLC is failed offchain, we just delete the HTLC. The above would disincentivize dropping the channel onchain for whatever shenanigans might be possible there. Note that if hold fees are always from the "main output" of the acceptor, then we cannot use single-funded channel opening. Single-funded channel opening is significantly lower-risk as, if somebody opens a channel to you and then goes offline forever, you would not care, none of your funds are in the channel. (Sure they could move funds out of the channel and *then* go offline forever, but you got paid for that by the forwarding fees in the first place.) Dual-funding requires some amount of trust/reputation, where you would only be willing to put funds on the initiating peer if you are reasonably sure that they would remain online so that the funds you put in the channel are not uselessly locked. If we also require that the hold fee be funded from the main output, then we cannot use single-funded channels, except perhaps with `push_msat`. On the other hand, it might be useful to require that though, as a promise from the funder that yes, it *is* committed to making that channel work, and will thus `push_msat` at you so you can pay for hold fees. > > * A sends an HTLC to B: > * `hold_grace_period = 100 sec` > * `hold_fees = 5 msat` > * `next_hold_grace_period = 90 sec` > * forward upfront payment: 1 msat is deduced from A's main output and added > to B's main output > * backwards upfront payment: 5 msat are deduced from B's main output and > added to A's main output > * B forwards the HTLC to C: > * `hold_grace_period = 90 sec` > * `hold_fees = 6 msat` > * `next_hold_grace_period = 80 sec` > * forward upfront payment: 1 msat is deduced from B's main output and added > to C's main output > * backwards upfront payment: 6 msat are deduced from C's main output and > added to B's main output > * C forwards the HTLC to D: > * `hold_grace_period = 80 sec` > * `hold_fees = 7 msat` > * `next_hold_grace_period = 70 sec` > * forward upfront payment: 1 msat is deduced from C's main output and added > to D's main output > * backwards upfront payment: 7 msat are deduced from D's main output and > added to C's main output The
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning list, Sorry in advance for the lengthy email, but I think it's worth detailing my hybrid proposal (bidirectional upfront payments), it feels to me like a workable solution that builds on previous proposals. You can safely ignore the details at the end of the email and focus only on the high-level mechanism at first. Let's consider the following route: A -> B -> C -> D We add a `hold_grace_period_delta` field to `channel_update` (in seconds). We add two new fields in the tlv extension of `update_add_htlc`: * `hold_grace_period` (seconds) * `hold_fees` (msat) We add an `outgoing_hold_grace_period` field in the onion per-hop payload. When nodes receive an `update_add_htlc`, they verify that: * `hold_fees` is not unreasonable large * `hold_grace_period` is not unreasonably small or large * `hold_grace_period` - `outgoing_hold_grace_period` >= `hold_grace_period_delta` Otherwise they immediately fail the HTLC instead of relaying it. For the example we assume all nodes use `hold_grace_period_delta = 10`. We add a forward upfront payment of 1 msat (fixed) that is paid unconditionally when offering an HTLC. We add a backwards upfront payment of `hold_fees` that is paid when receiving an HTLC, but refunded if the HTLC is settled before the `hold_grace_period` ends (see footnotes about this). * A sends an HTLC to B: * `hold_grace_period = 100 sec` * `hold_fees = 5 msat` * `next_hold_grace_period = 90 sec` * forward upfront payment: 1 msat is deduced from A's main output and added to B's main output * backwards upfront payment: 5 msat are deduced from B's main output and added to A's main output * B forwards the HTLC to C: * `hold_grace_period = 90 sec` * `hold_fees = 6 msat` * `next_hold_grace_period = 80 sec` * forward upfront payment: 1 msat is deduced from B's main output and added to C's main output * backwards upfront payment: 6 msat are deduced from C's main output and added to B's main output * C forwards the HTLC to D: * `hold_grace_period = 80 sec` * `hold_fees = 7 msat` * `next_hold_grace_period = 70 sec` * forward upfront payment: 1 msat is deduced from C's main output and added to D's main output * backwards upfront payment: 7 msat are deduced from D's main output and added to C's main output * Scenario 1: D settles the HTLC quickly: * all backwards upfront payments are refunded (returned to the respective main outputs) * only the forward upfront payments have been paid (to protect against `uncontrolled spam`) * Scenario 2: D settles the HTLC after the grace period: * D's backwards upfront payment is not refunded * If C and B relay the settlement upstream quickly (before `hold_grace_period_delta`) their backwards upfront payments are refunded * all the forward upfront payments have been paid (to protect against `uncontrolled spam`) * Scenario 3: C delays the HTLC: * D settles before its `grace_period`, so its backwards upfront payment is refunded by C * C delays before settling upstream: it can ensure B will not get refunded, but C will not get refunded either so B gains the difference in backwards upfront payments (which protects against `controlled spam`) * all the forward upfront payments have been paid (to protect against `uncontrolled spam`) * Scenario 4: the channel B <-> C closes: * D settles before its `grace_period`, so its backwards upfront payment is refunded by C * for whatever reason (malicious or not) the B <-> C channel closes * this ensures that C's backwards upfront payment is paid to B * if C publishes an HTLC-fulfill quickly, B may have his backwards upfront payment refunded by A * if B is forced to wait for his HTLC-timeout, his backwards upfront payment will not be refunded but it's ok because B got C's backwards upfront payment * all the forward upfront payments have been paid (to protect against `uncontrolled spam`) If done naively, this mechanism may allow intermediate nodes to deanonymize sender/recipient. If the base `grace_period` and `hold_fees` are randomized, I believe this attack vector disappears, but it's worth exploring in more details. The most painful part of this proposal will be handling the `grace_period`: * when do you start counting: when you send/receive `update_add_htlc`, `commit_sig` or `revoke_and_ack`? * what happens if there is a disconnection (how do you account for the delay of reconnecting)? * what happens if the remote settles after the `grace_period`, but refunds himself when sending his `commit_sig` (making it look like from his point of view he settled before the `grace_period`)? I think in that case the behavior should be to give your peers some leeway and let them get away with it, but record it. If they're doing it too often, close channels and ban them; stealing upfront fees should never be worth losing channels. I chose to make the backwards upfront payment fixed instead of scaling it based on the time an HTLC is left pending; it's slightly less penalizing for spammers, but is less complex and introduce
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning t-bast, > > I've started summarizing proposals, attacks and threat models on github [1]. > I'm hoping it will help readers get up-to-speed and avoid falling in the same > pitfalls we already > fell into with previous proposals. Would my inane incremental routing idea also be in scope here? https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002811.html Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hi Bastien, Thanks for creating the summary! While doing this exercise, I couldn't find a reason why the `reverse > upfront payment` proposal > would be broken (notice that I described it using a flat amount after a > grace period, not an amount > based on the time HTLCs are held). Can someone point me to the most > obvious attacks on it? > > It feels to me that its only issue is that it still allows spamming for > durations smaller than the > grace period; my gut feeling is that if we add a smaller forward direction > upfront payment to > complement it it could be a working solution. > The 'uncontrolled spamming' as you called it in your doc is pretty serious. If you want to have fun, you should really try to spin up a bunch of threads and keep your outgoing channels fully saturated with max length routes going nowhere. I tried it on testnet and it was quite bad. All that traffic is fighting for resources which makes it take even longer to unlock the htlcs again. I think that any solution should definitely address this case too. Your proposal to add a small upfront payment, wouldn't that allow the (arbitrary) grace period to be removed? It would mean that routing nodes always need to pay something for forwarding spam, but if they do it quick enough (honest nodes) that expense is covered by the upfront payment. - Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning list, I've started summarizing proposals, attacks and threat models on github [1]. I'm hoping it will help readers get up-to-speed and avoid falling in the same pitfalls we already fell into with previous proposals. I've kept it very high-level for now; we can add nitty-gritty technical details as we slowly converge towards acceptable solutions. I have probably missed subtleties from previous proposals; feel free to contribute to correct my mistakes. I have omitted for examples the details of Rusty's previous proposal since he mentioned a new, better one that will be described soon. While doing this exercise, I couldn't find a reason why the `reverse upfront payment` proposal would be broken (notice that I described it using a flat amount after a grace period, not an amount based on the time HTLCs are held). Can someone point me to the most obvious attacks on it? It feels to me that its only issue is that it still allows spamming for durations smaller than the grace period; my gut feeling is that if we add a smaller forward direction upfront payment to complement it it could be a working solution. Pasting it here for completeness: ### Reverse upfront payment This proposal builds on the previous one, but reverses the flow. Nodes pay a fee for *receiving* HTLCs instead of *sending* them. ```text A -> B -> C -> D B pays A to receive the HTLC. Then C pays B to receive the forwarded HTLC. Then D pays C to receive the forwarded HTLC. ``` There must be a grace period during which no fees are paid; otherwise the `uncontrolled spam` attack allows the attacker to force all nodes in the route to pay fees while he's not paying anything. The fee cannot be the same at each hop, otherwise it's free for the attacker when he is at both ends of the payment route. This fee must increase as the HTLC travels downstream: this ensures that nodes that hold HTLCs longer are penalized more than nodes that fail them fast, and if a node has to hold an HTLC for a long time because it's stuck downstream, they will receive more fees than what they have to pay. The grace period cannot be the same at each hop either, otherwise the attacker can force Bob to be the only one to pay fees. Similarly to how we have `cltv_expiry_delta`, nodes must have a `grace_period_delta` and the `grace_period` must be bigger upstream than downstream. Drawbacks: * The attacker can still lock HTLCs for the duration of the `grace_period` and repeat the attack continuously Open questions: * Does the fee need to be based on the time the HTLC is held? * What happens when a channel closes and HTLC-timeout has to be redeemed on-chain? * Can we implement this without exposing the route length to intermediate nodes? Cheers, Bastien [1] https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md Le dim. 18 oct. 2020 à 09:25, Joost Jager a écrit : > > We've looked at all kinds of trustless payment schemes to keep users >> >> > honest, but it appears that none of them is satisfactory. Maybe it is >> even >> > theoretically impossible to create a scheme that is trustless and has >> all >> > the properties that we're looking for. (A proof of that would also be >> >> > useful information to have.) >> >> I don't think anyone has drawn yet a formal proof of this, but roughly a >> routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking >> to answer the following question "Is this payment coming from Alice and >> going to Caroll will compensate for my resources consumption ?". With the >> current LN system, the compensation is conditional on payment settlement >> success and both Alice and Caroll are distrusted yet discretionary on >> failure/success. Thus the underscored question is undecidable for a routing >> peer making relay decisions only on packet observation. >> >> One way to mitigate this, is to introduce statistical observation of >> sender/receiver, namely a reputation system. It can be achieved through a >> scoring system, web-of-trust, or whatever other solution with the same >> properties. >> But still it must be underscored that statistical observations are only >> probabilistic and don't provide resource consumption security to Bob, the >> routing peer, in a deterministic way. A well-scored peer may start to >> suddenly misbehave. >> >> In that sense, the efficiency evaluation of a reputation-based solution >> to deter DoS must be evaluated based based on the loss of the reputation >> bearer related to the potential damage which can be inflicted. It's just >> reputation sounds harder to compute accurately than a pure payment-based >> DoS protection system. >> > > I can totally see the issues and complexity of a reputation-based system. > With 'trustless payment scheme' I meant indeed a trustless pure > payment-based DoS protection system and the question whether such a system > can be proven to not exist. A sender would pay an up-front amount to cover > the maximum cost, but with the
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > We've looked at all kinds of trustless payment schemes to keep users > > > honest, but it appears that none of them is satisfactory. Maybe it is > even > > theoretically impossible to create a scheme that is trustless and has > all > > the properties that we're looking for. (A proof of that would also be > > > useful information to have.) > > I don't think anyone has drawn yet a formal proof of this, but roughly a > routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking > to answer the following question "Is this payment coming from Alice and > going to Caroll will compensate for my resources consumption ?". With the > current LN system, the compensation is conditional on payment settlement > success and both Alice and Caroll are distrusted yet discretionary on > failure/success. Thus the underscored question is undecidable for a routing > peer making relay decisions only on packet observation. > > One way to mitigate this, is to introduce statistical observation of > sender/receiver, namely a reputation system. It can be achieved through a > scoring system, web-of-trust, or whatever other solution with the same > properties. > But still it must be underscored that statistical observations are only > probabilistic and don't provide resource consumption security to Bob, the > routing peer, in a deterministic way. A well-scored peer may start to > suddenly misbehave. > > In that sense, the efficiency evaluation of a reputation-based solution to > deter DoS must be evaluated based based on the loss of the reputation > bearer related to the potential damage which can be inflicted. It's just > reputation sounds harder to compute accurately than a pure payment-based > DoS protection system. > I can totally see the issues and complexity of a reputation-based system. With 'trustless payment scheme' I meant indeed a trustless pure payment-based DoS protection system and the question whether such a system can be proven to not exist. A sender would pay an up-front amount to cover the maximum cost, but with the guarantee that nodes can only take a fair part of the deposit (based on actual lock time). Perhaps the taproot upgrade offers new possibilities with adaptor signatures to atomically swap part of the up-front payment with htlc-received-in-time-signatures from nodes downstream (random wild idea). > > What I can see working is a system where peers charge each other a hold > fee > > for forwarded HTLCs based on the actual lock time (not the maximum lock > > > time) and the htlc value. This is just for the cost of holding and > separate > > from the routing fee that is earned when the payment settles > > Yes I guess any solution will work as long as it enforces an asymmetry > between the liquidity requester and a honest routing peer. This asymmetry > can be defined as guaranteeing that the routing peer's incoming/outgoing > balance is always increasing, independently of payment success. Obviously > this increase should be materialized by a payment, while minding it might > be discounted based on requester reputation ("pay-with-your-reputation"). > This reputation evaluation can be fully delegated to the routing node > policy, without network-wise guidance. > > That said, where I'm skeptical on any reputation-heavy system is on the > long-term implications. > > Either, due to the wants of a subset of actors deliberately willingly to > trade satoshis against discounted payment flow by buying well-scored > pubkeys, we see the emergence of a reputation market. Thus enabling > reputation to be fungible to satoshis, but with now a weird "reputation" > token to care about. > > Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys > from channel ownership or export your score across routing peers) and thus > you now have reputation scarcity which is introducing a bias from a "purer" > market, where agents are only routing based on advertised fees. IMO, we > should strive for the more liquid Lightning market we can, as it avoids > bias towards past actors and thus may contain centralization inertia. I'm > curious about your opinion on this last point. > I am in favor of more liquidity and less centralization, but as far as I know the reality is that we don't have a good solution yet to achieve this without being vulnerable to DoS attacks. If those attacks would happen on a large scale today, what would we do? Also peers can implement these trusted upfront payments without protocol changes. Just stop forwarding when the prepaid forwarding budget is used up and require a top-up. It may have been implemented already in parts of the network, I don't think there is a way to know. I've experimented a bit with the fee model myself ( https://twitter.com/joostjgr/status/1317546071984427009). Node operators don't need to wait for permission. To me it seems that the longer it takes to come up with a good anti-DoS system for Lightning, the further the outside world will have develope
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hi Joost, Thanks for your proposal, please find my following opinion which is deliberately on a high-level as IMO defining better threats model and agreeing on expected network dynamics resulting from any solution trade-offs sounds required before to work on any solution. > We've looked at all kinds of trustless payment schemes to keep users > honest, but it appears that none of them is satisfactory. Maybe it is even > theoretically impossible to create a scheme that is trustless and has all > the properties that we're looking for. (A proof of that would also be > useful information to have.) I don't think anyone has drawn yet a formal proof of this, but roughly a routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking to answer the following question "Is this payment coming from Alice and going to Caroll will compensate for my resources consumption ?". With the current LN system, the compensation is conditional on payment settlement success and both Alice and Caroll are distrusted yet discretionary on failure/success. Thus the underscored question is undecidable for a routing peer making relay decisions only on packet observation. One way to mitigate this, is to introduce statistical observation of sender/receiver, namely a reputation system. It can be achieved through a scoring system, web-of-trust, or whatever other solution with the same properties. But still it must be underscored that statistical observations are only probabilistic and don't provide resource consumption security to Bob, the routing peer, in a deterministic way. A well-scored peer may start to suddenly misbehave. In that sense, the efficiency evaluation of a reputation-based solution to deter DoS must be evaluated based based on the loss of the reputation bearer related to the potential damage which can be inflicted. It's just reputation sounds harder to compute accurately than a pure payment-based DoS protection system. > Perhaps a small bit of trust isn't so bad. There is trust in Lightning > already. For example when you open a channel, you trust (or hope) that your > peer remains well connected, keeps charging reasonable fees, doesn't > force-close in a bad way, etc. That's a good recall, obviously we should avoid getting stuck in a false trust-vs-trustlessness dichotomy but always bound the discussion to a specific situation. Even the base layer involved some trust assumptions, like fetching your initial p2p peers from DNS seeds, all the matter is how do you minimize this assumption. You might not have the same expectation when it's miners which might completely screw up the safety of your coin stack than routing nodes which might only make your loss a tiny routing fee, a minor nuisance. > What I can see working is a system where peers charge each other a hold fee > for forwarded HTLCs based on the actual lock time (not the maximum lock > time) and the htlc value. This is just for the cost of holding and separate > from the routing fee that is earned when the payment settles Yes I guess any solution will work as long as it enforces an asymmetry between the liquidity requester and a honest routing peer. This asymmetry can be defined as guaranteeing that the routing peer's incoming/outgoing balance is always increasing, independently of payment success. Obviously this increase should be materialized by a payment, while minding it might be discounted based on requester reputation ("pay-with-your-reputation"). This reputation evaluation can be fully delegated to the routing node policy, without network-wise guidance. That said, where I'm skeptical on any reputation-heavy system is on the long-term implications. Either, due to the wants of a subset of actors deliberately willingly to trade satoshis against discounted payment flow by buying well-scored pubkeys, we see the emergence of a reputation market. Thus enabling reputation to be fungible to satoshis, but with now a weird "reputation" token to care about. Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys from channel ownership or export your score across routing peers) and thus you now have reputation scarcity which is introducing a bias from a "purer" market, where agents are only routing based on advertised fees. IMO, we should strive for the more liquid Lightning market we can, as it avoids bias towards past actors and thus may contain centralization inertia. I'm curious about your opinion on this last point. Moving forward, I think t-bast is working on gathering materials to checkbox the first step, establishing a fully-fledged threat model. Cheers, Antoine Le lun. 12 oct. 2020 à 07:04, Joost Jager a écrit : > Hello list, > > Many discussions have taken place on this list on how to prevent undesired > use of the Lightning network. Spamming the network with HTLCs (for probing > purposes or otherwise) or holding HTLCs to incapacitate channels can be > done on today's network at very little cost to an attacker.
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Joost Jager writes: >> >> > A crucial thing is that these hold fees don't need to be symmetric. A new >> > node for example that opens a channel to a well-known, established >> routing >> > node will be forced to pay a hold fee, but won't see any traffic coming >> in >> > anymore if it announces a hold fee itself. Nodes will need to build a >> > reputation before they're able to command hold fees. Similarly, routing >> > nodes that have a strong relation may decide to not charge hold fees to >> > each other at all. >> >> I can still establish channels to various low-reputation nodes, and then >> use them to grief a high-reputation node. Not only do I get to jam up >> the high-reputation channels, as a bonus I get the low-reputation nodes >> to pay for it! > > So you're saying: > > ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I would > only waive the hold fee for high-reputation nodes. In that case, the > attacker is still paying for the attack. I may be forced to take a small > loss on the difference, but at least the larger part of the pain is felt by > the attacker. The assumption is that this is sufficient enough to deter the > attacker from even trying. No, because HIGH-REP == ATTACKER and LOW-REP pays. > I guess your concern is with trying to become a routing node? If nobody > knows you, you'll be forced to pay hold fees but can't attract traffic if > you charge hold fees yourself. That indeed means that you'll need to be > selective with whom you accept htlcs from. Put limits in place to control > the expenditure. Successful forwards will earn a routing fee which could > compensate for the loss in hold fees too. "Be selectinve with whom you accept HTLCs from"... it always comes back to incentives to de-anonymize the network :( > I think this mechanism can create interesting dynamics on the network and > eventually reach an equilibrium that is still healthy in terms of > decentralization and privacy. I suspect that if you try to create a set of actual rules for nodes using actual numbers, I think you'll find you enter a complexity spiral as you try to play whack-a-mole on all the different ways you can exploit it. (This is what happened every time I tried to design a peer-penalty system). Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost, > > * I convince Rene to make a channel to me. > > You may succeed, but Rene is probably not going to pay you a hold fee because > you're untrusted. Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene relationships, not necessarily recouping these funds. > > > > * I connect to Joost. > > * I prepay to Joost. > > * I forward Me->Joost->Rusty->Rene->me. > > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > > the tr\*st that Rene has to Rusty. > > * When the HTLC reaches me, I dicker around and wait until it is about to > > time out before ultimately failing. > > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. > > But most importantly: you will have paid hold fees to Joost for the long lock > time of the htlc. This should keep you from even trying this attack. But I might be interested in paying money in order to damage your reputation with Rusty, and damaging the reputation of Rusty with Rene. Thus my capacity to disrupt the network is increased linearly by the number of hops involved, thus my point: I think what should be paid should be for the entire route, not the first hop. For that matter, how certain are you that Rene and Zeeman are not secretly the same person, have you seen them in the same room together? As I pointed out before, the main reason to engage in these attacks is to lock up the capacity of less-capitalized competitors in the payment forwarding business. Cases of slow payment resolution caused by intermediate nodes are more likely to be because of incompetence (crashing nodes, ISP disconnections, clumsy humans tripping on power supplies) than active malice. Thus, the primary motivated attackers are the ends of the payment: the payer and payee, who, in this attack, are coordinating with each other to lock up the funds of multiple other lesser-capacity nodes (and which might be a single node). To an extent, to protect against such attacks, we need to know the payer and payee and somehow judge their tr\*stworthiness --- but we want to not have to reveal their identities, since that works against our privacy. Hmmm. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Joost Jager writes: >> The LOW-REP node being out of pocket is the clue here: if one party >> loses funds, even a tiny bit, another party gains some funds. In this >> case the HIGH-REP node collaborating with the ATTACKER can extract some >> funds from the intermediate node, allowing them to dime their way to all >> of LOW-REP's funds. If an attack results in even a tiny loss for an >> intermediary and can be repeated, the intermediary's funds can be >> syphoned by an attacker. >> > > The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all > those failed payments and small losses and start to realize that something > strange is happening. I know the proposal isn't fully trustless, but I > think it can work in practice. > > >> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the >> preimage is even worse: >> >> - Attacker node `A` charging hold fees receives HTLC from victim `V` >> - `A` does not forward the HTLC, but starts charging hold fees >> - Just before the timeout for the HTLC would force us to settle onchain >>`A` just removes the HTLC without forwarding it or he can try to >>forward at the last moment, potentially blaming someone else for its >>failure to complete >> >> This results in `A` extracting the maximum hold fee from `V`, without >> the downstream hold fees cutting into their profits. By forwarding as >> late as possible `A` can cause a downstream failure and look innocent, >> and the overall payment has the worst possible outcome: we waited an >> eternity for what turns out to be a failed attempt. >> > > The idea is that an attacker node is untrusted and won't be able to charge > hold fees. The attacker controls both the sender and the HIGH-REP node. The sender doesn't need to be trusted, it just initiates a payment that is used to extract hold fees from a forwarding node. The HIGH-REP node doesn't lose reputation because from what we can witness externally the payment failed somewhere downstream. It does require an attacker to have a hold fee charging HIGH-REP node, yes, but he is not jeopardizing its reputation by having it fail downstream. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I > > would only waive the hold fee for high-reputation nodes. In that case, > > the attacker is still paying for the attack. I may be forced to take a > > small loss on the difference, but at least the larger part of the pain > > is felt by the attacker. The assumption is that this is sufficient > > enough to deter the attacker from even trying. > > The LOW-REP node being out of pocket is the clue here: if one party > loses funds, even a tiny bit, another party gains some funds. In this > case the HIGH-REP node collaborating with the ATTACKER can extract some > funds from the intermediate node, allowing them to dime their way to all > of LOW-REP's funds. If an attack results in even a tiny loss for an > intermediary and can be repeated, the intermediary's funds can be > syphoned by an attacker. > The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all those failed payments and small losses and start to realize that something strange is happening. I know the proposal isn't fully trustless, but I think it can work in practice. > Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the > preimage is even worse: > > - Attacker node `A` charging hold fees receives HTLC from victim `V` > - `A` does not forward the HTLC, but starts charging hold fees > - Just before the timeout for the HTLC would force us to settle onchain >`A` just removes the HTLC without forwarding it or he can try to >forward at the last moment, potentially blaming someone else for its >failure to complete > > This results in `A` extracting the maximum hold fee from `V`, without > the downstream hold fees cutting into their profits. By forwarding as > late as possible `A` can cause a downstream failure and look innocent, > and the overall payment has the worst possible outcome: we waited an > eternity for what turns out to be a failed attempt. > The idea is that an attacker node is untrusted and won't be able to charge hold fees. - Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > The idea is that the available prepaid hold fee balance is enough to > cover the worst case hold fee. Otherwise the forward won't happen. The main > difference with option B is that you pay a sum upfront which can be used to > cover multiple forwards. And that this payment is a separate Lightning > payment, not integrated with the add/fail/settle flow. I prefer option B, > but implementation effort is also a consideration. > > If the above is not done (i.e. if I only prepay Joost but not Rusty) then > it seems to me that the below remote attack is possible: > Indeed, the above isn't done. Z only prepays Joost, not rusty. > * I convince Rene to make a channel to me. > You may succeed, but Rene is probably not going to pay you a hold fee because you're untrusted. > * I connect to Joost. > * I prepay to Joost. > * I forward Me->Joost->Rusty->Rene->me. > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > the tr\*st that Rene has to Rusty. > * When the HTLC reaches me, I dicker around and wait until it is about to > time out before ultimately failing. > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. But most importantly: you will have paid hold fees to Joost for the long lock time of the htlc. This should keep you from even trying this attack. Thinking a little more deeply: it is in principle possible to give a > financial value to an amount of msat being locked for an amount of time. > For instance the C-Lightning `getroute` has a `riskfactor` argument which > is used in this conversion. > Basically, by being locked in an HTLC and later failing, then the > forwarding node loses the expected return on investment if instead the > amount were locked in an HTLC that later succeeds. > > Now, the cost on a forwarding node is based on the actual amount of time > that its outgoing HTLC is locked. > That is indeed the proposal, to give financial value to the sats and the htlc slot being locked for an amount of time. > When we consider multi-hop payments, then we should consider that the > initiator of the multi-hop payment is asking multiple nodes to put their > funds at risk. > > Thus, the initiator of a multi-hop payment should, in principle, prepay > for *all* the risk of *all* the hops. > > > If we do not enforce this, then an initiator of a multi-hop payment can > pay a small amount relative to the risk that *all* the hops are taking. > I understand that, but I think it might be a large enough shift in the incentives of the attacker. > Secondarily, we currently assume that forwarding nodes will, upon having > their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as > possible. > This is because the incoming HTLC would be locked and unuseable until they > claim their incoming HTLC, and the liquidity would not be usable for > earning more fees until the incoming HTLC is claimed and put into its pool > of liquidity. > However, if we make anything that is based on the time that a forwarding > node claims its incoming HTLC, then this may incentivize the forwarding > node to delay claiming the incoming HTLC. > Yes, that is the trust part again. > > > > B. Tightly integrated with the htlc add/fail/settle messages. When > an htlc is added, the maximum cost (based on maximum lock time) for holding > is deducted from the sender's channel balance. When the htlc settles, a > refund is given based on the actual lock time. An additional > `update_fee`-like message is added for peers to update their hold fee > parameters (fee_base and fee_rate). > > > > > > If I am a forwarding node, and I receive the preimage from the > outgoing HTLC, can I deliberately defer claiming the incoming HTLC > (pretending that the outgoing HTLC was taking longer than it actually took) > in order to reduce the amount I have to refund? > > > > Yes you can. That is the trust part, your peer trusts you not to do > this. If they don't trust you, they won't forward to you if you charge a > (high) hold fee. > > What happens if I charge a tiny hold feerate in msats/second, but end up > locking the funds for a week? > How does my peer know that even though I charge a tiny hold fee, I will > hold their funds hostage for a week? > That is the trust part also. > > > > In both cases the sender needs to trust its peer to not steal the > payment and/or artificially delay the forwarding to inflate the hold fee. I > think that is acceptable given that there is a trust relation between peers > already anyway. > > > > > > I am wary of *adding* trust. > > > You might trust someone to keep an eye on your snacks while you go > refill your drink, but not to keep an eye on your hardware wallet when you > do the same. > > > (Since consuming snacks and drinks and hardware wallets are human > activities, this should show that I am in fact a human.) > > > > So I am arguing that there is trust already between peers. Quite > considerable trust even in case of high on-chain fee conditions. The add
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
I think the mechanism can indeed create interesting dynamics, but not in a good sense :-) >> I can still establish channels to various low-reputation nodes, and >> then use them to grief a high-reputation node. Not only do I get to >> jam up the high-reputation channels, as a bonus I get the >> low-reputation nodes to pay for it! > > So you're saying: > > ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I > would only waive the hold fee for high-reputation nodes. In that case, > the attacker is still paying for the attack. I may be forced to take a > small loss on the difference, but at least the larger part of the pain > is felt by the attacker. The assumption is that this is sufficient > enough to deter the attacker from even trying. The LOW-REP node being out of pocket is the clue here: if one party loses funds, even a tiny bit, another party gains some funds. In this case the HIGH-REP node collaborating with the ATTACKER can extract some funds from the intermediate node, allowing them to dime their way to all of LOW-REP's funds. If an attack results in even a tiny loss for an intermediary and can be repeated, the intermediary's funds can be syphoned by an attacker. Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the preimage is even worse: - Attacker node `A` charging hold fees receives HTLC from victim `V` - `A` does not forward the HTLC, but starts charging hold fees - Just before the timeout for the HTLC would force us to settle onchain `A` just removes the HTLC without forwarding it or he can try to forward at the last moment, potentially blaming someone else for its failure to complete This results in `A` extracting the maximum hold fee from `V`, without the downstream hold fees cutting into their profits. By forwarding as late as possible `A` can cause a downstream failure and look innocent, and the overall payment has the worst possible outcome: we waited an eternity for what turns out to be a failed attempt. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost, > > > A. Prepayment: node pays an amount to its channel peer (for example via > > > keysend) and the channel peer deducts the hold fees from that prepaid > > > balance until it is at zero. At that point it somehow (in the htlc fail > > > message?) communicates Lightning's version of http 402 to ask for more > > > money. > > > > If the node has already forwarded the HTLC onward, what enforcement hold > > does the node have on the sender of the incoming HTLC? > > Presumably the sender of the HTLC has already gotten what it wanted --- an > > outgoing HTLC --- so how can the forwarding node enforce this request to > > get more money. > > The idea is that the available prepaid hold fee balance is enough to cover > the worst case hold fee. Otherwise the forward won't happen. The main > difference with option B is that you pay a sum upfront which can be used to > cover multiple forwards. And that this payment is a separate Lightning > payment, not integrated with the add/fail/settle flow. I prefer option B, but > implementation effort is also a consideration. Okay, so basically, it becomes something like this. * There exists a network Joost <-> Rusty <-> Rene * I connect to Joost. * I owe Rene some sats. * First, I prepay Joost directly a bunch of sats. * Joost is now willing to forward to Rusty, but Rusty is not yet willing to forward further. * I prepay Rusty a bunch of sats. * I effectively "spend" some of the prepaid service that I already paid to Joost in order to pay to Rusty. * Finally, using the prepay to Joost and Rusty, I now can route a payment to Rene. Is that approximately how it works out? Does it mean that Joost and Rusty have to know the source of the payment route? Worse, they have to keep track of prepaid fees from all nodes, not just their direct peers? If the above is not done (i.e. if I only prepay Joost but not Rusty) then it seems to me that the below remote attack is possible: * I convince Rene to make a channel to me. * I connect to Joost. * I prepay to Joost. * I forward Me->Joost->Rusty->Rene->me. * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and the tr\*st that Rene has to Rusty. * When the HTLC reaches me, I dicker around and wait until it is about to time out before ultimately failing. * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. --- Thinking a little more deeply: it is in principle possible to give a financial value to an amount of msat being locked for an amount of time. For instance the C-Lightning `getroute` has a `riskfactor` argument which is used in this conversion. Basically, by being locked in an HTLC and later failing, then the forwarding node loses the expected return on investment if instead the amount were locked in an HTLC that later succeeds. Now, the cost on a forwarding node is based on the actual amount of time that its outgoing HTLC is locked. When we consider multi-hop payments, then we should consider that the initiator of the multi-hop payment is asking multiple nodes to put their funds at risk. Thus, the initiator of a multi-hop payment should, in principle, prepay for *all* the risk of *all* the hops. If we do not enforce this, then an initiator of a multi-hop payment can pay a small amount relative to the risk that *all* the hops are taking. Secondarily, we currently assume that forwarding nodes will, upon having their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as possible. This is because the incoming HTLC would be locked and unuseable until they claim their incoming HTLC, and the liquidity would not be usable for earning more fees until the incoming HTLC is claimed and put into its pool of liquidity. However, if we make anything that is based on the time that a forwarding node claims its incoming HTLC, then this may incentivize the forwarding node to delay claiming the incoming HTLC. > > > > B. Tightly integrated with the htlc add/fail/settle messages. When an > > > htlc is added, the maximum cost (based on maximum lock time) for holding > > > is deducted from the sender's channel balance. When the htlc settles, a > > > refund is given based on the actual lock time. An additional > > > `update_fee`-like message is added for peers to update their hold fee > > > parameters (fee_base and fee_rate). > > > > If I am a forwarding node, and I receive the preimage from the outgoing > > HTLC, can I deliberately defer claiming the incoming HTLC (pretending that > > the outgoing HTLC was taking longer than it actually took) in order to > > reduce the amount I have to refund? > > Yes you can. That is the trust part, your peer trusts you not to do this. If > they don't trust you, they won't forward to you if you charge a (high) hold > fee. What happens if I charge a tiny hold feerate in msats/second, but end up locking the funds for a week? How does my peer know that even though I charge a tiny hold fee, I will hold
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > A crucial thing is that these hold fees don't need to be symmetric. A new > > node for example that opens a channel to a well-known, established > routing > > node will be forced to pay a hold fee, but won't see any traffic coming > in > > anymore if it announces a hold fee itself. Nodes will need to build a > > reputation before they're able to command hold fees. Similarly, routing > > nodes that have a strong relation may decide to not charge hold fees to > > each other at all. > > I can still establish channels to various low-reputation nodes, and then > use them to grief a high-reputation node. Not only do I get to jam up > the high-reputation channels, as a bonus I get the low-reputation nodes > to pay for it! > So you're saying: ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP If I were LOW-REP, I'd still charge an unknown node a hold fee. I would only waive the hold fee for high-reputation nodes. In that case, the attacker is still paying for the attack. I may be forced to take a small loss on the difference, but at least the larger part of the pain is felt by the attacker. The assumption is that this is sufficient enough to deter the attacker from even trying. > Operators of high reputation nodes can even make this profitable; doubly > so, since they eliminate the chance of any of those low-reputation nodes > every getting to be high reputation (and thus competing). > > AFAICT any scheme which penalizes the direct peer creates a bias against > forwarding unknown payments, thus is deanonymizing. > If you're an honest but unknown sender (initiating the payment) and you just pay the hold fee, I don't think there is a problem? The unknown forward will still be carried out by a high-rep node. Also need to keep in mind that the hold fee for quick happy flow payments is going to be tiny (for example when calculating back from a desired annual return on the staked channel capacity). And we can finally make these parasitic hodl invoice users pay for it! I guess your concern is with trying to become a routing node? If nobody knows you, you'll be forced to pay hold fees but can't attract traffic if you charge hold fees yourself. That indeed means that you'll need to be selective with whom you accept htlcs from. Put limits in place to control the expenditure. Successful forwards will earn a routing fee which could compensate for the loss in hold fees too. I think this mechanism can create interesting dynamics on the network and eventually reach an equilibrium that is still healthy in terms of decentralization and privacy. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Joost Jager writes: > This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value). > fee_base is in there to compensate for the usage of an htlc slot, which is > a scarce resource too. ... > > In both cases the sender needs to trust its peer to not steal the payment > and/or artificially delay the forwarding to inflate the hold fee. I think > that is acceptable given that there is a trust relation between peers > already anyway. > > A crucial thing is that these hold fees don't need to be symmetric. A new > node for example that opens a channel to a well-known, established routing > node will be forced to pay a hold fee, but won't see any traffic coming in > anymore if it announces a hold fee itself. Nodes will need to build a > reputation before they're able to command hold fees. Similarly, routing > nodes that have a strong relation may decide to not charge hold fees to > each other at all. I can still establish channels to various low-reputation nodes, and then use them to grief a high-reputation node. Not only do I get to jam up the high-reputation channels, as a bonus I get the low-reputation nodes to pay for it! Operators of high reputation nodes can even make this profitable; doubly so, since they eliminate the chance of any of those low-reputation nodes every getting to be high reputation (and thus competing). AFAICT any scheme which penalizes the direct peer creates a bias against forwarding unknown payments, thus is deanonymizing. > I'd also like to encourage everyone to prioritize this spam/jam issue and > dedicate more time to solving it. Obviously there is a lot more to do in > Lightning, but I am not sure if we can afford to wait for the real > adversaries to show up on this one. Agreed. It's a classic "it's not actually on fire *right now*" problem, so it does keep getting pushed back. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > A. Prepayment: node pays an amount to its channel peer (for example via > keysend) and the channel peer deducts the hold fees from that prepaid > balance until it is at zero. At that point it somehow (in the htlc fail > message?) communicates Lightning's version of http 402 to ask for more > money. > > If the node has already forwarded the HTLC onward, what enforcement hold > does the node have on the sender of the incoming HTLC? > Presumably the sender of the HTLC has already gotten what it wanted --- an > outgoing HTLC --- so how can the forwarding node enforce this request to > get more money. > The idea is that the available prepaid hold fee balance is enough to cover the worst case hold fee. Otherwise the forward won't happen. The main difference with option B is that you pay a sum upfront which can be used to cover multiple forwards. And that this payment is a separate Lightning payment, not integrated with the add/fail/settle flow. I prefer option B, but implementation effort is also a consideration. > B. Tightly integrated with the htlc add/fail/settle messages. When an > htlc is added, the maximum cost (based on maximum lock time) for holding is > deducted from the sender's channel balance. When the htlc settles, a refund > is given based on the actual lock time. An additional `update_fee`-like > message is added for peers to update their hold fee parameters (fee_base > and fee_rate). > > If I am a forwarding node, and I receive the preimage from the outgoing > HTLC, can I deliberately defer claiming the incoming HTLC (pretending that > the outgoing HTLC was taking longer than it actually took) in order to > reduce the amount I have to refund? > Yes you can. That is the trust part, your peer trusts you not to do this. If they don't trust you, they won't forward to you if you charge a (high) hold fee. > In both cases the sender needs to trust its peer to not steal the payment > and/or artificially delay the forwarding to inflate the hold fee. I think > that is acceptable given that there is a trust relation between peers > already anyway. > > I am wary of *adding* trust. > You might trust someone to keep an eye on your snacks while you go refill > your drink, but not to keep an eye on your hardware wallet when you do the > same. > (Since consuming snacks and drinks and hardware wallets are human > activities, this should show that I am in fact a human.) > So I am arguing that there is trust already between peers. Quite considerable trust even in case of high on-chain fee conditions. The added risk of being scammed out of these prepay sats may not be significant. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost, I would like some clarifications on this mechanism. > A. Prepayment: node pays an amount to its channel peer (for example via > keysend) and the channel peer deducts the hold fees from that prepaid balance > until it is at zero. At that point it somehow (in the htlc fail message?) > communicates Lightning's version of http 402 to ask for more money. If the node has already forwarded the HTLC onward, what enforcement hold does the node have on the sender of the incoming HTLC? Presumably the sender of the HTLC has already gotten what it wanted --- an outgoing HTLC --- so how can the forwarding node enforce this request to get more money. > B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is > added, the maximum cost (based on maximum lock time) for holding is deducted > from the sender's channel balance. When the htlc settles, a refund is given > based on the actual lock time. An additional `update_fee`-like message is > added for peers to update their hold fee parameters (fee_base and fee_rate). If I am a forwarding node, and I receive the preimage from the outgoing HTLC, can I deliberately defer claiming the incoming HTLC (pretending that the outgoing HTLC was taking longer than it actually took) in order to reduce the amount I have to refund? > In both cases the sender needs to trust its peer to not steal the payment > and/or artificially delay the forwarding to inflate the hold fee. I think > that is acceptable given that there is a trust relation between peers already > anyway. I am wary of *adding* trust. You might trust someone to keep an eye on your snacks while you go refill your drink, but not to keep an eye on your hardware wallet when you do the same. (Since consuming snacks and drinks and hardware wallets are human activities, this should show that I am in fact a human.) How about this? Before, when thinking about JIT routing, I suggested that a JIT-routing enabled forwarding node should only be willing to pay for the JIT rebalancing up to some fraction (less than 1.0) of the amount already earned from the outgoing channel, in order to protect against some attacks. And when the JIT-routing node does a rebalance in order to serve the forwarding, it should deduct the cost of the rebalance from its cumulative sum of earnings from that outgoing channel. The effect of the above is that the already-earned forwarding fees serves as a "level of trust" that the rebalancing in order to serve the outgoing forward will not be wasted. Perhaps intermediate nodes should limit incoming HTLCs from peers that have not given them a lot of successful forwards and earned forwarding fees from those forwards. i.e. if it is a new peer, you allow HTLCs up to a certain size, then if the outgoing HTLC is claimed quickly rather than slowly and you earn a good amount of fee, you might be willing to increase the limits of incoming HTLCs. This is effectively "growing trust". Of course, now we have to wonder about exit scams where a node manipulates you into increasing this "trust score" and later screwing you over when you are willing to accept larger total HTLCs Sigh. On the other hand, if you base this on the amount of fees you earn per unit time and deducting the converted risk of having your fees locked in outgoing HTLCs, then attackers have to effectively pay you forwarding fees first before they can attack you, and once they attack, they lose the accumulated score. So in some way, this system functions a little like pre-paid fees, except the pre-payment is in the actual pay-on-successful-forwarding of previous HTLCs you have forwarded. Maybe. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Hello list, Many discussions have taken place on this list on how to prevent undesired use of the Lightning network. Spamming the network with HTLCs (for probing purposes or otherwise) or holding HTLCs to incapacitate channels can be done on today's network at very little cost to an attacker. So far this doesn't seem to be happening in practice, but I believe that it is only a matter of time before it will become a real issue. Rate limits and other limits such as the maximum number of in-flight HTLCs increase the cost of an attack, but may also limit the capabilities of honest users. It works as a mitigation, but it doesn't seem to be the ideal solution. We've looked at all kinds of trustless payment schemes to keep users honest, but it appears that none of them is satisfactory. Maybe it is even theoretically impossible to create a scheme that is trustless and has all the properties that we're looking for. (A proof of that would also be useful information to have.) Perhaps a small bit of trust isn't so bad. There is trust in Lightning already. For example when you open a channel, you trust (or hope) that your peer remains well connected, keeps charging reasonable fees, doesn't force-close in a bad way, etc. What I can see working is a system where peers charge each other a hold fee for forwarded HTLCs based on the actual lock time (not the maximum lock time) and the htlc value. This is just for the cost of holding and separate from the routing fee that is earned when the payment settles. This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value). fee_base is in there to compensate for the usage of an htlc slot, which is a scarce resource too. I think the implementation of this is less interesting at this stage, but some ideas are: A. Prepayment: node pays an amount to its channel peer (for example via keysend) and the channel peer deducts the hold fees from that prepaid balance until it is at zero. At that point it somehow (in the htlc fail message?) communicates Lightning's version of http 402 to ask for more money. B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is added, the maximum cost (based on maximum lock time) for holding is deducted from the sender's channel balance. When the htlc settles, a refund is given based on the actual lock time. An additional `update_fee`-like message is added for peers to update their hold fee parameters (fee_base and fee_rate). In both cases the sender needs to trust its peer to not steal the payment and/or artificially delay the forwarding to inflate the hold fee. I think that is acceptable given that there is a trust relation between peers already anyway. A crucial thing is that these hold fees don't need to be symmetric. A new node for example that opens a channel to a well-known, established routing node will be forced to pay a hold fee, but won't see any traffic coming in anymore if it announces a hold fee itself. Nodes will need to build a reputation before they're able to command hold fees. Similarly, routing nodes that have a strong relation may decide to not charge hold fees to each other at all. This asymmetry is what is supposed to prevent channel jamming attacks. The attacker needs to pay hold fees to send out the payment, but when it comes back to the attacker after traversing a circular route, they won't be able to charge a hold fee to cancel out the hold fee paid at the start of the route. (Assuming the attacker node is not trusted.) A consequence for honest users is that payment attempts are no longer free. The cost should however be negligible for fast-failing attempts. Also senders will have to be a lot more selective when building a route. Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be costly. The hold fee scheme is a bit looser compared to previously proposed schemes (as far as I know...). It is purely an arrangement between channel peers and doesn't try to exactly compensate every hop for its costs. Instead trust relations that arguably exist already are leveraged to present a bill to the actor who deserves it. Interested to hear opinions about this proposal. I'd also like to encourage everyone to prioritize this spam/jam issue and dedicate more time to solving it. Obviously there is a lot more to do in Lightning, but I am not sure if we can afford to wait for the real adversaries to show up on this one. Cheers, Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev