lnd keep transaction cancelled by RBF

[nicolasburtey]

Background

Send a tx to lnd from an outside wallet
Increase the fee on this same tx using RBF

lncli listunspent --unconfirmed_only shows both transaction instead of only the higher fees transaction.

( Note: doing a third tx with RBF will also keep the first two )

Your environment

• version of lnd: 0.12.1-beta
• which operating system (uname -a on *Nix): linux
• version of btcd, bitcoind, or other backend: bitcoind

[nicolasburtey]

may be a duplicate of #5225 ?

[wpaulino]

Yeah it is a duplicate of #5225, just that in your case the RBF transactions were incoming rather than outgoing. The issue with this is that unconfirmed funds are not considered safe, especially when it comes to RBF. We can't always assume the latest replacement will make it into the chain over others (even when it has the highest fee of all replacements).

[Roasbeef]

There's no guarantee that the latest one actually confirms, therefore the wallet always keeps around all variants.

[nicolasburtey]

I think even after the transaction has been confirmed, lnd still keep the original as unconfirmed. AFAIR, the problem went away after a lnd reboot.

[wpaulino]

I think even after the transaction has been confirmed, lnd still keep the original as unconfirmed. AFAIR, the problem went away after a lnd reboot.

@nicolasburtey I just tested this myself locally and wasn't able to reproduce: I sent coins to lnd from another wallet and RBF'd that transaction twice. I saw one output for each transaction before a block was mined. After a block was mined confirming the latest RBF attempt (the third transaction), lnd properly removed all other invalid outputs without a restart and only one confirmed UTXO exists. Is there a step that I'm missing?

[nicolasburtey]

@nicolasburtey I just tested this myself locally and wasn't able to reproduce: I sent coins to lnd from another wallet and RBF'd that transaction twice. I saw one output for each transaction before a block was mined. After a block was mined confirming the latest RBF attempt (the third transaction), lnd properly removed all other invalid outputs without a restart and only one confirmed UTXO exists. Is there a step that I'm missing?

maybe you can remove this step

I sent coins to lnd from another wallet

by using a coin that doesn't come from lnd (or at least not pending from lnd, ie: has enough confirmation)

otherwise, not sure if this is relevant, but the issue was on mainnet, and the other wallet being used was specter.

[wpaulino]

by using a coin that doesn't come from lnd (or at least not pending from lnd, ie: has enough confirmation)
otherwise, not sure if this is relevant, but the issue was on mainnet, and the other wallet being used was specter.

@nicolasburtey I used Bitcoin Core's wallet on testnet to send to lnd and do the RBF bumps.

[nicolasburtey]

so probably this bug is not deterministic?

maybe if this matters, the node having the issue have 1000+ onchain transactions.

[wpaulino]

@nicolasburtey I think if the replacement transactions ends up sending to a different address not related to lnd then this could also happen. Maybe this is what you experienced?

[nicolasburtey]

I don't think this was the case for me. it was a RBF to the same address, basically bumping fees to make sure it get confirmed quickly.

[Roasbeef]

So seems we tried to reproduce this in practice and we weren't able to? Just to clarify, until one of the transactions has fully confirmed you may see the dangling replacement transactions until one of them is properly confirmed. On top of that, when you "RBF", if you don't bump the fee of the transaction enough, it may not even propagate throughout the network, resulting in the last compliant bump being the one that ultimately confirms.

[qustavo]

I did reproduce this following @wpaulino's suggestion:

I think if the replacement transactions ends up sending to a different address not related to lnd then this could also happen.

My setup uses bitcoind-v22.0 and two lnd nodes (0.14 and 0.13)

I created and broadcasted an initial tx to send funds to the first node. listunspent lists the tx with 0 confirmations on the receiving node as expected.

Then I updated the previous tx's vout to point to the other node and the amount and broadcasted it. Now both nodes list the tx with 0 confirmations[1].

After mining 1 or more blocks, both nodes show the tx, the first node still displays 0 confirmation while the second updates the confirmations accordingly.

To create the first Tx I used:

bitcoin-cli createrawtransaction '[ {"txid": "$TX_ID", "vout":0, "sequence": 1} ]' '{"$DEST_ADDR_1": 49.9996}' 0 true
bitcoin-cli signrawtransactionwithwallet <output from the previous>
bitcoin-cli sendrawtransaction <output from the previous>

and to RBF (changes the address and amount):

bitcoin-cli createrawtransaction '[ {"txid": "$TX_ID", "vout":0, "sequence": 1} ]' '{"$DEST_ADDR_2": 49.9995}' 0 true
bitcoin-cli signrawtransactionwithwallet <output from the previous>
bitcoin-cli sendrawtransaction <output from the previous>

After mining a block, the first node should not list the tx since it has been RBF, instead it is stuck there.

1: At this point bitcoind's listunspent only shows one tx (the latest).

[arshbot]

We're seeing this issue affect people at Voltage, particularly while developing Surge. Is it possible to have this endpoint return the value of the most recent RBF'd transaction (or the one with the highest fee)?