in the interests of saying something useful instead of idle musing: We're all fretting about sourcing entropy for our master secrets (seed phrases if you prefer), but what about for the nonces we use when we sign? Normal signing can use RFC6979 [1], also known as 'deterministic nonces': this trick means your wallet *doesn't need* to source any entropy/randomnes when it makes a signature; it creates a 'pseudorandom' value that is tied to the private key and the transaction you're signing; no one can figure it out, and you yourself can't screw up and accidentally use a low entropy, or repeated nonce. All good so far. So the headline is, for most of us, nothing to worry about with nonces, ever. However there are 2 bad things: the first is very counterintuitive but worth explaining: a master secret can be a few bits short in entropy (say, 120 bits instead of 128 of pure randomness) and it's very unlikely to ever matter. But this is not true of nonces! If you sign say 100 times with a private key p, and you use nonces k that are just *a few bits less random than full 256 bits* you can leak your private key to a sophisticated mathematical attack. In this, you might think, 'well I don't use addresses so there'll never be 100 signatures on one key p' -- but, careful: if you use an HD wallet (and everyone does), then knowing the pubkey means knowing the relationship between all the private keys on the branch, so the attack can still work if the attacker knows the xpub. **None of this matters if you use RFC6979**. Second bad thing: RFC6979 cannot be used in MuSig2 or DahLIAS. It is profoundly insecure. It can be used, of course, in traditional multisig. [1] RFC written by thomas pornin back in 2013; outside of bitcoin it's not well known, as most people back in the day, outside of bitcoin, thought using bernstein curve25519 was the solid industry standard and bitcoin's secp256k1 ECDSA was weird flaky nonsense that 'didn't even have deterministic nonces'; true, it originally didn't until this standard arrived [2]; btw people like Greg Maxwell were actively reviewing with Pornin at the time. As I recall Greg didn't like it a huge amount because it is quite an obscure construction and not so easy to byte-for-byte implement correctly. But obviously the idea is not only sound, but absolutely vital. [2] and true, ECDSA *is* weird flaky nonsense...

I always had a gut reaction against dice rolls. Reflecting seriously, I have to reluctantly agree it's a solid concept. But: why that gut negative reaction? Not because the number of bits is not exactly what you think because of some complex mathematical calculation. Instead, it's two related principles: 1/ complexity is the enemy of correctness. This is a lot of extra manual steps. 2/ I made up a "law" a long time ago: every time a user sees their secret key on a screen it cuts their security in half. This is a gray area: you may be entering the key material in chunks, and also a 'screen' on a hardware wallet is not the same as a computer screen. I've come round to it over the years, it's a sensible idea, but I'm still slightly suspicious. We should be focused more on an audit step: however you generate the entropy, is there a way you can check the process is working? Dice rolls don't fit that idea so well (compared with machine-seeded). I'm reminded of an excellent point Gmax once made abou wallet dev: when you generate addresses for users, you should sanity check that you can actually sign against it, before giving it to the user, so they don't send their money to a black hole.

I want to write a whole essay about this Coinkite disaster but I'll resist for now, and just make one point that I don't think others are making: constrained devices need to source entropy in unusual, more complex ways. /dev/urandom as a PRNG, at least post-2012, has been pretty reliable for software wallets throughout bitcoin's life. There have been several other entropy failures in wallets similar to this one, but they've *all* been based on customized entropy generation methods. I'm dubious that people's conclusion is not to be suspicious of the constrained, single-purpose device model, but instead to conclude 'hardware wallet plus dice rolls and/or multisig across manufacturers' is now the sensible thing. That model is not terrible at all, pros and cons etc., but damn is it asking a lot of ordinary users. I have always advocated for commodity hardware (a laptop) that never sees the internet, if you are serious about security, but I admit the hardware wallet model's advantages are very notable. The thing is, so are its risks.

Central points of failure are a way, way worse problem in Bitcoin than in most things you're used to.

A little bitcoin quiz for you: look at this address:

The Mempool Open Source Project®

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

If it's an address someone found by grinding (not really a vanity address unless their name is qqqq or something), don't you think that's a bit expensive to grind?! (it's around 90 bits of zeros!). If it's a NUMS address, how come someone spent out of it?

I predict that we will continue to see more like this about post-quantum schemes: "Despite HAWK having survived two rounds of expert human review over a period of two years, Mythos was able to improve the best-known attack on it in just 60 hours of work—effectively cutting its key strength in half." (see

Discovering cryptographic weaknesses with Claude

Anthropic researchers find weaknesses in cryptographic algorithms with Claude Mythos Preview

), but (and i think this is the common wisdom) very little such things with the hash-based PQC schemes. This is common wisdom because non-AI research was finding holes in other post quantum schemes a lot, for years. The problem with hash-based schemes is they're kind of shitty - precisely because they eschew any structure, we can't do anything nice with them. (Disclaimer: my post 100% sure lacks important nuance, I have not studied this field...)

Whatever happened to LORD HIS EXCELLENCY JAMES HRMH? (aka KING JAMES HRH, Great British Empire)

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

Been finding @PayPerQ more and more to my liking over time. I can use models more privately with the TEE feature. I pay with LN anonymously, i can see exact costs to the cent. I wonder if more features can be added for switching between nyms more seamlessly.

abcbadq's magnum opus. (Fallen Symphony - Ludicin) Map is hard as balls. But it's absolutely epic, especially the last 3 minutes.

Beat Saber replay

Not joking about magnum opus, abc is the most prolific (mainstream) mapper in the game, and there's always some creative flair in every one of his maps. This one is some kind of culmination of years of his craft, across 9.5 minutes it manages to include so many different patterns, many extremely difficult, and represents the music fantastically. #beatsaber

Talking absolute bollocks with supreme confidence — that's the whole game.

Gmax on proposals to add tail emissions to bitcoin: "but I agree with Sipa that these inflationary notions are a non-starter philosophically and morally. Particularly because anyone can create their own cryptocurrency with whatever rules they think are superior, and if its good people are free to adopt it. In such a world trying to impose such a radical change to the premise of Bitcoin would be inexcusable, and ultimately self defeating since if bitcoin doesn’t even have durability of its monetary policy why does it exist at all?" Unlike in technical questions, where in my experience Greg ends up being right 95% of the time, I found myself disagreeing with his take on philosophical things a lot more often. Most particularly around freedom of speech questions. Yet, I'm 100% with him on the above (and he expressed it very cleanly), and I (by the same token) completely disagree with @Peter Todd

Delving Bitcoin

Addressing the Diminishing Block Subsidy

I reject the premise that fee behavior does doesn’t already show Satoshi’s plan as viable. Bitcoin currently-- even now under an unfrothy mark...

I wonder how many Americans are aware (because I don't think I've ever heard one mention it) just how uniquely obnoxious the transit system in their airports is. You might not immediately grok what I mean; you might think "foreigners aren't entitled to anything" but in which case you didn't get my point - my point is that *for a traveller who has no interest in entering the United States* the experience is uniquely obnoxious. Every other major international airport has what's called "transit". I'm going from country A to country B with a connecting flight in country C. if C != USA, I just stay in the pre-immigration area and move over to the other flight; sometimes they have baggage checks (and ticket checks ofc), but not full blown immigration, because you're not entering the country. The problem is that the USA is a *major* hub for flights, for the Western hemisphere; it's not trivial at all, to avoid it, for some routes. And couple this with the fact that US immigration is not exactly relaxed (which is fine, but is not fine when you have no intention of stepping foot in the country ...) Why? And as bad as it is for me, I could use the 'visa waiver program' (still shit - still have to go through immigration) but many countries don't have that entitlement, meaning a citizen wanting to travel *via* (again, not into, via) the US would have to do this just to get to their non-US destination. Which goes from obnoxious to .. I don't know, surreally obnoxious.

What really amused me about Borges' Library of Babel is how he goads the reader by giving them all the exact numbers required to count exactly how big the library will be if it contains every possible book, once, but then stops short of counting and starts musing about infinity :) Even more amusing is the discussion of the fabled catálogo 😄 ... which can't exist. The *contents* of the library is ~perfectly compressible ("print every book length N" does it), but the *ordering* of the library, which is the purpose of a catalog, is perfectly incompressible: the only catalogue is the library itself!