-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add refund boost CPFP transaction if deposit tx does not get confirmed #287
Comments
If the deposit tx isn't confirmed any of the traders could just double spend the fee transaction to cancel the trade. It's probably not easy to handle gracefully in bitcoinj though, but otherwise that should be a cleaner and cheaper way to cancel when the deposit tx isn't confirming. |
EDIT: sorry have not read carefully before. Yes double spending the inputs to the deposit would be a possibility as well but as you mentioned it causes issues with the wallet. As far I remember a conflicting tx requires a spv resync. I was wondering to also combine it with the efforts in bisq-network/bisq#4899 for a emergency payout. So phrase it the other way: That emergency tool (and also the one we have already) could serve as the tool to achieve CPFP as well. Currently it is just designed around mediators and complexity with fee calculation for CPFP is not included. |
how do I run a spv resync???? |
This is not a place for support, but here's how: https://bisq.wiki/Resyncing_SPV_file |
This is vital functionality, but why don't you consider using Replace By Fee model of increasing fee? AFAIU it wouldn't require creating another (child) transaction, which essentially is also putting more stress on bitcoin network. It can lead to "fee-race" situation. In RBF model you just need to rebroadcast unconfirmed TX with a higher fee. Am I right? |
RBF is not supported in BitcoinJ and would cause lot of complications for the interactive process as the transactions would need to be redone. |
An alternative idea to #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).
The text was updated successfully, but these errors were encountered: