Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-16 📝 Original message: Many good thoughts here. ...
📅 Original date posted:2020-10-16
📝 Original message:
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 at 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 <laolu32 at 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 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
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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 at 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 <laolu32 at 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 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
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev