TL;DR: This new feature will allow for instant swaps without having to wait for confirmations of on-chain transactions.
We are excited to announce a new feature update which will make the trading experience on Boltz as seamless and instant as ever. User experience is paramount to our cultural ethos at Boltz and when our users speak, we ardently listen; based on the feedback we decided to empower our users with an option to fast track the trade using 0 confirmation if certain preconditions are met, which are further described in this article.
Introduction
As the name implies, 0-confirmations are transactions that have been broadcasted but did not receive any confirmations yet i.e. the state where the transaction is yet to be included in a block. In the current architecture, an on-chain bitcoin to lightning-bitcoin swap flow follows these intuitive steps:
- The user enters the swap amount and initiates the trade. In the successive window, she pastes the lightning invoice of the ⚡bitcoin she is ought to receive.
- User is prompted to download the refund.json file and is successively presented with a bitcoin on-chain address to send the funds to.
- After one confirmation on the Bitcoin’s blockchain, which takes ~10 minutes, the user receives the equivalent ⚡bitcoin in her lightning wallet.
It is rather apparent why, in many cases, the current flow might not make for ideal user experience. The user often wouldn’t have the patience to wait for 10 minutes to receive her funds and she could, in principle, choose to use any of the centralized alternatives for this very reason. We found that empowering the end-user with an option to receive the funds even before the transaction receives one-confirmation, by trading off a small amount of trust, results in orders of magnitude improvement of swap experience and therefore helps us avoid user churn.
In the famous quote replying to now EOS CTO Daniel Larimer (not sure he got it) Satoshi provided a framework and reinforced that a payment processor can verify the payments “well enough” in 10 seconds or less. This also reinforces the notion that if handled properly, low-value 0-conf transactions are not only safe but encouraged.
Caveats
We will start by explaining a very important feature of the Bitcoin protocol — Replace-by-Fee (RBF)
In laymen terms, it allows for the replacement of a transaction with a new version of the transaction, which is useful if the first transaction is stuck in the mempool because of low fees. The new version of the transaction can (and has to) pay more fees which will increase the probability of being included in a block. While this may be very useful for the free market that the Bitcoin protocol is hedging for, it comes with a serious drawback — a malicious actor can hypothetically double-spend the unconfirmed transaction using RBF. Because when a transaction is replaced with RBF it can not only change the amounts it is sending to the outputs but also change the outputs completely and redirect the unconfirmed transaction that way.
Consider a hypothetical scenario where Alice is a malicious actor who decides to scam Boltz. Alice initiates the swap of one ⚡bitcoin for one on-chain bitcoin. As explained in the Introduction section of this article, Alice sends the on-chain bitcoin to Boltz’s bitcoin address with a 0.0005 bitcoin as transaction fee. Boltz’s server notices the unconfirmed transaction and pays the user’s ⚡bitcoin invoice. Alice receives the ln payment and then goes forward and replaces the transaction from her wallet with her own address but with a higher fee of 0.001 bitcoin. Now since this replaced transaction has higher fees, miners are incentivized to include it in the block before the legitimate transaction. This results in Alice swapping 1 ⚡bitcoin from Boltz for merely 0.0015 bitcoin in transaction fees instead of the actual 1 bitcoin.
How does Boltz hedges against this risk?
To avoid the swindle as described in the aforementioned hypothetical case, Boltz employs a couple of precautionary measures: It checks for whether the transaction is signaling RBF (inherited or otherwise), in which case, the Boltz server would not pay the lightning invoice unless the legitimate transaction at least gets one confirmation. With the tradeoff for waiting longer (10 minutes in this case), Boltz could protect itself from malicious behavior from Alice. The second precautionary measure that would potentially discourage the use of this attack vector is a check by the Boltz server to concur if the fees are high enough for the transaction to be included in the next block. This eliminates the possibility where the attacker doesn’t even need to double-spend, but just send the transaction with very low fees that stay in mempool forever without getting mined.
Are users at risk?
As described before, when using Boltz for swapping on-chain coins for ⚡ lightning coins, the risk while very small, is on side of Boltz. If however, when the user decides to swap lightning coins for the on-chain coins, the minimal risk switches to the side of the user. Boltz also has a maximum threshold in place, which is currently 1 million satoshis and 125 million litoshis (currently ~100 USD), it further mitigates the risk as users sending transactions above these amounts won’t have an option to use the 0-conf feature.
Summary
The 0-conf feature allows us to empower users with a choice, a choice to trade off a small risk with a roughly 600x improvement in speed. Users who are not comfortable with this trade-off; stick with regular 1-confirmation on-chain transactions.
Further readings
- BIP 125: Opt-in Full Replace-by-Fee Signaling
- Bitcointalk discussion on RBF (Replace-by-Fee)
- A breakdown of the infamous bitcoin ATM hack that exploited 0-conf attack vector
