> I think the problem of accidental channel closure is getting ignored by > devs. > > If we think any anti-DoS fee will be "insignificant" compared to the cost > of closing and reopening a channel, maybe dev attention should be on > fixing accidental channel closure costs than any anti-DoS fee mechanism. > > Any deterrence of the channel jamming problem is economic so if the > anti-DoS fee is tiny, then its deterrence will be tiny as well.
This struck me as an extremely salient point. One thing that has been noticeable missing from these discussions is any sort of threat model or attacker profile. Given this is primarily a griefing attack, and the attacker doesn't stand any direct gain, how high a fee is considered "adequate" deterrence without also dramatically increasing the cost of node operation in the average case? If an attacker has say a budget of 20 BTC to blow as they just want to see the world burn, then most parametrizations of attempt fees are likely insufficient. In addition, if the HTLC attempt/hold fees rise well above routing fees, then costs are also increased for senders in addition to routing nodes. Also IMO, it's important to re-state, that if channels are parametrized properly (dust values, max/min HTLC, private channels, micropayment specific channels, etc), then there is an inherent existing cost re the opportunity cost of committing funds in channels and the chain fee cost of making the series of channels in the first place. Based on the discussion above, it appears that the decaying fee idea needs closer examination to ensure it doesn't increase the day to day operational cost of a routing node in order to defend against threats at the edges. Nodes go down all the time for various reasons: need to allocate more disk, software upgrade, infrastructure migrations, power outages, etc, etc. By adding a steady decay cost, we introduce an idle penalty for lack of uptime when holding an HTLC, similar to the availability slashing in PoS systems. It would be unfortunate if an end result of such a solution is increasing node operation costs as a whole, (which has other trickle down effects: less nodes, higher routing fees, strain of dev-ops teams to ensure higher uptime or loss of funds, etc), while having negligible effects on the "success" profile of such an attack in practice. If nodes wish to be compensated for committing capital to Lightning itself, then markets such as Lightning Pool which rewards them for allocating the capital (independent of use) for a period of time can help them scratch that itch. Returning back to the original point, it may very well be the case that the very first solution proposed (circa 2015) to this issue: close out the channel and send back a proof of closure, may in fact be more desirable from the PoV of enforcing tangible costs given it requires the attacker to forfeit on-chain fees in the case of an unsuccessful attack. Services that require long lived HTLCs (HTLC mailboxes, etc) can flag the HTLCs as such in the onion payload allowing nodes to preferentially forward or reject them. Zooming out, I have a new idea in this domain that attempts to tackle things from a different angle. Assuming that any efforts to add further off-chain costs are insignificant in the face of an attacker with few constraints w.r.t budget, perhaps some efforts should be focused on instead ensuring that if there's "turbulence" in the network, it can gracefully degraded to a slightly more restricted operating mode until the storm passes. If an attacker spends coins/time/utxos, etc to be in position to distrust things, but then finds that things are working as normal, such a solution may serve as a low cost deterrence mechanism that won't tangibly increase operation/forwarding/payment costs within the network. Working out some of the kinks re the idea, but I hope to publish it sometime over the next few days. -- Laolu On Fri, Feb 12, 2021 at 8:24 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Joost, > > > > Not quite up-to-speed back into this, but, I believe an issue with > using feerates rather than fixed fees is "what happens if a channel is > forced onchain"? > > > > > > Suppose after C offers the HTLC to D, the C-D channel, for any reason, > is forced onchain, and the blockchain is bloated and the transaction > remains floating in mempools until very close to the timeout of C-D. > > > C is now liable for a large time the payment is held, and because the > C-D channel was dropped onchain, presumably any parameters of the HTLC > (including penalties D owes to C) have gotten fixed at the time the channel > was dropped onchain. > > > > > The simplicity of the fixed fee is that it bounds the amount of risk > that C has in case its outgoing channel is dropped onchain. > > > > The risk is bound in both cases. If you want you can cap the variable > fee at a level that isn't considered risky, but it will then not fully > cover the actual cost of the locked-up htlc. Also any anti-DoS fee could > very well turn out to be insignificant to the cost of closing and reopening > a channel with the state of the mempool these days. > > > I think the problem of accidental channel closure is getting ignored by > devs. > If we think any anti-DoS fee will be "insignificant" compared to the cost > of closing and reopening a channel, maybe dev attention should be on fixing > accidental channel closure costs than any anti-DoS fee mechanism. > Any deterrence of the channel jamming problem is economic so if the > anti-DoS fee is tiny, then its deterrence will be tiny as well. > > It seems to me that adding this anti-DoS fee *on top of* an accidental > channel closure is just adding insult to injury, when we should probably be > considering how to ameliorate the injury. > Otherwise forwarding nodes will themselves be deterred from operating at > all. > > > > > Is assuming increasing `hodl_fee_rate` along a payment path at odds > with the ordering of timelocks ? > > > > I don't think it is. > > In terms of privacy, this is more dangerous. > > The decrementing timelock already leaks an upper bound on the distance to > payee. > An incrementing holdfee leaks an upper bound on the distance to payer. > This translates to a single payment-part being more easily associated with > the payer and payee. > > > Regards, > ZmnSCPxj > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
