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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
