Anyone running recent Tor builds with HiddenServicePoWDefensesEnabled set to true? What I'm mostly confused about is if onions have it switched on but their clients are on older versions or just incompatible versions, how does that work? #tor

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 →