calle / calle is on Nostr

DM @callebtc:matrix.org

Last Notes

2026-09-08 10:43:25 UTC

- reply

ah sweet, readme needs an update then!

2026-09-07 09:37:23 UTC

Liquid hack explained.
Liquid has confidential transactions that hide the amounts for improved privacy. A bug in how these transactions are validated caused inflation of Liquid BTC (L-BTC) and allowed hackers to empty the entire side chain.
Liquid nodes don't see the amounts of a confidential transaction, so to make sure that the transaction is still valid and doesn't cause inflation nodes check something called a balance proof and a range proof.
The balance proof establish that sum of the input amounts equal the output amounts, i.e., that "x L-BTC going in and x L-BTC going out". But there's a catch. Only relying on a balance proof isn't enough. You also need the range proof.
The range proof establishes that a hidden output amount falls within a positive range. That means a valid output must be at least 1 L-sat and at most 2^64 − 1 L-sats. Range proofs make sure that you can't mint "negative L-BTC".
Why is this even necessary? Remember, the amounts are hidden and a hidden negative amount would allow extra positive outputs to balance against it. Without a range proof, a transaction could say "I've put 1 L-BTC in, and I'm taking two outputs out: one with 4000 L-BTC and one with -3999 L-BTC)."
This is going to cause a disaster in a little bit.
Once the balance proof, the range proof, and other validations pass, a transaction is regarded as valid and can pass consensus. However, because especially the range proof is computationally expensive, Liquid nodes cache the result of a successful range proof in memory. Essentially, the node remembers "I saw this range proof before and it was valid, all good!".
In order to recognize the same range proof later on, you need to assign a label to it. This is called a cache key. This cache key is the actual cause of the bug.
The way this cache key was constructed allowed two different transactions to collide on their cache key. Essentially, one valid transaction (1 L-BTC in, 1 L-BTC out) had the same cache key as an invalid transaction (1 L-BTC in, 4000 L-BTC out).
Here's the hack: the attackers submitted the valid transaction (1 L-BTC in, 1 L-BTC out) first. Liquid nodes verified this transaction successfully, created a cache key called REKT and stored it in their cache. Then the attackers carefully crafted a second invalid transaction with (1 L-BTC in, 4000 L-BTC out) that created the same cache key REKT.
Instead of validating the second transaction and realizing that it printed money out of thin air, Liquid nodes found it in their cache and said "hey I saw this transaction before, everything is fine" and that caused the inflation.
The attackers then took their 4000 L-BTC and withdrew 4000 BTC onto the Bitcoin base chain.

2026-09-06 04:16:20 UTC

- reply

nostr is full of reply-guy psychopaths that you can't block and there isn't a single client where muting works reliably, let alone across apps
#nevent1q…9x70

2026-09-01 05:58:47 UTC

Gm @nprofile…nj27, just curious, do you sometimes still write Bitcoin stuff?

2026-08-27 13:40:16 UTC

Without Lightning, none of the Layer 2s make sense.
Without it, every Layer 2 would be a useless silo and a centralization vector.
Maybe Lightning was Bitcoin's Layer 3 all along.
https://blossom.primal.net/e8efb658494ae4cdea50ceb367faa38028fb80e22609b54ba1afc9185c53463f.png

2026-08-14 07:38:24 UTC

- reply

He didn't

2026-08-06 17:52:27 UTC

🚩 Bitcoin Red Team update 55 hours into the campaign
We're now 24 people working around the clock.
We've scanned 425 projects so far and have produced 1029 high+critical (H+C) findings.
https://blossom.primal.net/9c1af29b7a362e981cdac51f88186552e3e0e9c9fbc18fae5047d12015ad8565.png
We generated 6700 findings so far and are hitting 7.7 projects per hour.
Our H+C rate per person per hour is back at ~1 as we work off a massive backlog and as the team grows and naturally divides up roles.
We have hunters, wizards, outreachers, sugar daddies, and gigglers.
https://blossom.primal.net/4dc7b8b0c997a50ba2c60f8d69add016370cd0a76838b2244799c8f385b4d252.png
https://blossom.primal.net/ed41ccd68901b5a794084466bc552e57e41f7d026d5b91da39dd8b4fe0064ef7.png
Our H+C ratio is at 15.4% of all findings, increased by a percentage point compared to yesterday.
This is great, our accuracy is stable, and even slightly increasing. We're trying out best to reproduce all critical findings in local regtests before reporting them to projects.
https://blossom.primal.net/fd24c2f5f8057510eeca48735c208268303795feab03085cbd8c2e6de2659b04.png
Our biggest bottleneck is outreach. Most projects don't have a SECURITY .md in their repos (19.5%). Only 13.1% have an email in there.
We're working on better ways to reach folks. In the mean time, the best thing you can do as a project maintainer is to leave an email address in your repo.
https://blossom.primal.net/0c7e7ca2e032b79a7f84a4cbb775fbe2e609bb9ab5ca6dfa3dd0c8bd0adf5885.png
Thank you to the sponsors and donors who cover the costs of this campaign and help to keep it alive.
Specifically @nprofile…5h0z, FPuklowski, @nprofile…8a9z, and everyone who has donated to OpenSats Red.
https://opensats.org/funds/red
An incredible team of some of the most hard core Bitcoiners I know have assembled and dedicated their last days to this effort.
We've seen shit.
I don't want to reveal anyone personally, they can choose to do that themselves, but I think the way that people came together to join forces was and still is the most beautiful part about this entire program.
It makes me very hopeful, seeing so many people step up and give their time and energy to Bitcoin, especially during times of pain.
We're not done yet.
https://blossom.primal.net/833de63c0d642b97bc6662803604b1173578a16528b1908be8448830351668a2.png

2026-05-24 07:18:13 UTC

privacy wallets throwing their principles under the bus just to add lightning via spark isn’t what I expected I have to admit

2026-05-21 14:52:48 UTC

OCEAN is an attack against Bitcoin btw