<div dir="ltr">Good morning list,<br><br>It seems to me that the "funder pays all the commit tx fees" rule exists solely for simplicity<br>(which was totally reasonable). I haven't been able to find much discussion about this decision<br>on the mailing list nor in the spec commits.<br><br>At first glance, it's true that at the beginning of the channel lifetime, the funder should be<br>responsible for the fee (it's his decision to open a channel after all). But as time goes by and<br>both peers earn value from this channel, this rule becomes questionable. We've discovered since<br>then that there is some risk associated with having pending HTLCs (flood-and-loot type of attacks,<br>pinning, channel jamming, etc).<br><br>I think that *in some cases*, fundees should be paying a portion of the commit-tx on-chain fees,<br>otherwise we may end up with a web-of-trust network where channels would only exist between peers<br>that trust each other, which is quite limiting (I'm hoping we can do better).<br><br>Routing nodes may be at risk when they *receive* HTLCs. All the attacks that steal funds come from<br>the fact that a routing node has paid downstream but cannot claim the upstream HTLCs (correct me<br>if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of the HTLCs they offer<br>while they're pending in the commit-tx, regardless of whether they're funder or fundee.<br><br>The simplest way to do this would be to deduce the HTLC cost (172 * feerate) from the offerer's<br>main output (instead of the funder's main output, while keeping the base commit tx weight paid<br>by the funder).<br><br>A more extreme proposal would be to tie the *total* commit-tx fee to the channel usage:<br><br>* if there are no pending HTLCs, the funder pays all the fee<br>* if there are pending HTLCs, each node pays a proportion of the fee proportional to the number of<br>HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob pays 75% of the<br>commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is redistributed.<br><br>This model uses the on-chain fee as collateral for usage of the channel. If Alice wants to forward<br>HTLCs through this channel (because she has something to gain - routing fees), she should be taking<br>on some of the associated risk, not Bob. Bob will be taking the same risk downstream if he chooses<br>to forward.<br><br>I believe it also forces the fundee to care about on-chain feerates, which is a healthy incentive.<br>It may create a feedback loop between on-chain feerates and routing fees, which I believe is also<br>a good long-term thing (but it's hard to predict as there may be negative side-effects as well).<br><br>What do you all think? Is this a terrible idea? Is it okay-ish, but not worth the additional<br>complexity? Is it an amazing idea worth a lightning nobel? Please don't take any of my claims<br>for granted and challenge them, there may be negative side-effects I'm completely missing, this is<br>a fragile game of incentives...<br><br>Side-note: don't forget to take into account that the fees for HTLC transactions (second-level txs)<br>are always paid by the party that broadcasts them (which makes sense). I still think this is not<br>enough and can even be abused by fundees in some setups.<br><br>Thanks,<br>Bastien</div>