Good lord. Might be the most impressive tech map clear I've ever seen: #beatsaber

I think there is a tremendous productivity boost to be had from using AI tools to write code, but I'd warn people one thing: if your code has cryptography in it that can affect user security, using AI tools of course can help, but surprisingly it could also make situations much worse. For example, I just wrote some crude python to implement a particular public key cryptosystem, then asked github copilot for its opinion. It first said, everything is good, this is a secure implementation. Then, I wondered if I should change this one thing X. It said, yes, actually, you need to change X. I then looked up several references online and realized that the changed I proposed was wrong. It doesn't take much imagination to realize that a bot that doesn't understand why something abstract is true or false, and is skewed towards being "constructive" (not intentionally, of course, but it is) can actually make a situation of "implementing crypto badly" much, much worse, because it could end up reassuring you at the worst moment. Be careful out there. I expect the same comments would apply to anything that is (a) security critical and (b) very obscure. Of course, some AI will be better than others and it will change etc. etc. ; I'm just saying, be really wary if you're in this niche. #cryptography

Steganography is the ugly stepchild of cryptography. When the thug comes with the wrench, however, it suddenly seems remarkably attractive.

1FuckIRGCterrorists is embedded in the utxoset as "spam", forever.

Review after a quick readthrough of "Thunderbolt" :

IACR Cryptology ePrint Archive

Thunderbolt: A Formally Verified Protocol for Off-Chain Bitcoin Transfers

We present Bitcoin Thunderbolt, a novel off-chain protocol for asynchronous, secure transfer of Bitcoin UTXOs between uncoordinated users. Unlike p...

My brief overview is: an elegant core idea, but the paper isn't the best, and most significantly has what seems to be some glaring oversights. For example, it pays no attention to key subtraction attacks (which unless I'm misreading would completely break the scheme). There are a couple similar things (timelocked backouts?) but it doesn't invalidate the paper's value. Another slight complaint I have is that they don't point out a core characteristic of the design: it transfers utxo ownership off-chain, so it is not (like lightning) a mechanism for arbitrary payments (it shares this limitation with statechains). With those complaints out of the way, let me outline the basic idea, aiui: there is a committee that threshold signs over events. Each participant funds their mulitisig utxo with the committee, then it is possible to transfer ownership from one participant to the next using a clever 3-way adaptor signature game. This can be done indefinitely, conditional of course on the non-corruption of a threshold t of n of the committee (since otherwise the committee can collude with earlier owners of the utxo to spend it). There's an additional sub-protocol for an n-th recipient to actually go on chain; they basically have to do a swap with the committee to get the funds out. If that isn't obvious, it's probably because of a detail I didn't mention: the authors are very focused on asynchronousness (I think correctly!) : they don't want Alice to still have to be online when Bob is paying Charlie, or when Charlie is dumping the funds to chain. So at the time that Charlie redeems onchain, Alice is not around, so her signature on the starting utxo cannot be valid to pay out to Charlie's (not yet defined) output address. Hence the swap with the committee. It's complex, but justifiable I think. I *think* that's the gist of it. It's nice that they did some formal verification work on it (see "Tamarin" in the paper) but I didn't read that. I think the core idea here is interesting but I want to see discussion of how it could apply beyond transference of whole utxos, which I think is too limiting. #cryptography #bitcoin

This paper from CRYPTO 2025 (

IACR Cryptology ePrint Archive

Schnorr Signatures are Tightly Secure in the ROM under a Non-interactive Assumption

We show that the widely-used Schnorr signature scheme meets existential unforgeability under chosen-message attack (EUF-CMA) in the random oracle m...

) appears that it might be a major step forward in security analysis of Schnorr signatures. They argue that while you can't get a tight reduction from Schnorr to discrete log in the ROM, as has been proved by Seurin et al in 2012, you *can* get a tight reduction to what they call "CDL" ("circular discrete log") where the challenge is, instead of, given Y in the group, find y s.t. y*G = Y, you have to find (R, z) s.t. z*G = R + f(R)Y where f is some function. So what they're doing is matching more closely to Schnorr's actual structure. If CDL is as hard as DL, then this makes Schnorr's security reduction to DL actually tight (so that, for example, using 256 bit EC groups as we do in Bitcoin, *does* give 128 bit security directly from these proofs, which was not the case before). But to counteract the argument of Seurin's earlier paper, the reason this CDL approach sidesteps it is because CDL is "representation dependent", specifically because the value f(R) depends on the representation of the group element R. Reducing CDL to DL is something they analyze both in the GGM and a variant of the AGM. Don't understand the details. Obviously this is way above my paygrade to assess, especially just from a skim read, but it *looks* like a pretty significant result than can put Schnorr-based signing algos on a firmer footing. They specifically analyze the case of Sparkle+ which is a recent improvement of the basic FROST threshold signing scheme, and they argue that this approach proves tight security reduction of Sparkle+ to (ec) discrete log. Very interesting. #cryptography