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.
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'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.
it's reborn because you kill it every single night, but now to to save its own life the machine was reduced to this-- We're standing inside an external hard drive made up of people and and paper, Printing it all up at night and having them type it back in in the morning.
Concrete ZKP age verification schemes are hardly zero knowledge.
Imagine your idealized ZK address verification scheme. It would go something like: I show up at a website, it sends me some challenge, I send back a signature of the challenge that could only be made by someone with an of-age ID, but without specifying who. Everyone is happy.
Now little Johnny borrows my ID, and uses it to setup some oracle that provides ID validation for every kid and bot in the country. Woops.
To stop that you must compromise the idealized zero knowledge properties of the scheme, and in doing so you create the potential for harm/risk for everyone.
Sure, it's better than sending an ID card live feed to the dark web, but the risks of ID card theft are at least somewhat easy to understand.
Some of the threats to human rights don't even require the departure from the 'idealized' model-- as even the idealized model requires an ID issuer to issue the of-age person an ID. And so if the ID ZKP is widely required then the issuer can unperson you by simply declining to issue you an ID.
Which means the issuer has to be involved in every attestation and you aren't allowed to own/control your private key.
The government shouldn't know if/how many times I use my ID—you would be essentially building a country-wide blackmail database since it's a near direct proxy for porn usage. And it doesn't even matter if it's true, people will assume it anyway.
Your system effectively collects exactly the data ZKP is intended to protect.
Which is a long way of saying "ZKP" isn't an answer to this problem because you can't actually have zero knowledge in a system where people have little incentive to keep their key a secret.
My example is still just as good if the ID holder is complicit.
But also, this on-device fingerprint MFA would presumably be fairly bypassable. E.g. just glitch the device to extract the private key. ... and of course all the power hungry / extra complex ZKP machinery means less resources spent on preventing glitch attacks.
If they what they missed out on was selling the government tokens at a loss ... do they now have to pay the government the value of what they would have lost? :P
I take "It works better in the app" as confirmation that the app steals your data, tracks your location, etc. I wasn't going to run an 'app' in any case, but pushing confirms the decision.
> If the intermediate tokens represent reasoning or thought, you would expect "aha" to occur after the thoughts that led to the realisation, including the thoughts encoding the explanation: they don't have any other state.
Yes they do, they have their KV caches-- it's a pure function of the input tokens, sure but that doesn't prevent it from containing latent 'insight'. LLMs can and do pre-form the tokens they're expecting to output multiple steps in the future.
I wouldn't argue that the 'aha' means anything, but the structural argument that it can't that I think you're making isn't sound.
Indeed. And if someone then shares that output verbatim, they'll undermine their own credibility. They can guide the AI to tidy it up, or do it themselves. The issue is not in using AI for writing, but in not using it consciously.
They're acting as a meatbot being piloted by the AI. Could call them skroders.
It should be the other way around-- you give the AI instructions and it does stuff. Any time the AI is giving you instructions and you do stuff, that should be a big red flag.
I've been thinking about the Blight and [spoilers!] the skroderiders a lot lately. If you have read Fred Saberhagen's Berserker stories, I have also been thinking a lot about "goodlife" when I see some of the things that get posted. If you haven't, you might like them.
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.
reply