Stop #316 - The Layer 2 Apocalypse

“We are white hats. Contact us on-chain.”

On Sunday, September 6, someone included this message in a Bitcoin transaction. Around four hours earlier, their address had received nearly 4,000 bitcoin through a Liquid exploit.

Liquid is the sidechain developed by Blockstream on which L-BTC circulate, tokens that are supposed to be backed one-to-one by bitcoin held in custody by the federation. The mechanism makes it possible to transfer value across a network with different features, including confidential transactions and more frequent blocks, while maintaining a 1:1 peg with deposited BTC.

The attackers had managed to create around 4,000 L-BTC without depositing the corresponding bitcoin. They then used SideSwap to convert them into BTC. In its incident report, Liquid stated that the reserve held around 4,205 BTC before the exploit. After that withdrawal and other peg-outs processed before the suspension, 197 remained.

The same statement specified that no private keys appeared to have been compromised.

To understand how this was possible, we need to look at the flow of funds.

When a peg-in is made, bitcoin are deposited on the mainchain and their equivalent is credited on Liquid. The reverse process, the peg-out, burns L-BTC and releases BTC from the reserve. That reserve is held by the functionaries: federation servers that participate in the network's operation and in managing the link with Bitcoin.

The federation multisig requires eleven signatures out of fifteen. The keys are stored in dedicated hardware devices, HSMs. Spending the bitcoin therefore requires signatures from a sufficient number of functionaries.

There is also a restriction on destinations: peg-outs can reach addresses authorized through a Peg-out Authorization Key, or PAK. SideSwap owns one of these keys. The service receives the L-BTC, burns them, receives payment from the federation at one of its authorized destinations, and forwards the BTC to the customer.

The September 6 payment contains 83 inputs, each with the eleven signatures required by the standard branch. The script also contains an emergency path, with a different signature threshold and a timelock, which was not used in this case. The subsequent forwarding of nearly 3,996 BTC to the attackers' address was confirmed in the same Bitcoin block.

The software had recognized the L-BTC used to request that payment as valid. The multisig therefore authorized the spend based on incorrect accounting.

The origin of the issue was in Elements, the software on which Liquid is built, and concerned range proof verification. These cryptographic proofs make it possible to verify that the hidden amounts in confidential transactions fall within certain limits, preventing impossible values from being used to create money.

Verifying them requires work, so Elements caches positive results. When it encounters a proof it considers already verified, it avoids repeating the calculation. The flaw lay in identifying the data being checked: different fields were concatenated without properly distinguishing their boundaries. Different combinations could therefore produce the same cache entry.

According to CertiK's analysis, the attackers exploited this ambiguity to have an inflationary transaction approved by reusing a positive result. The verification that should have rejected it was skipped.

In its own account, SideSwap says it installed on August 13 a security build privately provided to Liquid members. That version nonetheless accepted the exploit transaction. It remains unclear which binaries were run by individual functionaries and what the state of their caches was during the attack.

The emergency fix, released with Elements 23.3.4 on September 9, makes the separation of fields used by the cache unambiguous and also allows the cache to be disabled.

SideSwap acknowledged two responsibilities of its own: the PAK was online and payments were forwarded automatically; moreover, adequate controls on the size and frequency of withdrawals were missing. An order for around 4,000 L-BTC was processed without human review.

Meanwhile, Blockstream and the attackers communicated through OP_RETURN. Some of the messages were encrypted. On September 7, Blockstream published a signed confirmation that bridge nodes had been updated; the signature can be verified with its public PGP key.

That afternoon, 3,400 BTC were returned. Around 598.5 remained with the attackers. On September 9, a plain-text request followed: a 10% reward paid with Blockstream funds, accompanied by the threat of leaving L-BTC holders with a 15% loss.

On September 11, Blockstream publicly rejected the ransom demand, disputing the white hat label and announcing it would turn to authorities and industry operators to recover the funds. The approximately 598.5 BTC retained remain separate from any agreed bounty: no public agreement to that effect appears to have been documented.

At the time of writing, Liquid has resumed confirming transactions and SideSwap has reopened peg-ins. Peg-outs remain suspended. Adam Back has promised to restore 1:1 backing, without yet specifying how or when.

Even if the peg returns to 1:1.

Those using Liquid accepted a federation and its trade-offs. Trust, however, also included an assessment of the competence of those developing the software, distributing updates, and managing withdrawals. That is the assessment the disaster has destroyed.

An irregular issuance passed validation, obtained the necessary signatures, and turned nearly the entire reserve into a payment to the hackers. The recovery of most of the bitcoin came thanks to their decision to return them, after a negotiation. The luck involved in that return weighs heavily on the final outcome.

I hope every user fully recovers their funds. The work of those fixing the software and rebuilding the service deserves recognition. My assessment of the project's reliability, however, is now compromised.

A reserve can be replenished. Entrusting one's bitcoin to the same processes again requires a level of trust that, as far as I am concerned, Liquid has exhausted.

And looking around, the alternatives on which we are supposed to make Bitcoin an everyday payment tool, a true medium of exchange, continue to demand far more trade-offs from users than their marketing campaigns are willing to admit.

In Stop #313, I analyzed Spark, adopted by wallets such as Wallet of Satoshi, Primal, Cake, Glow, and so on. Fast payments, offline receiving, no channel management by the user. The problem emerges when users want to recover their balance during an operator outage.

A wallet that makes on-chain fund recovery dependent on operators remains de facto custodial in practical use, even if it gives the user a seed.

With Bark, the Ark implementation developed by Second, the problem takes another form.

The balance is represented by VTXOs, virtual outputs built through pre-signed transactions. According to Second's documentation, those created through an on-chain entry or refresh on its server have a lifespan of 28 days. For those derived from Lightning payments received, the lifespan is 1-3 days. These are configurable parameters; a received VTXO may have already used up part of its lifetime.

Before expiry, VTXOs must be refreshed or the return on-chain must be completed. Upon expiry, the server gains the ability to claim the bitcoin through the protocol's timelocked path. The user may still attempt to exit while the funds remain available, but their exclusive control has been lost.

The phone can remain offline between operations. It must, however, come back online in time for the wallet to complete maintenance. Second's terms, section 1.6, state that the company may claim funds from expired VTXOs and assumes no obligation to return them.

Self-custody, with calendar reminders - preferably working ones.

I will not discuss the world of e-cash, including Fedimint, because these are openly and explicitly custodial solutions.

In this landscape, the exception I am willing to endorse is Phoenix, the Lightning wallet by ACINQ.

The model is that of the Lightning Service Provider: an operator provides connectivity and liquidity, while the wallet runs Lightning and manages the user's channel. Splicing makes it possible to resize that channel whenever funds need to be added or removed. ACINQ takes on the infrastructure work that makes the service usable.

The problem is that, as under the sheets, on Lightning size matters. At the time of writing, the ACINQ node explorer reports around 361 BTC in public capacity and 1,836 active channels. Capacity is the total value of observed channels, distinct from the liquidity available in each direction. It nonetheless gives an idea of the infrastructure supporting the service.

Phoenix shows the model I currently consider convincing for payments: Lightning, an LSP with adequate resources, and an on-chain exit route. Costs and technical requirements remain, but day-to-day management is made accessible by infrastructure that does its job.

The rest of the landscape leads me to a rather harsh judgment: Bitcoin - the real one, designed without compromises on custody - as a payment method for the general public is still technologically immature.

As of today, the fixed point remains on-chain. And perhaps, in this period of constant AI-driven attacks, it is better to play it safe by relying on the solidity of the good old UTXO.

Stay safe out there.