[bisq-network/proposals] Use CPFP to resolve stuck transactions from too low miner fees (#286)

[chimp1984]

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

## Problem

Fee estimation is a conceptual problem lacking a "perfect" solution. As relevant transactions in Bisq are created in an interactive context, some possible solutions like RBF [1] are not feasible. A stuck tx due too low miner fee which never gets confirmed can cause additional problems if the change outputs have been used for other offers and trades, leading to a cascade of failed trades. We had that experience in the past when fees have been spiking and sustained on a high level for longer period. The situation today might be a bit better as we have a better fee estimation service but it can happen again any time.

## Background

The miner fee for trade txs in Bisq is used from fee estimation services. Those give the best estimation at the current time but cannot look into the future. It can happen that just after the tx is published the fee increases a lot and sustain on a high level and mempool gets filled up for weeks. The settings how many txs are kept in the mempool is a local setting of any node but average I think it is about 2 weeks to get dropped from mempool if the tx was still not confirmed.
If the change outputs of such txs have been used for other offers and trades the problem escalates further as all those will never get confirmed as well, even if they might have used a better fee.

To use RBF comes with the problem that the trade txs would need to be recreated with the peer, requiring that both are online at the same time which is problematic. Furthermore any folllow up tx would need to be recreated as well if the parent tx change (tx, miner fee -> diff. change output). Beside that BitcoinJ has not implemented RBF ;-(.

We have the same problematic for attempts to create multiple txs with diff. fee levels and pre-sign all and broadcast the next higher fee tx in case the former does not get confirmed in time. That would also make change outputs basically un-usable.

To not allow to spend unconfirmed change outputs is for UX a no-go. One would need to wait each time after creating an offer until the tx is confirmed before being able to spend the outputs.

Note, that there are no security risk in the context of Bisq by spending unconfirmed outputs. The start of the trade requires a confirmation and that guaratees that the txs cannot be double spent. Double spent of any tx earlier would render the trade invalid. 

## Possible solution 

We could use CPFP [2] and add mandatory small outputs which gets reserved until the tx is confirmed. In case of a stuck tx we can use those change outputs for boosting the tx chain with CPFP.

The good thing with CPFP is that it can be applied after the fact without any prior requirements (beside that an output is available). We could add a mandatory output to each trader to the deposit tx and keep that utxo in a reserved state similar as we do it with reserved balance for the amount needed for an offer, but we should use a new model based on tx outputs not on addresses (as with the AddressEntry model) as that was a bad design choice. 
Once the tx is confirmed that utxo gets released and can be used for any future tx. 

If a tx gets stuck because of too low fees the app calculates the required fee to boost the tx chain to have more realistic chances to get confirmed. A tx spending the utxo is created and sufficient miner fee added so that miners take the whole tx chain to be able to earn the premium fee.

## Who pays for it?
An open problem is who of the traders is willing to make that tx and carries the costs for it. 
Another problem is that one of the traders could have a very long chain of unconfirmed txs used for funding the trade fee tx. It would be unfair to the peer to pay for that. 

So the protocol should detect who caused more cost to the chain. That user need to do the boost tx, it could/should be done automatically in the background.
The part of the cost caused from the peers side will be deducted at the payout tx, so the other peer will receive less than the normal security deposit. In case the peer is the seller and the deposit would not cover those costs (I guess that is unlikely) we could communicate it before the fiat or altcoin is sent so we deduct the cost from the transferred fiat/altcoin amount.
As this case seems to be rather rare, I think its acceptable to let the trade fail in such a case and leave it to mediation to resolve such a situation.
For the seller has done the tx and the costs exceed the deposit the buyer would receive less of the trade amount. The case that the trade amount is not sufficient as well will be very rare and can be treated as well manually via mediation.

### Cost calucaltion
Maker: 
- Cost for maker fee tx
- All depending txs of inputs of the maker fee tx

Taker:
- Cost for taker fee tx
- All depending txs of inputs of the taker fee tx
- Cost for deposit tx (as it is now)
- Cost for payout tx (as it is now)

It could be discussed if the costs for the deposit tx and payout tx should be shared in that case. The reason the taker pays for that in the current protocol is because the maker cannot know the required fee at maker offer time when he reserves the funds, so it has pure protocol technical reasons and was not intended conceptually.


[1] https://bitcoinops.org/en/topics/replace-by-fee/
[2] https://bitcoinops.org/en/topics/cpfp/


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