Max unconfirmed chainlength

Joukehofman commented at 1:06 pm on February 13, 2017: none

Describe the issue

Because transaction malleability isn’t that much of an issue lately, we’ve decided to let the wallet spend zero conf change. It has happened that we create a transaction just moments before a significant increase in (higher paying) transactions. Because of #9645, there is a chance that you end up with an unconfirmed chain of 24 child transactions. If you let the wallet produce a 25th child, it will return an error because the mempool won’t accept it. This is also problematic in the case we would like to cpfp the whole chain, because other nodes won’t relay the transaction to the miners.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Predict an increase in transactions. (You need a crystal ball)
Create transaction
Create more transactions
?
Profit

Expected behaviour

Ideally it would stop if the chain is 24 transactions long, so one could try a cpfp transaction to compensate for the fees.

Actual behaviour

It will create a transaction chain of 25 transaction, making it hard to have the whole chain confirmed in a certain time.

What version of bitcoin-core are you using?

Official binary: 0.13.1

Joukehofman commented at 1:17 pm on February 13, 2017: none

A quick way would be to have a setting for allowed length of unconfirmed transactions in the mempool, and push the cpfp-transaction on an other node.

jonasschnelli added the label Wallet on Feb 13, 2017

jonasschnelli commented at 1:29 pm on February 13, 2017: contributor

I think #9262 addresses that issue (partially?). This fix is available in 0.13.2 (as well as in 0.14). But #9262 is still disabled by default (DEFAULT_WALLET_REJECT_LONG_CHAINS = false;) @Joukehofman: You could try to upgrade to 0.13.2 and enable -walletrejectlongchains=true.

instagibbs commented at 1:34 pm on February 13, 2017: member

Yes -walletrejectlongchains sounds like what you want. It will simply reject the proposed transaction, allowing you to try something else.

Joukehofman commented at 1:38 pm on February 13, 2017: none

It is indeed what I want! Thanks for mentioning @jonasschnelli and fixing it @instagibbs !

Joukehofman closed this on Feb 13, 2017

instagibbs commented at 1:44 pm on February 13, 2017: member

Your use-case might be an argument for stopping 1 shorter even, to allow for a single CPFP in the mempool(with that one hitting the chain limit). As-is it might not quite work.

Joukehofman commented at 1:48 pm on February 13, 2017: none

Ah, I thought that was the intention, but you only catch it if mempool doesn’t accept the transaction. But, this option, combined with a setting for allowed mempool length would solve my issue in a nice way.

Joukehofman reopened this on Feb 13, 2017

instagibbs commented at 1:53 pm on February 13, 2017: member

Do note that there is no package relay for CPFP, so miners would have had to accepted the transactions into the mempool, but merely considered them too-low of a fee as a package.

Joukehofman commented at 2:02 pm on February 13, 2017: none

I know. As far as I can tell the transactions are being propagated on the network, they are seen by our other nodes, it’s just that the fees of those transactions start to lag behind the moment an uptrend in transactions is started.

morcos commented at 3:01 pm on February 13, 2017: member

@Joukehofman Take a look at -limitancestorcount and -limitdescendantcount (run bitcoind with -help –help-debug). These will limit all chains your node will accept/relay not just your own transactions, but could serve the purpose you want if you set them to limit your chains to 24 and then submit the 25th tx to the network via a different mechanism.

But if everyone started doing this, network relay would become a mess, so I do think a better solution could be for the wallet to try to stop one transaction shorter if -walletrejectlongchains is true.

TheBlueMatt commented at 3:33 pm on February 13, 2017: member

Yea, that also means you have to manually relay the 25th TX. We probably should stop one short by default (or provide an option to do so, somehow I thought we had…)

On February 13, 2017 4:01:18 PM GMT+01:00, Alex Morcos notifications@github.com wrote:

@Joukehofman Take a look at -limitancestorcount and -limitdescendantcount (run bitcoind with -help –help-debug). These will limit all chains your node will accept/relay not just your own transactions, but could serve the purpose you want if you set them to limit your chains to 24 and then submit the 25th tx to the network via a different mechanism.

But if everyone started doing this, network relay would become a mess, so I do think a better solution could be for the wallet to try to stop one transaction shorter if -walletrejectlongchains is true.

– You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9752#issuecomment-279415824

RHavar commented at 7:52 pm on February 21, 2017: contributor

What’s the issue in general with allowing long unconf chains? The risk if one of them is maliated and there’s a lot of wasted relay?

There’s certain times it’s pretty desirable to create some pretty massive chains, for example a service the does deposits and withdrawals. Deposits go into 1 wallet, withdrawals come out from another wallet. The deposit wallet batch sends money to the withdrawal wallet with an extremely low feerate (e.g. 10 sat/byte) for it to get confirmed when there’s not much network activity (e.g. weekends).

But this means the “withdrawal wallet” will be doing hundreds or thousands of sends for every receive it as, so by necessity create a long transaction chain and keep bumping into the unconfirmed chain limit pretty easily.

instagibbs commented at 7:54 pm on February 21, 2017: member

@RHavar haven’t thought about this a ton, but AFAIK it’s the tracking all the chains, which can be quite “wide” in a combinatorial sense, and updating package feerates, etc.

TheBlueMatt commented at 8:05 pm on February 21, 2017: member

The issue is the runtime of a bunch of things in the mempool is dependant on chain length, so allowing long chains is a very large potential DoS attack for the CPFP/mempool-size-limiting logic.

sipa commented at 8:13 pm on February 21, 2017: member

To be clear, these are reasons why there is a max unconfirmed chainlength in the mempool. They’re not necessarily reasons for disallowing them in the wallet - as the later parts of the chain can enter the mempool after the first ones get confirmed. However, the Bitcoin Core wallet uses the mempool as a means for checking likelihood of confirmations, so it rejects creation of things that wouldn’t enter.

morcos commented at 8:44 pm on February 21, 2017: member

@sipa I think by default it does not reject things that wouldn’t enter the mempool (although there is an option to do that). The default behavior is to create them and then periodically try to have them reaccepted to the mempool.

pinheadmz commented at 4:32 pm on March 16, 2017: member

adding 2 cents here, if -walletrejectlongchains=true were the default, I would have saved a lot of time yesterday! https://github.com/bitcoin/bitcoin/issues/10004

fanquake deleted a comment on Dec 10, 2018

MarcoFalke referenced this in commit f66c827c2d on Mar 25, 2022

MarcoFalke closed this on Mar 25, 2022

sidhujag referenced this in commit 92432625ce on Apr 2, 2022