[Lightning-dev] Imposing minimum 253 sat/ksipa feerate?

Mon Jun 18 09:22:07 UTC 2018

Good morning Sjors, Laolu, and list,

Indeed, I understand, this minimum of 1000 sat/kbyte (=250 sat/kweight), is imposed too, absolutely, regardless of dynamic blockchain conditions.

My logic, is, this is workaround for current conditions.

In current conditions, we often can get away with this minimum relay fee for fee rate.

But, we compute fee differently from bitcoind, which imposes this minimum relay fee.

Of course, we should use better dynamic fee paying later. But, requires blockchain-level softfork I think (at minimum, 0-value OP_TRUE output that can be spent only in current block).  Also, requires that LN impl, keep some money onchain for fee payment.

Currently, many channel failure occur between lnd and c-lightning, because of this imposed 253sat/ksipa feerate in c-lightning.  If lnd support same absolute minimum, this channel failure is reduced.  And then we have time, to make better dynamic fee system.

I think, SegWit blocksize increase, is sufficient to maintain low fees for some time until we can develop and deploy better dynamic fee system.

And we see this behavior (channel failure between lnd and c-lightning due to lnd too low feerate) especially during low feerate time, because of SegWit blocksize increase.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On June 15, 2018 7:39 PM, Sjors Provoost <sjors at sprovoost.nl> wrote:

> 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...
> > 
> > -- 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