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