Difference between revisions of "Deposit transaction pending in mempool and CPFP"
| Line 12: | Line 12: | ||
* 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) | * 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 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. | + | 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 a [[Resyncing SPV file|SPV resync]]) | ||
= To be continued = | = To be continued = | ||
Revision as of 21:59, 24 September 2023
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.
Contents
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 a SPV resync)
