You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases there are RBF trees which do not properly combine to make a 'full tree'. When this happens, one tree is left permanently unmined / unconfirmed and hangs around until the RBF tree expiry comes into effect (24H in default config).
In our testing we had two instances which share an electrs backend and the same bitcoind instance. One instance successfully combines everything, and the other has two distinct RBF trees.
The two instances don't have any difference in config.
Description
In some cases there are RBF trees which do not properly combine to make a 'full tree'. When this happens, one tree is left permanently unmined / unconfirmed and hangs around until the RBF tree expiry comes into effect (24H in default config).
In our testing we had two instances which share an electrs backend and the same bitcoind instance. One instance successfully combines everything, and the other has two distinct RBF trees.
The two instances don't have any difference in config.
Version
a66920c
Steps to reproduce
Not easy to intentionally reproduce, but can be observed in a running mempool instance on mainnet
Expected behaviour
RBF trees should always combine such that at least one TX will be confirmed
Actual behaviour
RBF trees can sometimes be split, and one tree is never mined
Screenshots
The text was updated successfully, but these errors were encountered: