Seems that an Elements rangeproof cache bug may've gotten exploited. Fix for suspicious issue was committed just last week and attackers could've monitored the public commits and exploited the bug before fix was ever pushed?

Sort of self-fulfilling prophecy if true, that's a leading theory anyhow.

fix: range proof cache bind to asset and scriptpubkey

https://github.com/ElementsProject/elements/commit/c26d719c2...

There’s kind of an interesting thread here about open source, which is usually thought of as more secure because of more eyes on the code, actually being less secure because an accidental merge can be exploited instantly with LLM’s monitoring. Is there a lot more security value in obscurity than before?

Why do they say it's white hat hackers?

Crypto is total scam, lives of many people have been destroyed, it only works until it runs out of fools.

How many forks and psyops until people realize?

I worked at blockstream back in 2017 and developed the original cryptographic range proofs which are the ancestors some of the involved code here. However, the vulnerabilities here and the whole liquid product as it exists today postdates my involvement in the company (while I was there it was under initial development but envisioned quite differently than what they eventually did), and I haven't followed any of it closely since.

But I gave this issue a quick look based on the transactions and github history.

Underlying issue was related to validation caching. Signatures and proofs are expensive to validate, to improve performance and prevent certain DOS attacks their validation is cached. It's important that the key used in the cache capture everything that goes into the validation decision (though to prevent some attacks its important not too much goes into the key, or an attacker can flood with valid proof attacked to insignificantly different transactions).

It appears to me that there was a longstanding vulnerability-- stemming back to the introduction of multiple-asset-support-- which could cause a consensus split/ddos. But on a lazy review I can't come up with any way of translating it into theft. I see how someone could make an invalid transaction that would be falsely accepted by nodes that have cache state from a constructed prior transaction, but the ways I can come up with results in the invalid transaction just burning assets--- not directly very useful. [Big asterisks on the non obviously exploitable here, I've only thought about it for a minute or two and I really know fairly little about assets support in Liquid-- but exploiting it would require being able to create a fake 'shadow' asset with the a generator that is the negation of a real asset.]

In any case: This was recently fixed, but the "fix" introduced a hash collision vulnerability: The new fields added to the hash were not delimited. Failing to include type information like lengths in hashes is a perennial problem in cryptographic protocols.

Imagine you have a protocol where you sign a {comment, command} tuple, each a string. If the protocol computes the hash by just concating the command and comment and they're variable length fields, then you could get a signature of {"boring comment containing dangerous command", "boring command"} but then present it to someone as {"boring comment containing ","dangerous command boring command"} and have the signature pass. That sort of thing.

This new vulnerability has a somewhat straight forward path to exploitation and prints funds out of thin air.

Based on some of the public comments about nodes rejecting the attack transaction, I'm guessing they rolled out the "fix" to the federation in advance of publishing the changes because they seem to have accepted an attack that everyone else was still rejecting.

Advanced private deployment of a 'fix' might have gave them the confidence to drop the fix on github with little fanfare as it was "already fixed", but doing so painted a target on the issue that remained. Interestingly, off the shelf open weight AI like Kimi K3 immediately identify the new vulnerability without any particularly artful prompting. Makes me wonder if "safe" AI played a role in the introduction of the new, more serious, vulnerability.

Interestingly, it looks like the funds are being returned: https://mempool.space/tx/3a3eac4a26395b8c2563aaf1eb8b1b77798...

I'm going to guess that anyone who actually knows more has their hands busy dealing with the return of the funds. I'm not sure if anyone has ever taken and then returned 1/3rd of a billion dollars worth of assets before.

I wonder how they'd ever cash out.

Is there any indications that this and the ColdCard heist could in fact be escaped distilled agents from the huggingface and similar attacks?

One disadvantage of decentralized money, criminals gain more power. Many such cases

$320m, not a bad haul.

More than enough to buy yourself a pardon if you get caught.

Crypto is a scam, lives of many people ruined, bitcoin is Epstein class owned.

Get rid of it.

[flagged]

“Inside job.”

It’s not "hackers". It’s an inside job, and a rug pull.

Time for bitcoin classic++?

I'm told by someone who threw AI at it that there may be a way to exploit the initial longstanding vulnerability by counting on the fact that updates to validation cache are non-atomic: You can make an invalid transaction that primes the cache before its rejected. But that these priming transactions can't propagate in the network (because they're invalid)... so getting them to the parties that need to sign the blocks might have been impractical to exploit.