{"type":"rich","version":"1.0","title":"Bastien TEINTURIER [ARCHIVE] wrote","author_name":"Bastien TEINTURIER [ARCHIVE] (npub17f…ntr0s)","author_url":"https://yabu.me/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-10-05\n📝 Original message:\nGood morning list,\n\nIt seems to me that the \"funder pays all the commit tx fees\" rule exists\nsolely for simplicity\n(which was totally reasonable). I haven't been able to find much discussion\nabout this decision\non the mailing list nor in the spec commits.\n\nAt first glance, it's true that at the beginning of the channel lifetime,\nthe funder should be\nresponsible for the fee (it's his decision to open a channel after all).\nBut as time goes by and\nboth peers earn value from this channel, this rule becomes questionable.\nWe've discovered since\nthen that there is some risk associated with having pending HTLCs\n(flood-and-loot type of attacks,\npinning, channel jamming, etc).\n\nI think that *in some cases*, fundees should be paying a portion of the\ncommit-tx on-chain fees,\notherwise we may end up with a web-of-trust network where channels would\nonly exist between peers\nthat trust each other, which is quite limiting (I'm hoping we can do\nbetter).\n\nRouting nodes may be at risk when they *receive* HTLCs. All the attacks\nthat steal funds come from\nthe fact that a routing node has paid downstream but cannot claim the\nupstream HTLCs (correct me\nif that's incorrect). Thus I'd like nodes to pay for the on-chain fees of\nthe HTLCs they offer\nwhile they're pending in the commit-tx, regardless of whether they're\nfunder or fundee.\n\nThe simplest way to do this would be to deduce the HTLC cost (172 *\nfeerate) from the offerer's\nmain output (instead of the funder's main output, while keeping the base\ncommit tx weight paid\nby the funder).\n\nA more extreme proposal would be to tie the *total* commit-tx fee to the\nchannel usage:\n\n* if there are no pending HTLCs, the funder pays all the fee\n* if there are pending HTLCs, each node pays a proportion of the fee\nproportional to the number of\nHTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob\npays 75% of the\ncommit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is\nredistributed.\n\nThis model uses the on-chain fee as collateral for usage of the channel. If\nAlice wants to forward\nHTLCs through this channel (because she has something to gain - routing\nfees), she should be taking\non some of the associated risk, not Bob. Bob will be taking the same risk\ndownstream if he chooses\nto forward.\n\nI believe it also forces the fundee to care about on-chain feerates, which\nis a healthy incentive.\nIt may create a feedback loop between on-chain feerates and routing fees,\nwhich I believe is also\na good long-term thing (but it's hard to predict as there may be negative\nside-effects as well).\n\nWhat do you all think? Is this a terrible idea? Is it okay-ish, but not\nworth the additional\ncomplexity? Is it an amazing idea worth a lightning nobel? Please don't\ntake any of my claims\nfor granted and challenge them, there may be negative side-effects I'm\ncompletely missing, this is\na fragile game of incentives...\n\nSide-note: don't forget to take into account that the fees for HTLC\ntransactions (second-level txs)\nare always paid by the party that broadcasts them (which makes sense). I\nstill think this is not\nenough and can even be abused by fundees in some setups.\n\nThanks,\nBastien\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/521584fe/attachment.html\u003e"}