I feel like I'm missing something about this fix:

source

The shared consensus code angle is what worries me most, every Elements sidechain inherits this until they pull the patch. ~lightning

@orangesurf has some interesting thoughts on this:

Brief notes on the liquid hack, followed by 3 open questions.

Brief notes:
Liquid has confidential transactions, which make use of range proofs to check transactions are valid without revealing the amounts bring sent.

These are computationally expensive (relative to most other operations) so a range-proof caching optimisation was introduced ~7 years ago which was intended to avoid re-doing the same calculations unnecessarily.

The cache checked

• the range-proof bytes
• the value commitment

The issue appears to be that it didn't check

• The asset type
• The output script

As a result is that a later output that reuses a prior outputs checked features can get a cached pass even when full verification would fail.

It seems that the cache is not persistent, so a reboot of a node (possibly amongst other things) will wipe the cache.

The error appears to have sat unexploited for 7 years, throughout numerous rewrites & modifications to the surrounding code by multiple people - no one individual bears responsibility for this and the mantra that many eyes make bugs shallow is hopium which must be rejected.

Note: Fable5 in Github Copilot found this bug with a simple "spot anything erroneous with this?" prompt on the PR which introduced the caching.

Open questions:

1. How did the exploit happen before the fix was widely deployed?

It seems that the liquid team did spot and fix this bug prior to the exploit

• The fix commit is dated Aug 3,
• The PR to master was opened on Sept 1st

However it's notable that there hasn't been a release/tag since the fix. Clearly the sideswap team weren't running a fixed build when this was exploited a week later. Given sideswap have the ability to peg-out it is surprising to me that they weren't informed, or if they were that they didn't update.

Perhaps the magnitude of this exploit was not well understood when the PR was made introducing the fix publicly to master.

2. Why did Sideshift allow the huge peg-out?

There was an assumption by many that the federation imposed restrictions on the peg-out's triggered by members of the federation - were those restrictions honored by Sideshift?

Separately, why were there not sanity checks on the total amount per peg-out, and the daily total peg-outs?

I think a major learning here is that sanity checking and manual review of large peg outouts would likely have avoided this, but the team may have their reasons for not wanting to be involved in that process whatsoever.

3. Why did https://t.co/Kqv2Oc9x8t and blockstream's explorer diverge?

It appears that the @liquidexplorer was not affected by the cache exploit - and rejected that transaction. Checking the monitoring page it seems the servers are running version 23.3.2 (released long before the fix was added to master). Was there some configuration which meant that this caching was not performed, or was regularly reset? I will dig into this area more to find out.

Elements (what functionaries who sign peg-outs run) is based on Bitcoin Core, but it lags a little because I'm sure they have to change things to work for Liquid.

source