Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-05 📝 Original message: > In this case, a 250 ...
📅 Original date posted:2018-06-05
📝 Original message:
> In this case, a 250 sat/kweight feerate is too low for Bitcoin to
broadcast,
> and thus will be too low for timely processing (since it will *never* be
put
> in a block, the processing time will be infinite).
If by "Bitcoin" you mean Satoshi's client, then the latest instance will
actually _dynamically_ regulate its min fee rate [1]. As a result, we can't
just all agree to some static fee floor, as nodes on the network will
regulate their min fee rate accordingly deepening on the size of their
mempools. If a large fee spike occurs, then even a value of 253 may be too
low. As a result, setting a static fee floor is only a temporary measure,
that may cease to work at an unknown time (or even if nodes are configured
to have very small mempools if they have low memory).
The best current candidate for managing these fee issues (without more
liberal sighash flags) seems to be utilizing a permanent op_true output.
Although this itself has its own issues...
[1]:
https://github.com/bitcoin/bitcoin/blob/0264836695a2c260fcc50f25a5e9962098a84647/src/txmempool.cpp#L983
-- Laolu
On Tue, May 29, 2018 at 12:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning laolu,
>
> What's a ksipa? lnd uses vsize internally for all fee estimation. FWIW,
> fees are extremely low on mainnet atm, we can thank the segwit capacity
> increase for that.
>
>
> This:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-calculation
>
> sipa is the arbitrary unit used for weight, although I suppose there is no
> such thing anyway.
>
>
> Why does cl unilaterally close in that case? Atm it's trivial for anyone
> to propose a low ball fee rate and cause a synchronized channel closure.
> The latest of such events resulted in over 250 channels being closed within
> 2 blocks.
>
>
> This:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee
>
> > A receiving node:
> > * if the `update_fee` is too low for timely processing, OR is
> unreasonably large:
> > * SHOULD fail the channel.
>
> In this case, a 250 sat/kweight feerate is too low for Bitcoin to
> broadcast, and thus will be too low for timely processing (since it will
> *never* be put in a block, the processing time will be infinite).
>
> If we do not immediately close, I believe the attack I described here is
> possible:
> https://github.com/ElementsProject/lightning/issues/1443#issuecomment-385541379
>
> Although it is entirely possible that I made a mistake, and the attack I
> gave is not possible. So, I want also to ask, if I am too naive in this
> attack and it is in fact not possible.
>
> (one wonders why the above "SHOULD fail the channel" is indicated in the
> BOLT spec, if the attack above (or a similar attack) is not possible)
>
>
> Force closing asymmetrically penalizes the broadcaster atm, causing cl to
> waste on chain fees sweeping and also it must incur the time lock delay.
>
>
> Yes.
>
> But I find it strange that lnd insists on a 250 sat/kweight, when, if we
> use the BOLT-02 algorithm for fee calculation, such a feerate would be
> rejected by bitcoind nodes for many transactions. Does not lnd encounter
> this issue?
>
> Regards,
> ZmnSCPxj
>
> On Mon, May 28, 2018, 11:16 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all, but most especially non-c-lightning developers,
>>
>> Some time ago, C-lightning imposed a minimum 253 sat/ksipa feerate:
>> https://github.com/ElementsProject/lightning/pull/1251
>>
>> The reason is that the BOLT spec specifies a fee computation that is not
>> identical to how bitcoind computes fees.
>>
>> Thus, the minimum 250 sat/ksipa feerate, if computed using the BOLT spec,
>> will result in a fee which bitcoind will compute as less than the minimum
>> 250 sat/ksipa it imposes (due to difference in how BOLT and bitcoind
>> compute feerates).
>>
>> Now C-lightning will not accept an onchain feerate (from `update_fee`) of
>> less than 253 sat/ksipa, precisely because of the above issue with the
>> divergence in how BOLT and bitcoind compute fees: anything less than 253
>> sat/ksipa, computed using the BOLT spec, will be rejected by bitcoind.
>> This results in a few issues in C-lightning where we close unilaterally
>> when the counterparty proposes a 250sat/ksipa feerate:
>>
>> * https://github.com/ElementsProject/lightning/issues/1351
>> * https://github.com/ElementsProject/lightning/issues/1529
>>
>> (C-lightning has increased the ranges recently, but the 253sat/ksipa
>> limit is a hard limit and will still cause C-lightning to unilaterally
>> close if the counterparty gives an `update_fee` of <253)
>>
>> Recently, Eclair discovered this same issue (i.e. bitcoind will not
>> broadcast a 250 sat/ksipa feerate tx when computed using the BOLT spec
>> algorithm): https://github.com/ACINQ/eclair/issues/602
>>
>> Eclair appears to have also imposed the same solution as C-lightning:
>> https://github.com/ACINQ/eclair/commit/8981d45dd52c52abe60d5c00411d638dd2124b6f
>>
>> ucoin (nayutaco/ptarmigan) also has 253 in a constant somewhere:
>> https://github.com/nayutaco/ptarmigan/blob/6fe9db418ec962bf1d9282bb5271750b7c5764c2/ucoin/include/ln.h#L73
>> https://github.com/nayutaco/ptarmigan/blob/315e49785aa3fa19d1291b4d40bfc6951f988cda/ucoind/monitoring.c#L147
>>
>> I am wondering whether lnd and lit have ever encountered issues with 250
>> sat/ksipa transactions getting propagated on the Bitcoin-level network. I
>> cannot find "253" in either codebase, suggesting that this minimum is not
>> imposed by lnd or lit.
>>
>> Regards,
>> ZmnSCPxj
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180605/5d7d209f/attachment.html>;
📝 Original message:
> In this case, a 250 sat/kweight feerate is too low for Bitcoin to
broadcast,
> and thus will be too low for timely processing (since it will *never* be
put
> in a block, the processing time will be infinite).
If by "Bitcoin" you mean Satoshi's client, then the latest instance will
actually _dynamically_ regulate its min fee rate [1]. As a result, we can't
just all agree to some static fee floor, as nodes on the network will
regulate their min fee rate accordingly deepening on the size of their
mempools. If a large fee spike occurs, then even a value of 253 may be too
low. As a result, setting a static fee floor is only a temporary measure,
that may cease to work at an unknown time (or even if nodes are configured
to have very small mempools if they have low memory).
The best current candidate for managing these fee issues (without more
liberal sighash flags) seems to be utilizing a permanent op_true output.
Although this itself has its own issues...
[1]:
https://github.com/bitcoin/bitcoin/blob/0264836695a2c260fcc50f25a5e9962098a84647/src/txmempool.cpp#L983
-- Laolu
On Tue, May 29, 2018 at 12:39 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning laolu,
>
> What's a ksipa? lnd uses vsize internally for all fee estimation. FWIW,
> fees are extremely low on mainnet atm, we can thank the segwit capacity
> increase for that.
>
>
> This:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-calculation
>
> sipa is the arbitrary unit used for weight, although I suppose there is no
> such thing anyway.
>
>
> Why does cl unilaterally close in that case? Atm it's trivial for anyone
> to propose a low ball fee rate and cause a synchronized channel closure.
> The latest of such events resulted in over 250 channels being closed within
> 2 blocks.
>
>
> This:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee
>
> > A receiving node:
> > * if the `update_fee` is too low for timely processing, OR is
> unreasonably large:
> > * SHOULD fail the channel.
>
> In this case, a 250 sat/kweight feerate is too low for Bitcoin to
> broadcast, and thus will be too low for timely processing (since it will
> *never* be put in a block, the processing time will be infinite).
>
> If we do not immediately close, I believe the attack I described here is
> possible:
> https://github.com/ElementsProject/lightning/issues/1443#issuecomment-385541379
>
> Although it is entirely possible that I made a mistake, and the attack I
> gave is not possible. So, I want also to ask, if I am too naive in this
> attack and it is in fact not possible.
>
> (one wonders why the above "SHOULD fail the channel" is indicated in the
> BOLT spec, if the attack above (or a similar attack) is not possible)
>
>
> Force closing asymmetrically penalizes the broadcaster atm, causing cl to
> waste on chain fees sweeping and also it must incur the time lock delay.
>
>
> Yes.
>
> But I find it strange that lnd insists on a 250 sat/kweight, when, if we
> use the BOLT-02 algorithm for fee calculation, such a feerate would be
> rejected by bitcoind nodes for many transactions. Does not lnd encounter
> this issue?
>
> Regards,
> ZmnSCPxj
>
> On Mon, May 28, 2018, 11:16 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all, but most especially non-c-lightning developers,
>>
>> Some time ago, C-lightning imposed a minimum 253 sat/ksipa feerate:
>> https://github.com/ElementsProject/lightning/pull/1251
>>
>> The reason is that the BOLT spec specifies a fee computation that is not
>> identical to how bitcoind computes fees.
>>
>> Thus, the minimum 250 sat/ksipa feerate, if computed using the BOLT spec,
>> will result in a fee which bitcoind will compute as less than the minimum
>> 250 sat/ksipa it imposes (due to difference in how BOLT and bitcoind
>> compute feerates).
>>
>> Now C-lightning will not accept an onchain feerate (from `update_fee`) of
>> less than 253 sat/ksipa, precisely because of the above issue with the
>> divergence in how BOLT and bitcoind compute fees: anything less than 253
>> sat/ksipa, computed using the BOLT spec, will be rejected by bitcoind.
>> This results in a few issues in C-lightning where we close unilaterally
>> when the counterparty proposes a 250sat/ksipa feerate:
>>
>> * https://github.com/ElementsProject/lightning/issues/1351
>> * https://github.com/ElementsProject/lightning/issues/1529
>>
>> (C-lightning has increased the ranges recently, but the 253sat/ksipa
>> limit is a hard limit and will still cause C-lightning to unilaterally
>> close if the counterparty gives an `update_fee` of <253)
>>
>> Recently, Eclair discovered this same issue (i.e. bitcoind will not
>> broadcast a 250 sat/ksipa feerate tx when computed using the BOLT spec
>> algorithm): https://github.com/ACINQ/eclair/issues/602
>>
>> Eclair appears to have also imposed the same solution as C-lightning:
>> https://github.com/ACINQ/eclair/commit/8981d45dd52c52abe60d5c00411d638dd2124b6f
>>
>> ucoin (nayutaco/ptarmigan) also has 253 in a constant somewhere:
>> https://github.com/nayutaco/ptarmigan/blob/6fe9db418ec962bf1d9282bb5271750b7c5764c2/ucoin/include/ln.h#L73
>> https://github.com/nayutaco/ptarmigan/blob/315e49785aa3fa19d1291b4d40bfc6951f988cda/ucoind/monitoring.c#L147
>>
>> I am wondering whether lnd and lit have ever encountered issues with 250
>> sat/ksipa transactions getting propagated on the Bitcoin-level network. I
>> cannot find "253" in either codebase, suggesting that this minimum is not
>> imposed by lnd or lit.
>>
>> Regards,
>> ZmnSCPxj
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180605/5d7d209f/attachment.html>;