Re: [Lightning-dev] Why should funders always pay on-chain fees?
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 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 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 >> 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
Re: [Lightning-dev] Why should funders always pay on-chain fees?
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 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,
Re: [Lightning-dev] Why should funders always pay on-chain fees?
> 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 >
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Thanks (again) Antoine and Zman for your answers,
On the other hand, a quick skim of your proposal suggests that it still
> respects the "initiator pays" principle.
> Basically, the fundee only pays fees for HTLCs they initiated, which is
> not relevant to the above attack (since in the above attack, my node is a
> dead end, you will never send out an HTLC through my channel to rebalance).
> So it should still be acceptable.
I agree, my proposal would have the same result as today's behavior in that
case.
Unless your throw-away node waited for me to add an HTLC in its channel, in
that case I would pay a
part of the fee (since I'm adding that HTLC). That leans towards the first
of my two proposals,
where the funder always pays the "base" fee and htlc fees are split
depending on who proposed the HTLC.
The channel initiator shouldn't have to pay for channel-closing as it's
> somehow a liquidity allocation decision
I agree 100%. Especially since mutual closing should be preferred most of
the time.
That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
Yes, this is an issue, but the only way to fix it today is to never be the
funder, always be fundee
and I think that creates unhealthy, assymetric incentives.
This is a scenario where the other node will only burn you once; if you
notice that behavior you'll
be forced to pay on-chain fees, but you'll ban this peer. And if he opened
the channel to you, he'll
still be paying the "base" fee. I don't think there's a silver bullet here
where you can completely
avoid being bitten by such malicious nodes, but you can reduce exposure and
ban them after the fact.
Another note on using a minimal relay fee; in a potential future where
on-chain fees are always
high and layer 1 is consistently busy, even that minimal relay fee will be
costly. You'll want your
peer to pay for the HTLCs it's responsible for to split the on-chain fee
more fairly. So I believe
moving (slightly) away from the "funder pays all" model is desirable (or at
least it's worth
exploring seriously in order to have a better reason to dismiss it than
"it's simpler").
Does that make sense?
Thanks,
Bastien
Le mar. 6 oct. 2020 à 18:30, Antoine Riard a
écrit :
> Hello Bastien,
>
> I'm all in for a model where channel transactions are pre-signed with a
> reasonable minimal relay fee and the adjustment is done by the closer. The
> channel initiator shouldn't have to pay for channel-closing as it's somehow
> a liquidity allocation decision ("My balance could be better allocated
> elsewhere than in this channel").
>
> That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
>
> AFAICT, this issue is not solved by anchor outputs. A way to decentivize
> this kind of behavior from a malicious counterparty is an upfront payment
> where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher
> than the cost of going onchain. It should cost higher for the counterparty
> to withhold a HTLC than paying onchain-fees to close the channel.
>
> Or can you think about another mitigation for the issue raised above ?
>
> Antoine
>
> Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> a écrit :
>
>> 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
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Hello Bastien,
I'm all in for a model where channel transactions are pre-signed with a
reasonable minimal relay fee and the adjustment is done by the closer. The
channel initiator shouldn't have to pay for channel-closing as it's somehow
a liquidity allocation decision ("My balance could be better allocated
elsewhere than in this channel").
That said, a channel closing might be triggered due to a security
mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
can easily loop a HTLC forwarding on an honest peer. Then not cancel it
on-time to force the honest counterparty to pay onchain fees to avoid a
offered HTLC not being claimed back on time.
AFAICT, this issue is not solved by anchor outputs. A way to decentivize
this kind of behavior from a malicious counterparty is an upfront payment
where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher
than the cost of going onchain. It should cost higher for the counterparty
to withhold a HTLC than paying onchain-fees to close the channel.
Or can you think about another mitigation for the issue raised above ?
Antoine
Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :
> 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
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Good morning Bastien, > 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. This indeed seems to be one of those "unwritten rules", like the unwritten rule that SCRIPT opcodes can only look at the transaction they are in and cannot look at the block it got confirmed in, or previous blocks. My rough understanding is that it prevents this kind of griefing attack: * You have a node with channels balanced just as you like it, very lucrative, earning entire satoshis of routing fees per week. * I have a bunch of funds lying around, much larger than your liquidity. * I create a temporary throwaway node and have it make a large channel to you about equal to your liquidity. * I send out all of the funds on the new large channel, preferably to offchain-to-onchain swaps like Loop or Boltz. * This shrinks the outgoing liquidity you have available on your existing channels, making it difficult for you to route and earn routing fees -- in order to route, you need to have *both* incoming and outgoing liquidity. * If I do not make another channel with my new node, then you cannot rebalance offchain. * Since my new large channel is now exhausted, I can delete the throwaway node forever. * The `close_to` feature also allows me to arrange the funds to be closed to a cold-storage funds. * Or I can just keep the necessary keys to recover funds from the unilateral channel close broadcast by you later. * There is a reserve, but that is tiny, and if so I can probably afford to wait --- this is a game of chicken on who closes the channel, and since most of the channel is on your end, you are at a serious disadvantage. * You are now forced to unilateral close the channel so you can send it to an onchain-to-offchain swap and reload your channels into the proper balance it had before I attacked you. If the unilateral close on the channel were paid by you, then that is adding insult to injury. Thus, it is better if the unilateral close were paid by me, even if ultimately the unilateral close is performed by you. This is "initiator pays" principle. -- On the other hand, a quick skim of your proposal suggests that it still respects the "initiator pays" principle. Basically, the fundee only pays fees for HTLCs they initiated, which is not relevant to the above attack (since in the above attack, my node is a dead end, you will never send out an HTLC through my channel to rebalance). So it should still be acceptable. Regards, ZmnSCPxj > > 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
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Hi darosior, This is true, but we haven't solved yet how to estimate a good enough `min_relay_fee` that works for end-to-end tx propagation over the network. We've discussed this during the last two spec meetings, but it's still unclear whether we'll be able to solve this before package-relay lands in bitcoin, so I wanted to explore this as a potential more short-term solution. But maybe it's not worth the effort and we should focus more on anchors and `min_relay_fee`, we'll see ;) Bastien Le lun. 5 oct. 2020 à 15:25, darosior a écrit : > Hi Bastien, > > > 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). > > > Agreed. > However in an anchor outputs future the funder only pays for the > "backbone" fees of the channel and the fees necessary to secure the > confirmation of transactions is paid in second stage by each interested > party (*). It seems to me to be a reasonable middle-ground. > > (*) Credits to ZmnSCPxj for pointing this out to me on IRC. > > Darosior > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Hi Bastien, > 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). Agreed. However in an anchor outputs future the funder only pays for the "backbone" fees of the channel and the fees necessary to secure the confirmation of transactions is paid in second stage by each interested party (*). It seems to me to be a reasonable middle-ground. (*) Credits to ZmnSCPxj for pointing this out to me on IRC. Darosior___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Why should funders always pay on-chain fees?
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
