We are very close to being able to have communication that is practically undetectable even by an aggressive censor like the CCP. Here's the basis of my claim: in order to be uncensorable, it's not only required that the data can't be readable (that's trivially achieved with end to end encryption), but also, the channel used to convey the messages needs to be 100% not suspicious. This is what we call steganography, and it's not only as hard as it seems, it's even harder. For example, you can embed data easily into low order bits of an image, but that doesn't successfully pass the "innocent" test. The pattern embedded in the binary file is statistically detectable with (not even very advanced) mathematics, so the censor will catch you. So you find yourself having to solve a strange problem: how to "mix" your secret message with some "innocent" message (called in the literature "cover text") in such a way that the innocent message is not suspicious. People have tried things like: embedding data in whitespace in text; this is obviously not good enough, though it's an amusing idea. Recently I started mulling over whether LLMs might be *the* solution to this problem, because an LLM's state evolution is governed by random choice, so if you embedded your data into that random stream, the output could be plausible innocent text while the hidden message was encoded in the randomness. (If you already see problems with that idea, well done, we'll get to it...)> It turns out I am not even slightly original: Meteor https://eprint.iacr.org/2021/686 already had this idea in 2021 before LLMs had taken off, and moreover it tweaks the basic idea in the specific way needed to make it work. I won't bother expanding on the details rn. But I'll point out the limitations: for a receiver of the hidden message to actually receive it, they have to use exactly the same LLM, in exactly the same state, as the sender did (because it extracts the message from the random choices of token, which are stateful; the next token depends on the previous ones). The upshot of this: if we had a scenario where a "decent" LLM could be loaded by users on both sides, and the sender generating output from that model is plausible innocent text (true for a decent model, not true for a really crappy small model), then you have a properly undetectable communication channel that no censor, even a suspicious one, would be able to see. But it'd be very stateful: Alice and Bob would need to set it up in advance with a key exchange. The idea of the model being *public* (which the paper discusses), could *kind of* work, again, if the model is very good. The bandwidth would still be fairly low (but much higher than bits in jpegs!). Not really clear, but we're a way off from this, but it could come in future. Plausible but difficult for communication that is extremely dangerous. Notice again the pattern of how access to compute could be crucial for freedom.

Dario Amodei at Anthropic is using the same playbook as SBF. Who remembers the pictures of SBF being fawned over (and even kissed!) by Washington politicians. Why? Basically because he engaged with them and told them what they wanted to hear, that their power was going to control "crypto" and that everyone else who wasn't spending their time talking to politicians and celebrities (because they were actually running businesses that served customers, not scams) were just scoundrels who could be brought to heel by 'regulators'. Amodei is doing the same thing now, with the same 'effective altruist' philosophical background. Of course I am matching a pattern at a high level, in the details the two cases are very different; Amodei is not stealing customer funds because he isn't in custody of them, and his power level is currently very high, much higher than SBF's was, but notice that he skews Democrat-side, like SBF, but like SBF, it's more just by nature of the govt control he's trying to encourage; he will try to play both sides. They are funding "anti-AI" (meaning strongly regulating AI, it's largely the same) candidates directly, see [1] from reuters for example. I slightly drifted off the point, but it's : a moat through regulatory capture. I wonder if it will blow up in their face: cripple AI as a consumer (and business) product by making their own products unusable, and not just stop new competitors, as he/they intend. The competition is partly open source, and if the battle for the consumer shifts from the software top layer to the lower layer of hardware, they could end up screwing themselves over by campaigning for regulation. One of my first realizations after LLM-AI became a "huge thing" a couple years back was this: this is not really the same as social networks or money because it doesn't have a strong network effect (it has *a* network effect - every product does). So while monopolies might develop, they definitely won't at the level of a chat interface. This is a direct customer-product interaction, almost entirely in private, so switching costs the user absolutely nothing (I admit, that may change in future). That's why I've been convinced from the start that open source will win at the software level of this phenomenon. And nowadays censorship resistance can easily be observed as the unsurprising other vector pointing in the same direction. (Privacy also but people always give that up first). [1] https://www.reuters.com/legal/government/anthropic-donate-20-million-us-political-group-backing-ai-regulation-2026-02-12/

I've read quite a lot in Spanish now. Nothing prepared me for Borges though 🤯

Everyone's worried about how AI is going to find bugs in existing open source software. A bigger threat might be how many bugs are going to be introduced through using AI without being excessively careful. I guess, doomer mode on, both are going to pretty severe. So we're going to have a lot more software and features, but at least in an intervening period, a lot more dangers from using it.

To sponsor (support) someone on github, even just to tip them $25, you have to hand over name and address (and use a credit card or something equally crappy). That's so shit.

