TL;DR: There might not be any such thing as a free lunch but in cryptoverse, there is something called the free options problem that pushed us to the state of quandary. This blog post details how we, at Boltz, fell prey to that. The brief timeline goes over what transpired at Boltz and how we recovered from it.
Introduction
Suppose that Alice agrees to sell 10 Litecoin for 1 ⚡Bitcoin to Bob, so the trade gets executed in the following steps:
Step 1)Bob will create an invoice for 1 ⚡Bitcoin and sends it to Alice
Step 2)Alice will generate a redeem script and address based on the hash of the preimage of the invoice
Step 3)Bob will send the on-chain Litecoin to this address
Step 4)Alice will pay the aforementioned invoice of Bob to get the preimage in order to be able to claim those 10 Litecoin
The aforementioned steps illustrate how a submarine swap between ⚡Bitcoin and Litecoin (buying ⚡Bitcoin by sending on-chain Litecoin) works. But there’s a catch, during that period of time, Bob can choose to delay sending his Litecoin to Alice’s address, for as long as Alice is annoyed enough to bail out of the agreement because the onchain HTLC times out. If the exchange rate changes in Litecoin’s favor, Bob would wait until the onchain timelock expires and keep his “more valuable Litecoin”. If however, the exchange rate tilts in Bitcoin’s favor, Bob would settle the payment and receive the Bitcoin at a discounted rate. Evidently, this gives an unfair advantage to Bob since Alice is left prone to Bob delaying his payment and take advantage of exercising his option to let the swap expire. Completely free of charge. This proves that the method of trade described above depends on the altruism of Bob and hence isn’t a foolproof system.
This problem is well studied in modern cryptography. Many research papers like How to Use Bitcoin to Design Fair Protocols have proposed workarounds. But a solution to the free options problem, which is a subset of the broader fair exchange problem, has been found to be impossible to solve so far without the use of a trusted third party. In the context of lightning powered exchanges, Corné Plooy, a researcher who earlier created a related thread pertaining to this on Lightning-Dev mailing list, proposed a solution that lowers the amount of trust needed to be placed on the third party in this scenario. This proposed solution, according to Plooy’s own admission, is far from perfect but we think that this is a step in the right direction and departure from the belief that a multi-asset lightning network and in turn exchange of different assets via lightning may not be economically viable.
How did this affect us at Boltz?
Simply put, WE GOT REKT
We started to observe suspicious bot trading activity on Boltz (albeit quite late) on the BTC/LTC pair. The attacker was making use of the free option exploit and waiting for the rate to sway to his favor, at which point, the attacker would go forward with the trade to churn out a profit. The Litecoin price increase in the month of May complemented this strategy and made it a lucrative exploit. We deployed our SWAT team to research this and realized that regular submarine swaps (paying ⚡ invoice via on-chain tx) on Boltz did not have a timeout. This major bug made it very easy for the malicious actor to carry out this attack as s/he could quite literally delay the release of the preimage forever. We quickly deployed a fix that made Boltz abort the normal swap when the on-chain timeout expired.
But the draining continued…
The fix proved to be inconsequential to our cause as the funds keep getting drained out. It turned out that, the block timeout, which was ~10 blocks for the Bitcoin’s blockchain, gave enough room to the attacker to continue with the offensive. In the process, a bug was discovered, which opened another attack vector: we miscalculated our fees. We were finally able to control the damage by fixing these two bugs. We decided to invest time building better internal toolings i.e robust warning system and periodic statistics updates that can help us track and deter any potential exploit earlier than we did this time around. We decided to move away from CryptoCompare for rates, and built a new rate calculation mechanism that takes the rates from the APIs of five popular exchanges, namely, Binance, Bitfinex, Coinbase Pro, Kraken, and Poloniex and averages them out to get a more “fair” rate for our users.
We apologize for any inconvenience caused by the downtime Boltz experienced in the past weeks. The code is now more robust than ever before and we are excited about a new big feature launch soon. Please watch out this space for more on it.
