Add Child-pays-for-parent (CPFP) support to avoid stuck deposit txs

[chimp1984]

If miner fee is volatile we are exposed to the risk that the tx never gets confirmed and the trade got stuck and a SPV resync is required to clean up the Bisq wallet. This problem gets increased by the potentail chain of unconfirmed transaction from any of both traders and by the fact that there the moment the miner fee is defined is not always the same as the time when the transaction is published (in case of the payout tx).

We have already a "hidden" and partial support for Child-pays-for-parent (CPFP) [1] in case the offer had a min. amount smaller than the amount and the taker choose to set the amount small than the max. amount of the offer. In that case the maker will receive a change from the amount he had reserved for the trade (which was the max. trade amount). The maker could do a CPFP transaction in case the deposit tx got stuck. It is not trivial to calculate the required fee (sum of all dependent unconfirmed transactions on both maker and taker side) and to ensure that output is used in the tx. To ensure that they maker can spend all available balance to a new own address. Better would be to create a tx with that particular output as input as well as the input to pay the miner fee. The coin selection feature in Bisq is not sophisticated enough to make that easy.
Further it might be not fair that the maker has to pay that fee specially in case the taker had a long chain of unconfirmed transactions.

Proposal:
We could add mandatory change outputs for both maker and taker to be used for potential CPFP.
Furthermore we could add some check at the maker or taker fee tx to see if there are unconfirmed txs in the dependency chain and if so check if they might be unconfirmed because of low fee. If that is the case try to bump the miner fee for the maker/taker fee tx so that the dependent tx chain has better chances to get confirmed. If that is done automatically we have a good basis to not need to deal with checking all the dependency chain later.
If the deposit tx gets stuck for too long both traders if they are online will make a CPFP tx to bump the deposit tx. Here we could extend it to check ones own tx chain (e.g. maker checks maker fee tx and the dep. chain) and include that as well in case those txs are still not confirmed and had too low fees. If both traders bump the fees on their side the total sum of miner fees for the whole chain should become enough for miners to take that tx chain. The costs are distributed fairly between both traders.

Potential issues:
If one trader is not online for longer we still might get a delay but as both traders need to be online to check the trade status this delay should not be too large. A potential problem is that some txs in the dependency chain might be wallet-foreign transactions and we might lack data. E.g if a trader gets funds via a tx with sufficient miner fee but that that tx was funded with too low miner fee. This tx might have be originated completely outside of Bisq context. The user does not want to pay in that case for bumping that tx. Another problem can be if the tx for receiving funds is very large (e.g. a CJ tx) and the trader does not want to pay a very high fee.
Another issue is how to deal with the case that the user does not have more funds left for bumping the tx fee.
Should we do it fully automated or ask the trader via UI if he confirms to the suggested transaction? Probably required to ask him to confirm but then how to deal if one trader is greedy and does not want to pay and delegates the risk for a stuck and failed trade to the peer. This could be also used intentionally tyo "cancel" a trade if price has moved a lot (e.g.. option trade problem).

Backward compatibility needs to be ensured as well. We could achieve that by adding a field in a trade message and check for that to see if the peer has updated as well and only use the feature in that case. Another option is to enforce it and set some activation time to enusure its widely deployed at enforcement time (via trade protocol version change or filter).

Conclusion:
I think it is technically possible to deal with the miner fee problem in that way but I fear it is rather complex and carries many potential issues. The easiest and fastest mitigation of the problem is to increase the miner fee estimation to be more on the safe side.

[1] https://en.bitcoin.it/wiki/Miner_fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29

[Bayernatoor]

The proposal does seem complex and since my understanding of it is limited I may not be the best to comment but I am concerned that this may lead to confusion for the users if they are required to intervene in any way, bump fees, be online at the same time(I know mediators often struggle to get both parties together) etc.

Having a user perform an SPV resync is already challenging at times. Removing any task from the user may be ideal.

I don't know how the Miner fee estimation works but couldn't we just refer to https://mempool.space/'s fee estimation and either go with med/high fee on all transactions? This would ensure that all transactions confirm in a reasonable time.

[MwithM]

@Bayernatoor

I don't know how the Miner fee estimation works but couldn't we just refer to https://mempool.space/'s fee estimation and either go with med/high fee on all transactions? This would ensure that all transactions confirm in a reasonable time.

That would lead to overpay some other transactions, which is also not desirable.

[Bayernatoor]

@MwithM

Ya I realize that but what option do we have. Is it better to overpay (the consequences of wanting to do on-chain transactions during a high fee period) or have the transactions hang, fail, which results in more mediation and fee reimbursements?

I assume allowing the user to pick between a low, med and high fee is probably not trivial to implement? It be interesting if we had 3 different miner fee estimations available and we could toggle the one we wanted.