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