Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-05 📝 Original message: Good morning list, It ...
📅 Original date posted:2020-10-05
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/521584fe/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/521584fe/attachment.html>;