📅 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
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 13:01:03
in reply to nevent1q…cwqw
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 13:01:03Event JSON
{
"id": "558ec02ab4dfb20dcc9103494a155d68b85fb1f21fffb182c8ae10bb2ec77412",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315663,
"kind": 1,
"tags": [
[
"e",
"fec71d3de654367615cc4717048ad27af6f514e566116a304019e8b84f85ddb2",
"",
"root"
],
[
"e",
"6a013ab7030c9333d439b126fb5d2171542b0b519c3a1d1194eef6e1e63939b5",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-10-16\n📝 Original message:\nMany good thoughts here.\n\nPersonally I think we should design any changes for a package-relay\nfuture, where the commitment can be 0-fee, update_fee doesn't longer\nexist and fees are only decided upon on channel close.\n\n- johan\n\n\nOn Wed, Oct 14, 2020 at 10:25 AM Bastien TEINTURIER via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e I totally agree with the simplicity argument, I wanted to raise this because it's (IMO) an issue\n\u003e today because of the way we deal with on-chain fees, but it's less impactful once update_fee is\n\u003e scoped to some min_relay_fee.\n\u003e\n\u003e Let's put this aside for now then and we can revisit later if needed.\n\u003e\n\u003e Thanks for the feedback everyone!\n\u003e Bastien\n\u003e\n\u003e Le lun. 12 oct. 2020 à 20:49, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e a écrit :\n\u003e\u003e\n\u003e\u003e \u003e It seems to me that the \"funder pays all the commit tx fees\" rule exists\n\u003e\u003e \u003e solely for simplicity (which was totally reasonable).\n\u003e\u003e\n\u003e\u003e At this stage, I've learned that simplicity (when doing anything that\n\u003e\u003e involves multi-party on-chain fee negotiating/verification/enforcement can\n\u003e\u003e really go a long way). Just think about all the edge cases w.r.t _allocating\n\u003e\u003e enough funds to pay for fees_ we've discovered over the past few years in\n\u003e\u003e the state machine. I fear adding a more elaborate fee splitting mechanism\n\u003e\u003e would only blow up the number of obscure edge cases that may lead to a\n\u003e\u003e channel temporarily or permanently being \"borked\".\n\u003e\u003e\n\u003e\u003e If we're going to add a \"fairer\" way of splitting fees, we'll really need to\n\u003e\u003e dig down pre-deployment to ensure that we've explored any resulting edge\n\u003e\u003e cases within our solution space, as we'll only be _adding_ complexity to fee\n\u003e\u003e splitting.\n\u003e\u003e\n\u003e\u003e IMO, anchor commitments in their \"final form\" (fixed fee rate on commitment\n\u003e\u003e transaction, only \"emergency\" use of update_fee) significantly simplifies\n\u003e\u003e things as it shifts from \"funding pay fees\", to \"broadcaster/confirmer pays\n\u003e\u003e fees\". However, as you note this doesn't fully distribute the worst-case\n\u003e\u003e cost of needing to go to chain with a \"fully loaded\" commitment transaction.\n\u003e\u003e Even with HTLCs, they could only be signed at 1 sat/byte from the funder's\n\u003e\u003e perspective, once again putting the burden on the broadcaster/confirmer to\n\u003e\u003e make up the difference.\n\u003e\u003e\n\u003e\u003e -- Laolu\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Mon, Oct 5, 2020 at 6:13 AM Bastien TEINTURIER via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Good morning list,\n\u003e\u003e\u003e\n\u003e\u003e\u003e It seems to me that the \"funder pays all the commit tx fees\" rule exists solely for simplicity\n\u003e\u003e\u003e (which was totally reasonable). I haven't been able to find much discussion about this decision\n\u003e\u003e\u003e on the mailing list nor in the spec commits.\n\u003e\u003e\u003e\n\u003e\u003e\u003e At first glance, it's true that at the beginning of the channel lifetime, the funder should be\n\u003e\u003e\u003e responsible for the fee (it's his decision to open a channel after all). But as time goes by and\n\u003e\u003e\u003e both peers earn value from this channel, this rule becomes questionable. We've discovered since\n\u003e\u003e\u003e then that there is some risk associated with having pending HTLCs (flood-and-loot type of attacks,\n\u003e\u003e\u003e pinning, channel jamming, etc).\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think that *in some cases*, fundees should be paying a portion of the commit-tx on-chain fees,\n\u003e\u003e\u003e otherwise we may end up with a web-of-trust network where channels would only exist between peers\n\u003e\u003e\u003e that trust each other, which is quite limiting (I'm hoping we can do better).\n\u003e\u003e\u003e\n\u003e\u003e\u003e Routing nodes may be at risk when they *receive* HTLCs. All the attacks that steal funds come from\n\u003e\u003e\u003e the fact that a routing node has paid downstream but cannot claim the upstream HTLCs (correct me\n\u003e\u003e\u003e if that's incorrect). Thus I'd like nodes to pay for the on-chain fees of the HTLCs they offer\n\u003e\u003e\u003e while they're pending in the commit-tx, regardless of whether they're funder or fundee.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The simplest way to do this would be to deduce the HTLC cost (172 * feerate) from the offerer's\n\u003e\u003e\u003e main output (instead of the funder's main output, while keeping the base commit tx weight paid\n\u003e\u003e\u003e by the funder).\n\u003e\u003e\u003e\n\u003e\u003e\u003e A more extreme proposal would be to tie the *total* commit-tx fee to the channel usage:\n\u003e\u003e\u003e\n\u003e\u003e\u003e * if there are no pending HTLCs, the funder pays all the fee\n\u003e\u003e\u003e * if there are pending HTLCs, each node pays a proportion of the fee proportional to the number of\n\u003e\u003e\u003e HTLCs they offered. If Alice offered 1 HTLC and Bob offered 3 HTLCs, Bob pays 75% of the\n\u003e\u003e\u003e commit-tx fee and Alice pays 25%. When the HTLCs settle, the fee is redistributed.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This model uses the on-chain fee as collateral for usage of the channel. If Alice wants to forward\n\u003e\u003e\u003e HTLCs through this channel (because she has something to gain - routing fees), she should be taking\n\u003e\u003e\u003e on some of the associated risk, not Bob. Bob will be taking the same risk downstream if he chooses\n\u003e\u003e\u003e to forward.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I believe it also forces the fundee to care about on-chain feerates, which is a healthy incentive.\n\u003e\u003e\u003e It may create a feedback loop between on-chain feerates and routing fees, which I believe is also\n\u003e\u003e\u003e a good long-term thing (but it's hard to predict as there may be negative side-effects as well).\n\u003e\u003e\u003e\n\u003e\u003e\u003e What do you all think? Is this a terrible idea? Is it okay-ish, but not worth the additional\n\u003e\u003e\u003e complexity? Is it an amazing idea worth a lightning nobel? Please don't take any of my claims\n\u003e\u003e\u003e for granted and challenge them, there may be negative side-effects I'm completely missing, this is\n\u003e\u003e\u003e a fragile game of incentives...\n\u003e\u003e\u003e\n\u003e\u003e\u003e Side-note: don't forget to take into account that the fees for HTLC transactions (second-level txs)\n\u003e\u003e\u003e are always paid by the party that broadcasts them (which makes sense). I still think this is not\n\u003e\u003e\u003e enough and can even be abused by fundees in some setups.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thanks,\n\u003e\u003e\u003e Bastien\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "cedd4ef25e0d6603e42bc799802404c0aa2419b139f7e61c6219906c3ac6e73e267d40f29718940224353adf9af672ec56fa3422aa46ec1e0d01c1b43fe6f642"
}