📅 Original date posted:2018-06-15
📝 Original message:
Despite the dynamic stuff, IIUC a minimum of 1000 sat / kbyte is still enforced (in AcceptToMemoryPoolWorker), unless the user also sets -minrelaytxfee:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L736
Most lnd nodes probably use btcd either directly or through neutrino (which is not implemented for Bitcoin Core yet). So they wouldn’t notice the issue immediately, or at all if those nodes are well connected.
However, in order to get mined, your transaction likely needs to pass through at least one bitcoind node, so keeping at least the above minimum in mind seems wise.
Default minimums aside I agree with Laolu: the problem with dynamic minimum relay fees is that many nodes - including your own! - might never relay your transaction if the fee is on the low end of the permitted range. Even the default 300 MB mempool setting only fits ~150 blocks (1 day) worth of transactions. That creates a problem if you use fees based on e.g. having a full week to close a channel, you better make sure your node is well connected or somehow warns you otherwise.
Sjors
> Op 6 jun. 2018, om 03:06 heeft Olaoluwa Osuntokun <laolu32 at gmail.com> het volgende geschreven:
>
> > 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Sjors Provoost [ARCHIVE] /
npub1ux…7wq7p
2023-06-09 12:50:47
in reply to nevent1q…ry0s
Author Public Key
npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pPublished at
2023-06-09 12:50:47Event JSON
{
"id": "b5a1b53dd1c9cd87f9ec4fb122ab2f2f5aa111e336e96a86d0d99b4c8c3af768",
"pubkey": "e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e",
"created_at": 1686315047,
"kind": 1,
"tags": [
[
"e",
"e837c451d5e726749c139d36b0759d7c94dbf7b6b988d3a42fc502ac2c6e2c3f",
"",
"root"
],
[
"e",
"6bb1887321502b7c3b5997c3ff2e1c6a7c19a48f395de986311f310549080ca8",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2018-06-15\n📝 Original message:\nDespite the dynamic stuff, IIUC a minimum of 1000 sat / kbyte is still enforced (in AcceptToMemoryPoolWorker), unless the user also sets -minrelaytxfee:\n\nhttps://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L736\n\nMost lnd nodes probably use btcd either directly or through neutrino (which is not implemented for Bitcoin Core yet). So they wouldn’t notice the issue immediately, or at all if those nodes are well connected.\n\nHowever, in order to get mined, your transaction likely needs to pass through at least one bitcoind node, so keeping at least the above minimum in mind seems wise.\n\n\nDefault minimums aside I agree with Laolu: the problem with dynamic minimum relay fees is that many nodes - including your own! - might never relay your transaction if the fee is on the low end of the permitted range. Even the default 300 MB mempool setting only fits ~150 blocks (1 day) worth of transactions. That creates a problem if you use fees based on e.g. having a full week to close a channel, you better make sure your node is well connected or somehow warns you otherwise.\n\nSjors\n\n\n\u003e Op 6 jun. 2018, om 03:06 heeft Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e het volgende geschreven:\n\u003e \n\u003e \u003e In this case, a 250 sat/kweight feerate is too low for Bitcoin to broadcast,\n\u003e \u003e and thus will be too low for timely processing (since it will *never* be put\n\u003e \u003e in a block, the processing time will be infinite).\n\u003e \n\u003e If by \"Bitcoin\" you mean Satoshi's client, then the latest instance will\n\u003e actually _dynamically_ regulate its min fee rate [1]. As a result, we can't\n\u003e just all agree to some static fee floor, as nodes on the network will\n\u003e regulate their min fee rate accordingly deepening on the size of their\n\u003e mempools. If a large fee spike occurs, then even a value of 253 may be too\n\u003e low. As a result, setting a static fee floor is only a temporary measure,\n\u003e that may cease to work at an unknown time (or even if nodes are configured\n\u003e to have very small mempools if they have low memory).\n\u003e \n\u003e The best current candidate for managing these fee issues (without more\n\u003e liberal sighash flags) seems to be utilizing a permanent op_true output.\n\u003e Although this itself has its own issues...\n\u003e \n\u003e [1]: https://github.com/bitcoin/bitcoin/blob/0264836695a2c260fcc50f25a5e9962098a84647/src/txmempool.cpp#L983\n\u003e \n\u003e -- Laolu\n\u003e \n\u003e \n\u003e On Tue, May 29, 2018 at 12:39 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e Good morning laolu,\n\u003e \n\u003e\u003e 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. \n\u003e \n\u003e This: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-calculation\n\u003e \n\u003e sipa is the arbitrary unit used for weight, although I suppose there is no such thing anyway.\n\u003e \n\u003e\u003e \n\u003e\u003e 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. \n\u003e \n\u003e This: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee\n\u003e \n\u003e \u003e A receiving node:\n\u003e \u003e * if the `update_fee` is too low for timely processing, OR is unreasonably large:\n\u003e \u003e * SHOULD fail the channel.\n\u003e \n\u003e 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).\n\u003e \n\u003e If we do not immediately close, I believe the attack I described here is possible: https://github.com/ElementsProject/lightning/issues/1443#issuecomment-385541379\n\u003e \n\u003e 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.\n\u003e \n\u003e (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)\n\u003e \n\u003e\u003e \n\u003e\u003e Force closing asymmetrically penalizes the broadcaster atm, causing cl to waste on chain fees sweeping and also it must incur the time lock delay. \n\u003e \n\u003e Yes.\n\u003e \n\u003e 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?\n\u003e \n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e \n\u003e\u003e On Mon, May 28, 2018, 11:16 PM ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Hi all, but most especially non-c-lightning developers,\n\u003e\u003e \n\u003e\u003e Some time ago, C-lightning imposed a minimum 253 sat/ksipa feerate: https://github.com/ElementsProject/lightning/pull/1251\n\u003e\u003e \n\u003e\u003e The reason is that the BOLT spec specifies a fee computation that is not identical to how bitcoind computes fees.\n\u003e\u003e \n\u003e\u003e 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).\n\u003e\u003e \n\u003e\u003e 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:\n\u003e\u003e \n\u003e\u003e * https://github.com/ElementsProject/lightning/issues/1351\n\u003e\u003e * https://github.com/ElementsProject/lightning/issues/1529\n\u003e\u003e \n\u003e\u003e (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 \u003c253)\n\u003e\u003e \n\u003e\u003e 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\n\u003e\u003e \n\u003e\u003e Eclair appears to have also imposed the same solution as C-lightning: https://github.com/ACINQ/eclair/commit/8981d45dd52c52abe60d5c00411d638dd2124b6f\n\u003e\u003e \n\u003e\u003e 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\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\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": "1e4b079314cbb3daa7d7c39c0b044d3ba4858f1b99d6fd49d7c43adf15468598984276bcdd352d953b2397cd898fd7e14f3f2b69b180b7485c10acb9aadf756e"
}