📅 Original date posted:2020-10-12 📝 Original message: > It seems to me that the "funder pays all the commit tx fees" rule exists > solely for simplicity (which was totally reasonable). At this stage, I've learned that simplicity (when doing anything that involves multi-party on-chain fee negotiating/verification/enforcement can really go a long way). Just think about all the edge cases w.r.t _allocating enough funds to pay for fees_ we've discovered over the past few years in the state machine. I fear adding a more elaborate fee splitting mechanism would only blow up the number of obscure edge cases that may lead to a channel temporarily or permanently being "borked". If we're going to add a "fairer" way of splitting fees, we'll really need to dig down pre-deployment to ensure that we've explored any resulting edge cases within our solution space, as we'll only be _adding_ complexity to fee splitting. IMO, anchor commitments in their "final form" (fixed fee rate on commitment transaction, only "emergency" use of update_fee) significantly simplifies things as it shifts from "funding pay fees", to "broadcaster/confirmer pays fees". However, as you note this doesn't fully distribute the worst-case cost of needing to go to chain with a "fully loaded" commitment transaction. Even with HTLCs, they could only be signed at 1 sat/byte from the funder's perspective, once again putting the burden on the broadcaster/confirmer to make up the difference. -- Laolu On Mon, Oct 5, 2020 at 6:13 AM Bastien TEINTURIER via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > 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 > lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/148e00a3/attachment-0001.html>