Philosophical reflections incoming: A famous anarchist once said "privacy is not a right, it must be taken". There's also the more catchy "privacy is a human fight". You should look at bitcoin ownership similarly, except a bit more optimistically: *general* privacy is stupidly hard bordering on impossible; bitcoin ownership is just "bloody hard". There's two ways in which this affects my personal philosophy around bitcoin self-custody. 1/ i consider myself in a permanent war against others trying to steal my coins, and in an even more violent war against my own stupidity and errors. I know this sounds a bit exhausting, but it is realistic. This feeds into 2/ don't put all your life savings in bitcoin; even 50-70% of your life savings in it is *way* more risky than most should be comfortable with. 2/ almost seemed liked heresy at some points in recent years. And that's insane. It didn't used to be, it used to be common knowledge/obvious that you don't put in more than you can afford to lose. Somehow this idea that 'everything fiat is crap so put all your accumulation of wealth in btc' became not just acceptable but required in some social groups. it's wrong mainly because of the above - namely that holding bitcoin is not super-safe, people make errors, people get hacked, people get unlucky with software. it's also a bit wrong because of bitcoin's high volatility. it's also a bit wrong because diversification makes sense with savings (perhaps not so much with investments, where you need growth), but with savings, I think so. So plan around the worst outcomes, including losing your btc (and you can plan around that by diversifying *that* into different storage clumps, but of course how much complexity you can stomach will depend on you). All of that sounds like I'm saying, meh, bitcoin, useless, but never forget: you can lose fiat money too, just as unfairly and cruelly, in different ways - mostly through "powers-that-be" just shafting you. It's happened to me, and more than once. With that system you're little more than a slave, just hoping your masters don't decide they don't like you today. There's a reason a system as impractical as bitcoin exists.

There's actually going to be a fork in a few days. I kind of forgot for a while. bip110.orange.surf/live.html

I've moved funds onto lightning from onchain today without problems (to do payments) with no problem. A win for Phoenix's splicing model I guess?

The part of 'multi-vendor multisig' that I don't like is this part: "vendor"

Here is the answer: The private key of this address is 2^-1 mod n, where n is the secp256k1 curve order. This curiosity is super well known by now. When the spec was created, they chose the generator by hashing with some ~160 bit hash and the output was converted to an x-coordinate to choose a curve point. The generator G was then chosen as 2 times that curve point. That's why this is the only very small x coordinate point on the curve for which we know the private key. Everyone was a bit freaked out about this, but there are mathematical reasons to not be concerned. I'll stop there, the rabbit hole exists if you want to go down it ... (tagging @SPA (Super Phat Arrow) ) View quoted note →

Fwiw i thought more about it last night, chatted with Claude about it, and saw a serendipitous tweet from Matthew Green making similar points in the negative: I don't think what I'm alluding to here is even really possible at all; you can't really 'verify that you're actually getting random output', and not only because of intermediate hashing steps. Wish I were wrong but it really seems that way. There are other interesting ideas around testing, but I want a 'one click' version for a user, and I can't find one unless they generate the entropy themselves and do not mix it with from-device entropy. So dice rolls and similar. View quoted note →

We all (who have tech skills) are at least a little bit at fault. We never developed some kind of norm of: how can you assure your users that their private keys are 'proper'? Were they supposed to look at them? No. If you grab your randomness from the OS, you can't know, via testing, that the result will be random for a *user*, who is using a different machine than you. But why don't they have a simple push button test to check by sampling? Obviously it's a bit harder with HWW but same principle. Actually I'm genuinely curious what people think about that.

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...