Blockstream lost my support when they showed themselves to be dishonorable after the backstabbing of the New York Agreement and immature taunting that followed. Now we have learned there was an Epstein connection there as a possible cause. Seeing them run to the police after bad faith negotiations and claiming “code is law” for years is exactly what I would expect from them.

I do have a new slogan for anyone thinking of using the Liquid Network. “Get Pegged” because that’s what it will feel like exchanging BTC for LBTC at a 1:1 peg.

Wild? No, this is exactly how you should deal with retards. The hack was probably committed by inexperienced individuals with the mental development of elementary school children that have figured out how to use AI tools. To believe or to claim that they are white hackers after they have committed a clear crime is beyond standard stupidity. This is the kind of toddler-like thinking where you believe that by making public claims you can change reality to your imagination. 

No ransoms should ever be paid, this is the core of cybersecurity. Fuck them and their bullshit. They deserve everything that is coming to them.  

It seems like you are the one with the mental development of an elementary school child who thinks and believes that some inexperienced individuals can exploit bugs and steal thousands of bitcoins by using AI tools. If a bunch of AI tools could help people with zero experience breach systems and steal cryptocurrencies, I believe we would see a few incidents on a daily basis considering how many people have got their hands on AI tools these days.

Blockchair didn't release that statement.

I agree with you, we are on the same mind regarding ransom. Since they're using the BTC as leverage in the negotiation.

But also, don't really like the action of Blockstream after getting 3,400 BTC back. They're the ones who make these hapens can be happen in the first place through their shitty security they have. They don't even have a clear bounty policy at all. Even a project with a clear bounty and having so much volunteer work for the security check can still get situations like these.

I don't see any words, at least "THANK YOU" for the 3,400 BTC back on the statement. At least the first word in the statement should be "THANK YOU" for 3,400 BTC, even though we don't like it at all, with the movement of those hackers who claim to be white-hats. A courtesy first would be very wise, and then they can continue making statements like that.

I think bounty programs from campaigns for programmers will likely disappear as a phenomenon and evolve into a bug audit service using the most powerful AI. In general, this activity will completely lose the enthusiasm of individuals and small groups, becoming a serious service reflected in requests to advanced AI campaigns (B2B): OpenAI, Anthropic. Or subscriptions, token purchases, etc.
And disaster awaits those IT projects who neglect this.

This year has already been the most high-profile in terms of AI hacks: KelpDAO, Drift, Coldcard, Moonwell, Term Finance, LiteLLM, TMXTribe...

Blockstream, striving to be as open and honest with its users as possible, released a very detailed analysis of the hack, but the problem is that all concerned users are already well aware of the entire chronology and details of these events. And in the comments, which aren't even closed, they, as expected, simply write that BS isn't going to return their money anyway.

https://x.com/Blockstream/status/2102879987841815031

I'm doubtful of both Blockstream and "red team"'s (past?) prowess at using AI for review.

After the exploitation, I used GLM-5.3-flash in my standard harness (with no internet access) and standard one-line review prompt and it immediately and correctly identified the vulnerability introduced by the incomplete fix, identified it as inflation, and even constructed a demonstration.  I tried several more times and had 100% success, so not just sampling luck.  I don't have any particularly relevant experience with the elements codebase (probably last used it in 2017) and have never used liquid, but even if I did it wouldn't have changed my approach.

I don't currently have K3 running locally and wasn't eager to make myself an investigation target by using it on this over an API (plus it's kind of expensive)-- but I'd be somewhat surprised if the same approach didn't get a similar result there.
 
Prompting style can make a dramatic difference on getting useful review vs useless sycophantic glazing.  Unfortunately the approaches that produce the most sensitive review also increase the false positive rate significantly so they're most effective in the hands of a subject matter expert rather than an outside reviewer.

My recommendations are:

Prior to the beginning of context, check out the entire system and dependencies, and get build & tests working, and have all documentation ready so an agent can build and run tests without any context wasting screwing around. After this point no internet access should be available, the initial review agent should not be given access to PR discussion or subsequent changes.  If an agent was used to perform the setup it should write handoff docs and review should begin with a fresh context.  Review context shouldn't be polluted with setup machinery or what other people think of the PR, and models are generally trained to go easy on internet access so you want all it could need locally.

Review should be performed by telling the LLM that the change under review introduces a serious vulnerability and ask it to identify and characterize it so that it can be reported.  False positives can be controlled by asking it to construct a demonstration (this step largely precludes using any closed weight commercial LLMs).  Avoid situations where the common outcome would be saying something is all good: "Review my PR" = "This change is great, you're so smart", "This has a bug" = "yes, the bug is ...".  Remember, these things begin their training as internet content prediction machines.

If the change under review is under-tested, then a pre-review step of constructing comprehensive tests may be necessary.  If the agent spends more than a turn or two on a side-quest after you stop start over with that side-quest pre-resolved.  A context full of useless sidequests can really hurt sensitivity.

This strategy immediately reproduces issues in several bitcoin ecosystem incidents that I've seen incorrectly reported as not-llm-discoverable (including, in some cases, with relatively weak models).

The review approach should go commit-by-commit or at least pr-by-pr at a time, as throwing an entire codebase for review at once is kind of a crapshoot-- it can be useful to do too but it isn't a replacement for a focused approach.  For a large existing codebase where the concern is existing issues and not newly introduced ones, you can obtain focus by directing the flaw search unit by unit and/or by making a pass where you ask what kind of flaws might exist in this sort of software (or in each part of the software), then with a fresh context working one at a time with the claim that such a flaw exists.

Some supervision is required since when there is no flaw nor anything that LLM could claim might be the flaw its pretty common for it to get stuck in a loop of some sort and need to be manually stopped to retry or moved onto the next commit/issue.

It's important to operate in the most sensitive regime and potentially run multiple times-- because an attacker will be using tools at least as good (and in the case of state sponsored attackers may have models that are less handicapped), and they also might get lucky in their run.