I totally agree with the simplicity argument, I wanted to raise this because it's (IMO) an issue today because of the way we deal with on-chain fees, but it's less impactful once update_fee is scoped to some min_relay_fee.
Let's put this aside for now then and we can revisit later if needed. Thanks for the feedback everyone! Bastien Le lun. 12 oct. 2020 à 20:49, Olaoluwa Osuntokun <laol...@gmail.com> a écrit : > > 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@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev