comit-network / xmr-btc-swap

Bitcoin–Monero Cross-chain Atomic Swap

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add CLI command to double-spend Bitcoin lock transaction funds if the transaction has no hopes of being confirmed

binarybaron opened this issue · comments

If the Bitcoin lock transaction is not getting confirmed due to the fee being too low, it can be challenging to refund the swap. If the transaction has not been confirmed within the first hour of the swap being initiated, there's no hope of the swap being successful because Alice has already given up.

AliceState::Started { state3 } => {
let tx_lock_status = bitcoin_wallet.subscribe_to(state3.tx_lock.clone()).await;
match timeout(
env_config.bitcoin_lock_mempool_timeout,
tx_lock_status.wait_until_seen(),
)
.await
{
Err(_) => {
tracing::info!(
minutes = %env_config.bitcoin_lock_mempool_timeout.as_secs_f64() / 60.0,
"TxLock lock was not seen in mempool in time",
);
AliceState::SafelyAborted
}
Ok(res) => {
res?;
AliceState::BtcLockTransactionSeen { state3 }
}
}
}

You have carefully monitor the transaction (sometimes for multiple weeks) and as soon as it is gets confirmed, you need to make sure to publish the refund transaction in time. This is quite annoying and can be mitigated by allowing the user to double-spend the funds using RBF (Replace-By-Fee).

I propose that we add add a flag --double-spend-unconfirmed-outgoing-funds flag to the withdraw-btc command and a --include-unconfirmed-outgoing-funds to the balance command. This'll allow the user to double spend those funds by publishing a RBF bitcoin withdraw transaction.

We can also add a new command rbf-unconfirmed-lock-tx that takes a swap id and double-spends only the inputs of the Bitcoin lock transaction that corresponds to that swap to a receive address of the internal Bitcoin wallet. Ideally, this'd even be integrated into the existing state machine. If we haven't seen the XMR Lock Transaction after a certain time has passed, we check if we can double-spend the Bitcoin lock tx.

Here are two instances of users experiencing this issue: UnstoppableSwap/unstoppableswap-gui#200, UnstoppableSwap/unstoppableswap-gui#202