Cost for a SWIFT transaction between 2 LatAm countries: $45 on sending side plus $20 on receiving side [1]. No matter how small the transaction. You also have to fill out forms on both sides and submit supporting documentation, on both sides. But remember guys, bitcoin has no use case and is slow and expensive! [1] (Before you say it, yeah i know that a more normal cost is like $30 or less for SWIFT and ~$0 for some other types of bank transfer. But plenty of the world is not 'normal' in the way you're accustomed to, and plenty of governments and bureaucracy is tied to these abysmally inefficient banking rails).

I just came up with a slightly casual thesis about Bitcoin privacy and for fun threw it at Kimi 2.6 (2.6 mind you! not even a latest model!) and said "develop this thesis however you see fit". It came back to me with a full essay that honestly is a pleasure to read (at least for me...), *at least in* how beautifully it was written combined with a set of metaphors and comparisons that were really quite original. Sure, I know, AI writing is "slop": you can recognize it and it's pretty annoying when people resort to it to achieve a goal (it feels both fake and lazy, often), but I hadn't recently just asked it to write free form: it's *probably* recognizably AI (just about), but who cares if it's *actually better than almost all writing I've seen recently about <bitcoin, or whatever you care about>!*

Did you know that Dryja's discreet log contracts are fundamentally unsound? OK now the click has been well and truly baited, I'll try to contextualize: DLCs are unsound in a theoretical sense that I'll explain; it's enough that it matters, but probably not enough that any real-world implementation would actually get attacked. To explain the cryptographic-unsoundness without going into mathematics, I think it probably helps to explain a concept "UF-CMA": unforgeability against chosen message attack. The idea is this: you want your signing algorithm to be strong enough that this, specifically, holds: if someone asks me to sign a message and (this is after all, quite common), I'm willing to oblige and sign their message, then there's no way they can craft their message-to-be-signed such that my signature on *that* message allows them to *forge* my signature on a different message. Obviously we imagine this scenario repeated, e.g. they get me to sign 16 different messages, all of which they carefully choose, before using all of that as input to create a forgery. We clearly do not want this to be true in a general purpose signing algorithm. You can prove EUF-CMA for plain vanilla Schnorr signatures: here the "E" is about the idea of them creating a signature on *any* new message, at all. EUF-CMA is generally treated as a requirement. DLCs don't use vanilla-Schnorr[1]. What they use is a variant: R is set *in advance*. A refresher on R: there is a one-time used secret value k, called a nonce, in a Schnorr-type signature, and R is the "pubkey" of k: R = kG. DLC doesn't violate the "one-time" and "secret" nature of k. It changes the protocol in a more subtle way, by publishing and therefore fixing R, before the message to be signed arrives. It turns out that this loses UF-CMA due to something called the Wagner attack (or ROS attack). I will spare you the details, but imagine just that it means: because an attacker can know in advance the inputs to the hash function, he can create a forgery by summing signatures he's given, **as long as he can control what gets signed**. (that's why knowing R matters; if he couldn't predict R, he would be unable to execute the attack because the hash output wouldn't be predictable from the message). If your DLC oracle will sign literally anything (so it has published a huge number of Rs for a huge number of outcomes), then in N (large) signatures on messages *you control*, he'll actually allow a forgery of his signature on *any message at all* (even a bitcoin transaction, should you store money at the same key as the signing oracle, unlikely I guess). Sounds pretty bad, right? Cryptographically, it is. But in practice, in the nature of what oracles are is that they control what they sign carefully. If they only sign "true" or "false" then that's not enough information to squeeze in random values that the attacker needs to squeeze in, *even if* the attacker can fully control whether the output is true or false. Even in the more plausible scenarios like, an oracle signs a price measured to 6 decimal places, there's more information for the attacker to "squeeze in" but it's all the more impractical for an attacker to control the outcome that exactly. The oracle has to be prepared to attest to some huge number of outcomes, *and* the attacker has to be able to fully force the output he wants. And to repeat this process. So this leaves us in a funny situation: it is reasonable to assume security of the construct from the point of view of "the oracle can be trusted not to sign just anything, or some large number of weird message that don't correspond to reality (real price, real temperature), and that's why we trust it's not going to get hacked", that is, your trust is not in the cryptography, but in the identity behind it. But that's the "oracle problem" anyway; even if the cryptography didn't have this weakness, you'd still have that same trust. I *do* think it's dubious, though; such a theoretical hole is very undesirable. Attacks *tend* to improve over time. The rest is more techincal, feel free to skip: Postscript: you might be thinking, damn, this Wagner attack is scary, if you can just make a forgery from a bunch of pre-existing signatures .. maybe you can do that with normal Schnorr like in BIP340? The answer is: using *deterministic nonces* elegantly avoids this attack, even if making fresh and unpredictable nonces didn't (it does). If the nonce is generated from a hash of the message and the private key it cannot be derived in advance in any way by the attacker without knowledge of the private key, which makes the attack moot. The only other "nonces are pre-prepared and handed out" case is that of MuSig2 (and iirc FROST); in those cases the defence is specifically connected with a clever "contextualized nonce" : R1 + bR2 where b hashes the *context* of the signing event, including the message, which prevents grinding. This extra defence was created *specifically* to address the Wagner threat, which otherwise would be even worse for the collaborative protocols than the single signer one. What you should take away is: default Schnorr is tremendously nonce-fragile: it's not even enough for it to be random; it has to be secret before the signing event! [1] You can say that it does, but I beg to differ. Vanilla Schnorr is the canonical sigma protocol and follows the pattern: commit, challenge, response, with R being the "commit" step and "P" being the public context of the protocol execution. In DLC R is part of the public context, and what is the commit step? (there isn't one, I guess). Obviously this is very abstract but it's probably the right way to understand why the security hole exists.

I love these new AI tools. It seems like most of us do. But let's be real, so many of us are going to get disastrously owned. It's a security nightmare.