Many good thoughts here. Personally I think we should design any changes for a package-relay future, where the commitment can be 0-fee, update_fee doesn't longer exist and fees are only decided upon on channel close.
- johan On Wed, Oct 14, 2020 at 10:25 AM Bastien TEINTURIER via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrote: > > 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev