Maybe people will finally realise (a) it's easier to audit software than hardware (b) the threat model on hardware isn't realistically backdooring general purpose computers when they don't even know what software you'll run (c) you don't have to rip out network cards, if there is no accessible internet. Maybe, maybe not ;) I wonder if I was influenced by getting into bitcoin before hardware wallets existed. Back then the discussion was "don't be a dumbass and run your wallet on windows" and "keep it on a separate machine". People were running wallets on phones and getting into arguments about how much is safe to keep on it - I guess that just hasn't changed at all. BIP32 was just starting to become commonplace and people realized the 'watch only' concept could work (a massive step forward imo), people were just starting to tinker with the idea of special purpose devices, I remember Trezor starting up. I played with one a few times, small amounts, it's kind of cool technology, but I could never bring myself to put much money on it. It's sitting in a drawer, empty, now. I bought a couple Coldcards, gave one to a guy in El Salvador who used it for teaching, the other one sat in my drawer until the hack, shortly after which I took it out of its bag and used it as a teaching demonstration, myself. Thanks for coming to my ted talk.

Here's what withdrawal looks like when the hub has gone offline. There are 2 such transactions. Each about 10kvb, a mere 40kB of witness/script 😄 (seriously though: big, but not a problem at all).

mempool - Bitcoin Explorer

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

View quoted note →

Doesn't look like much (because it isn't! lol), but here is the first ever withdrawal from a lichen on a public network :

mempool - Bitcoin Explorer

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

Alice deposited 30k sats into the L2 for a 2 week timeframe, paid Bob 5k, then withdrew 20k. Now Bob has 5k sats more and Alice has 5k sats left. Alice's leftover 5k sats in this case are in "credit" mode: she can't exit them any more independently, she'd have to sell them to someone else. In general, she won't do this; she'll withdraw everything when she withdraws, that's the simplest, or just "novate" : when she wants to withdraw she'll negotiate a new contract to replace the first one. Also it won't be very practical to use 10k sat type deposits in a real deployment. Like 400k and up is my guess. Of course L2 txs can be v. small. View quoted note →

From the table of contents this looks like a fantastic ZKP reference. All the way from the absolute math basics to modern systems:

GitHub

Release Latest Book Build · BlockstreamResearch/zk-book

Automated build compiled from the latest push to main.

A follow up from recent ideas : Lichen[1]. You can have trustless withdrawal from an L2 based on liquidity in channels. https://groups.google.com/g/bitcoindev/c/yZEZ5P1lj5E I'll be interested to see opinions. I believe this can be built today. No consensus changes needed (op codes). The application I'd like to see it for is shielded transfers for good privacy, without some of the current impracticalities in proposed bridge designs.

GitHub

GitHub - AdamISZ/lichen: L2s in channels enforced on Bitcoin

L2s in channels enforced on Bitcoin. Contribute to AdamISZ/lichen development by creating an account on GitHub.

has a prrof of concept with a demo on regtest. [1] another backronym 😄 .. L2 In CHannels ENforced by bitcoin.

Is anyone else getting paranoid that their own writing is starting to sound like AI cliches, because so much of what they read nowadays comes out of an AI. To be clear, I don't look down on AI writing just because it's AI. I still read it if it's a useful set of ideas, but I see it very differently if you aren't writing it yourself because, *sometimes* (depending on context) it means you just didn't make much of an effort. Also it's gradually getting less cliched with more recent models. But, gradually.

if you want to know why i always talked down people's belief in hardware wallets, it was not because of what happened with Coldcard, it's because of what just happened (apparently? seeing it rumored via Karpeles on twitter; not sure if it's true) with Ledger: supply chain. They didn't need to tamper the wallet directly, they just created a way to watch it. You buy via the authorized resale agent, but he goes rogue and sells versions with 'implants' that read your seed as you enter it. *Not advising any particular approach to all this, not even 'don't use hardware wallets!'. just saying - central points of failure matter, you need to think about that *actively* because it's human nature to stay in the herd, even in subtle ways.

Interesting detail that I bet no one else mentions ;) If you're worried that AI might break the cryptography protecting your coins, it might make sense to switch to taproot. ECDSA is *far* less trustworthy than Schnorr and ECDLP, imho. Of course no one really has a clue, but that take is not unreasonable.

Following the coins of the 19 September 2026 Blink attacker

Very interesting read! H/T @Super Testnet

It's strange but afaict bitrefill.com is permanently blocked in my ISP in Buenos Aires, last 2 months at least. I saw other similar reports from people in Argentina. Zero problems via VPN. Definitely *some* kind of local block. Weird.

As both users and developers, we're rapidly approaching the point where we have to decide 'is it OK for the software I use for serious things (health, money, privacy etc.) was not fully vetted or fully understood, line-by-line, by expert humans.' Tests were always a vital part of development. We're going to have to decide if we can rely on them even way more than we do now. Sorry for being Captain Obvious today...

Project I've been working on: "LN-GAP":

GitHub

GitHub - AdamISZ/ln-gap: Lightning governed by arbitrary programs

Lightning governed by arbitrary programs. Contribute to AdamISZ/ln-gap development by creating an account on GitHub.

Play multi-move games or arbitrarily complex contracts in Lightning channels. Read the linked short paper as per the README, to get an idea of how it works. Trust model: trustless settlement w.r.t. the counterparty, but needing a 'venue' that is only trusted to publish the 'moves' on time. The venue never controls any funds, doesn't need to process (or understand) the contract, can be drawn randomly from an arbitrarily large set, only 1 of n trust for liveness and majority+counterparty required to collude. Collusion burns reputation and/or bonds. You can pretty easily run the chess or blackjack examples in the browser. I think it's a pretty interesting idea, slightly different angle of attack on offchain bitcoin denominated contracts. Draws a lot on many older ideas/constructions, with a few new ideas/details.

This is extremely typical of my interactions with Opus 5.5. I try to make a lighthearted quip about some nerdy thing and it immediately shoots back with a totally dry/deadpan insightful and content-packed answer with the intellect of a thousand suns, or something (*): "a long time ago when analyzing a similar construction, i somehow convinced myself that the optimum is at e, and that's why 3 or 4 as the base often appears optimal. but knowing me i probably just guessed e by intuition, and it's probably not correct :) Your intuition was right, and it's a real result. It's called radix economy. If representing a number costs (number of digits) × (cost per digit, proportional to the base), the cost is b · log_b N = (b / ln b) · ln N, which is minimized at b = e. The best integer is 3, slightly better than 2 or 4. That's the classic argument for ternary computers (the Soviet Setun was one)." (*) OK on reflection, this isn't particularly amazing. But the reference to the Soviet ternary computer is cool. And this output comes in like, milliseconds.

a trick I hadn't seen before to get a random number onto the stack in bitcoin: say Alice and bob post a hash (so a commitment) of a random number, then you want to force them to reveal it in a Script. Using 32 byte values is not useful if you want to do arithmetic; as we all know you can only do arithmetic on "little script": 4 byte values, not 32 byte. Even worse, just hashing '12' is no good; there needs to be a salt so that the commitment is hiding, so more random bytes. Script can't parse the preimage and split it into parts to get the number from '12f3fwrffrsf' to '12'. So here's what you do: OP_SIZE on the preimage gives a 'little script' number directly. If you want to commit '12' you make a random string *of 12 bytes*, hash it and that's your commitment. It has hiding because the 12 character string is random, and when the preimage is consumed with OP_SIZE you get the number 12 on the stack. Obviously this is only going to get a smallish number out: I used '12' but i think you could get into the 100s, but not 1000s due to Script limitations. You could do it multiple times though and encode digits that way. Apparently this trick was already there in a 2013(!) paper: https://eprint.iacr.org/2013/784.pdf that talks about doing MPC on bitcoin. I wonder if it was unfairly ignored because no one was gonna do MPC on bitcoin back then!

The whole Glock program is as expected, slowly but surely coming together. Basically algebraic garbling is the thing: with that you change a garbled circuit from a 100GB behemoth into some normal sized object. You might still have to throw cut and choose at it, but that's never more than a 100x multiplier. (I admit I haven't read the paper yet, lol, but that's the story that's been brewing all year. I think the Linus/Eagen/Ying Tong thing is somehow closed source so I guess none of us know what the frontier is exactly, unless we pay up!)

Shrinking offchain data requirements for Groth16 verification on Bitcoin

Taking Groth16 garbling from gigabytes to megabytes