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
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
