Uncomfortable truth: digital ids will make ZK age verification relatively easy. View quoted note →

Glock is simple really. It only uses: Binary elliptic curves, Garbled circuits, Oblivious transfer, verifiable secret sharing, adaptor signatures, lamport signatures, SNARKs, and cut-and-choose. Oh and Bitcoin too, it uses that somewhere. #cryptography

Crazy story. I wonder if the UK govt is keeping most of it. They are so weak and incompetent I would not be surprised if a ton of it ends up in the hands of CCP interests. Best quote: "... and to reassure them that the significant rise in cryptocurrency values means there are more than sufficient funds available to repay their losses," said Qian's solicitor Roger Sahota,..." Translation: You'll be paid in 2015-16 prices if you're lucky, in about 8 years time. Lawyers, bureaucrats and govt officials will skim off far more of the remaining 98%. However cynical you are, it is not enough, believe me. View quoted note →

I spent a good long while thinking about this issue in more detail, even to the point of writing out formal security arguments, and I came to the conclusion that there's no real-world way to prevent at least a 20% leakage of data (i.e. data can be published at 20% of the size of the utxo) in the hypothetical scheme where you require a signature on the pubkey, so (P, (R, s)), in scriptPubkeys. Why 20%? Think of it like this: the nonce being deducible is absolutely unavoidable. You could ban repeated nonces, you could ban ultra-low value nonces, you could ban other specific patterns but there will always be a way to leak it to interested observers - it could be something as neat as "the secret nonce is exactly the previous block's block hash" or something more messy like a function of the time of day, or ... whatever. That will mean that in *any* one signature we can broadcast the private key at least. In a (P, R, s) scheme that means 32 bytes in 160. In reality, grinding could add a few more bytes to that so it's a little higher. In the repeated scheme, you leak 64 bytes out of 320 bytes, which is still 20%. But 20%-ish with the massive caveat that you let others control the key and thus eject the data from the utxo set. It's *academically* super-interesting but I'm not sure any "bad actor" would ever choose this channel, unless perhaps they were forced out of other ones. "Academically interesting" because while outputs don't work like this now, and probably never will, it would not totally solve the problem of "spam data in unpruneable utxos". It would make it less efficient, but at the cost of making Bitcoin as a whole also much less efficient. View quoted note →

Apparently Bitmex research last month wrote an excellent article using the same idea about data in private keys that I mentioned on the mailing list last May:

Delving Bitcoin

Response to Pieter Wuille's StackExchange Answer Re: Nuking the Opreturn Filter

Oh I hadn’t seen that recent article by Bitmex Research, very interesting that they came up with the same idea I had a while back in May on the m...

(I don't think they had seen my post). Jokes aside, it is kinda fascinating to try to formally prove that you can't embed data in Schnorr in P, (R,s) without doing this. I have a vague outline but it's quite unclear.

Not sure if it's of interest to anyone here, but I tried to make a formal reduction from silentpayments unlinkability to DDH here. Haven't had any review yet. It wasn't 100% trivial (also I couldn't find earlier papers that had analyzed this), but it also feels, to me, unlikely that there's any problem here, at the base level. It says nothing about ways you could screw up privacy with usage patterns.

GitHub

GitHub - AdamISZ/silentpayments-unlinkability-note: Short writeup of unlinkability property of Silent Payments (BIP352)

Short writeup of unlinkability property of Silent Payments (BIP352) - AdamISZ/silentpayments-unlinkability-note

#cryptography View quoted note →

Unsurprisingly people are really clueless about Argentina and so if they decided Milei is bad they don't really have to check more than the headline, they already "know" the reasons behind the story ... View quoted note →