[bisq-network/proposals] Add Child-pays-for-parent (CPFP) support to avoid stuck deposit txs (#258)

chimp1984 notifications at github.com
Tue Sep 8 19:39:34 UTC 2020


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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/258
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200908/d26f8dc1/attachment-0001.html>


More information about the bisq-github mailing list