Deposit transaction pending in mempool and CPFP

WORK IN PROGRESS

The following article is directed at users who have extensive knowledge of Bitcoin, and understand the nuances of the suggestions below. It is not advised to try one's luck as unforeseen consequences might happen.

Basic fee considerations

A trade on Bisq can only start after the deposit transaction has been mined into a block (one confirmation is enough), so the application will choose the optimal miner fee based on how mempool is busy at the moment the taker accepts the maker's offer. There are two different edge cases which Bisq is not able to account for, and that will delay the first confirmation, if not prevent it entirely from happening:

• sudden spikes of transactions in mempool (think when central exchanges decide to flood the blockchain with consolidation txs, or a new hype like inscriptions takes off)
• traders funding Bisq wallet at a fee which is too low to be confirmed in current mempool, and then using the unconfirmed utxo to fund the deposit tx (this will cause a Child Pays For Parent on the original funding tx -and possible unconfirmed precursors- that will decrease the effective fee rate of the actual deposit transaction)

Commonly, it is a combination of the two that happens: mempool becomes progressively busier, and at the same time one of the traders (or even worse, both) send funds from an external wallet to be used for the deposit transaction, selecting an inadequate fee that will bring down the effective fee rate.

What happens when fee is too low

Bitcoin transactions can either be confirmed, or not, so the deposit transaction will stay parked in mempool until one of two outcomes occurs:

• it is finally included in a block (trade will start normally, even if with a large initial delay)
• it will be purged out of mempool (no hard expiration limit on this, but if it happens both traders will need to do an SPV resync to let Bisq acknowledge the deposit tx never took place)

What can be done to speed things up

A common strategy to accelerate a Bitcoin transaction is called Child Pays For Parent (CPFP), and consists of spending one of the outputs (child) of an unconfirmed transaction (parent) at a high fee, so those miners who want to collect said high fee, will necessarily have to confirm both child and parent transactions (and that's why child pays for parent).

Calculating the fee you need to pay for the child, so the parent fee is bumped to the desired value, involves knowing the total size of all transactions, and absolute fees that are already on the table, but for practicality, let us say that if you want to double the effective fee rate of the parent, you need to use a fee that is 3 to 4 times more than the parent's original fee.

CPFP can only be done by the owner of the unconfirmed UTXO that will act as a child, so to examine the case where a deposit tx is stuck in mempool after Bisq wallet was funded at a low fee, these are the possible cases:

• trader sent funds to Bisq wallet at low fee, but has a change output of this funding that went back to his external wallet: trader has to send this change output to another address of the same external wallet, using a very high fee
• trader sent a whole UTXO to Bisq wallet, and used part of it to fund a deposit tx: he will have to do CPFP within Bisq, by going to Funds > Receive Funds, copy the first unused receive address, then go to Funds > Send Funds and, after selecting the unconfirmed UTXO(s), send the full amount to the Bisq address taken from the clipboard, enabling Use custom value at the bottom to manually choose a very high fee