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 liquid.network 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.

> Now, maintainers, who provide the application, suddenly want users to just trust them without being able to easily verify what changed in a release. This is in clear conflict with the "don't trust, verify" approach. +1 on this, reject black box binaries