Why can't I append an UTXO unseen in the mempool in a replacement transaction? #15369

<!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

<!-- Describe the issue -->

[Setup]

I was trying the opt-in rbf feature by preparing the follow setup:

Available UTXO:
U1: 1BTC
U2: 2BTC
U3: 3BTC

TX1:
vin: [U1, U2]
vout: [Alice: 2.9999BTC]

TX2:
vin: [U1, U2, U3]
vout: [Alice: 2.9999BTC, Change: 2.9995BTC]

Both TX1 and TX2 have their input already marked as replaceable (I used nSequence: 0xffffff00),

<!--- What behavior did you expect? -->

[Expected Behaviour]

I expect the second transaction will replace the first one.

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

[Actual Behaviour]

bitcoind sendrawtransaciton CLI returns error when trying to broadcast the second transaction:

replacement-adds-unconfirmed, replacement f67ddaf7df71c376c5ac2c0d802b19334f9bb9d07e4ab88bf0f98b057797d8a3 adds unconfirmed input, idx 2 (code 64)

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

[Version]

bitcoind: 0.17.0.1

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- For the GUI-related issue on Linux provide names and versions of a distro, a desktop environment and a graphical shell (if relevant). -->

<!-- Any extra information that might be useful in the debugging process. -->

[Investigation]

After some investigation, I found that in the code https://github.com/bitcoin/bitcoin/blob/5cdb82111cc128d68ba5268eb94787110ce1fe6e/src/validation.cpp#L859 It checks that the vins have to be one of the previous vins used in the pool (If I understand the comment correctly).

Is this an expected behaviour? Because with this design, reusing the above setup, since the first setup I have already used up all the amount in U1 and U2, 2.9999BTC + 0.0001BTC fee. If I want to increase the fee, I must include another UTXO or I have to reduce the amount to spent in output to leave space for the relay fee.

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

Full comment:

https://github.com/bitcoin/bitcoin/blob/5cdb82111cc128d68ba5268eb94787110ce1fe6e/src/validation.cpp#L853-L856

So, in your case, the new input UB3 needs to be confirmed.

Thanks!

@promag May I know a bit more about the intention of making sure only confirmed UTXO are included in replacement transaction? I am trying to understand what it means for the term feerate junk.

If U3 was unconfirmed, you could use another low rate input for that one again. That would fill up the mempool (which is actually only maintained by local node rules) and this can repeat as long as you like to do so.

@yuhlau see b272ecfdb39f976dd61e35bacb22047da02b3416 in #6871.

Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. Keep in mind that general bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on freenode.