rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 Original date posted:2020-10-06 📝 Original message: Hello Bastien, I'm all in for a model where channel transactions are pre-signed with a reasonable minimal relay fee and the adjustment is done by the closer. The channel initiator shouldn't have to pay for channel-closing as it's somehow a liquidity allocation decision ("My balance could be better allocated elsewhere than in this channel"). That said, a channel closing might be triggered due to a security mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty can easily loop a HTLC forwarding on an honest peer. Then not cancel it on-time to force the honest counterparty to pay onchain fees to avoid a offered HTLC not being claimed back on time. AFAICT, this issue is not solved by anchor outputs. A way to decentivize this kind of behavior from a malicious counterparty is an upfront payment where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher than the cost of going onchain. It should cost higher for the counterparty to withhold a HTLC than paying onchain-fees to close the channel. Or can you think about another mitigation for the issue raised above ? Antoine Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a écrit : > Good morning list, > > It seems to me that the "funder pays all the commit tx fees" rule exists > solely for simplicity > (which was totally reasonable). I haven't been able to find much > discussion about this decision > on the mailing list nor in the spec commits. > > At first glance, it's true that at the beginning of the channel lifetime, > the funder should be > responsible for the fee (it's his decision to open a channel after all). > But as time goes by and > both peers earn value from this channel, this rule becomes questionable. > We've discovered since > then that there is some risk associated with having pending HTLCs > (flood-and-loot type of attacks, > pinning, channel jamming, etc). > > I think that *in some cases*, fundees should be paying a portion of the > commit-tx on-chain fees, > otherwise we may end up with a web-of-trust network where channels would > only exist between peers > that trust each other, which is quite limiting (I'm hoping we can do > better). > > Routing nodes may be at risk when they *receive* HTLCs. All the attacks > that steal funds come from > the fact that a routing node has paid downstream but cannot claim the > upstream HTLCs (correct me > if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of > the HTLCs they offer > while they're pending in the commit-tx, regardless of whether they're > funder or fundee. > > The simplest way to do this would be to deduce the HTLC cost (172 * > feerate) from the offerer's > main output (instead of the funder's main output, while keeping the base > commit tx weight paid > by the funder). > > A more extreme proposal would be to tie the *total* commit-tx fee to the > channel usage: > > * if there are no pending HTLCs, the funder pays all the fee > * if there are pending HTLCs, each node pays a proportion of the fee > proportional to the number of > HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob > pays 75% of the > commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is > redistributed. > > This model uses the on-chain fee as collateral for usage of the channel. > If Alice wants to forward > HTLCs through this channel (because she has something to gain - routing > fees), she should be taking > on some of the associated risk, not Bob. Bob will be taking the same risk > downstream if he chooses > to forward. > > I believe it also forces the fundee to care about on-chain feerates, which > is a healthy incentive. > It may create a feedback loop between on-chain feerates and routing fees, > which I believe is also > a good long-term thing (but it's hard to predict as there may be negative > side-effects as well). > > What do you all think? Is this a terrible idea? Is it okay-ish, but not > worth the additional > complexity? Is it an amazing idea worth a lightning nobel? Please don't > take any of my claims > for granted and challenge them, there may be negative side-effects I'm > completely missing, this is > a fragile game of incentives... > > Side-note: don't forget to take into account that the fees for HTLC > transactions (second-level txs) > are always paid by the party that broadcasts them (which makes sense). I > still think this is not > enough and can even be abused by fundees in some setups. > > Thanks, > Bastien > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/eb3eaa1c/attachment.html>