[bisq-network/proposals] Add refund boost CPFP transaction if deposit tx does not get confirmed (#287)

[chimp1984]

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

An alternative idea to https://github.com/bisq-network/proposals/issues/286 would be to allow traders to create an alternative payout tx from a deposit tx which got stuck in case miner fee was too low in the tx chain.

If the deposit tx is not confirmed after a certain number (e.g. about 3-5 days) both users would get displayed a popup explaining the context and suggesting to make a refund tx which refunds the trade amount to the seller and the deposits to both trades but also increases the miner fee so both traders will receive a bit less from that cose.

The way how the costs are calculated and distributed would be the same as in #286. 
There is not need that both peer are online at the same time. The peer who acts first on the popup will create a payout tx which serves as CPFP and send the half signed tx to the peer as mailbox message. As soon the peer goes online and the miner fee used in the peers tx matches his calculation (with some tolerance as time delay will change fee rate) he can accept the suggested payout and sign and publish the payout. With that the whole stuck chain should be released.
If the miner fee has changed too much in the meantime he can reject and make instead another suggestion and send that to the peer. On the peers side its the same, he can accept or reject and make another suggestion... This can be repeated until the miner fee of both peer is inside the tolerance window. 

I am not sure if we should allow that the peer does not accept at all, as that might lead to kind of extortion scenarios if the problem of follow up locked up txs is on the peers side (e.g. more risky for market makers). 

-- 
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/287
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201210/762c5a46/attachment.htm>