Sign in shopping area in English but sign on stairs in Russian (and upside down).

No, looks interesting. Censorship resistance is pretty clearly going to be far weaker in such a system just by common sense. And btw "private because nobody is looking" is not a good summary of what I was saying there :)

Vpn paid for with a LN payment. E.g. https://lnvpn.net/

I might argue that inability to unambiguously calculate an anon set is a positive - systems which don't create permanent global records of usage are ceteris paribus *more* private.

There are obviously counter arguments. But I will say that, the fact that LN is fast and cheap is the 'special sauce' that makes its particular version of privacy attractive to me. Many academic studies have already pointed out ways it can be attacked actively, it is true, so I don't claim it's even close to perfect, but it actually has 'cover traffic' in the loosest sense by being fast and cheap, and for everyday users that may end up mattering more.

It's hard to recommend one thing, there's a whole stack of knowledge that this stuff is based on, and it depends what you're already comfortable with. For example if you wanted to learn STARKs (as I do, but haven't yet), there's a whole different bunch of mathematical machinery compared with SNARKs or Bulletproofs. This uses the latter. You could do worse than read my old doc that slowly builds up the concepts behind bulletproofs, including what 'ZK' means: https://github.com/AdamISZ/from0k2bp . You can look for detailed books that cover all the preliminaries like the "moonmath manual" (search it), or shorter more conceptual things like Matthew Green's cryptography blog that has iirc a 3 part intro to ZKPs. You can find much more rigorous academic stuff like the Crypto Book of Boneh and Shoup which gives pieces of the picture but isn't yet completed. You can read Vitalik Buterin's old blog posts explaining zkSNARKs from the ground up (he's always been a really good technical writer, one of the best actually). And at the end of the day, the academic papers will really help too. If you need more general cryptography knowledge, different recommendations would apply :)

Btw on bulletproofs specifically look up the dalek cryptography blogs/docs, they are the best in terms of details, diagrams.

Re: the 55MB file generic/custom: it comes from parsing the taproot-only utxo set at a particular block height (you see that in the filename). It's a list of curve points, each one of them is basically P + vJ where P is the taproot pubkey of the utxo and v is the value in satoshis of the utxo. It's also filtered with minimum value to prevent being too large. Also it should be half that size (and that's one of the largest I've seen so far) because I never bothered to change it from hex to binary.

The processing takes time: yes, this pre-processing step, which reads in and modifies the curve points, is currently more friction than we'd like. That one took 4 minutes for a 440K key set. For some applications it might be fine to have this setup, then run a daemon in the background so that you can keep verifying instantly, but for this one, maybe not. Farming this out to others, I'm not sure if there's a way to do that that's more interesting than have the "other" do the whole verification. Maybe? Also, it *might* be possible to have the proof size be larger (e.g. 1MB instead of 10kb) and then the verifier only needs the tree root, but it's a significantly different algorithm and I'm not sure about if/how that would work.

The range: the range here was a from a chosen minimum of 1 million sats to a maximum of 1 million + 2^18. The minimum is completely prover choice. The range being a power of 2 is because ZKPs of range are most efficiently done as "prove that the number has the following bit representation", hence a power of 2. My feeling is that k+2^n is flexible *enough* but with some extra machinery you could make it more flexible (you can also change the base from 2 to 3 or whatever, but that doesn't help a ton I think).

Window for cheating: as above it's a utxo snapshot at a certain block. It isn't valid for any other time. So frequency of checks can't be that fast. Now I think about it, that is a big drawback here, if you want real time checking.

I'm not sure what your "custom to the prover" sentence was really asking. As per above ,the keyset/snapshot is generic for everyone, it's a snapshot of a blockheight. The prover and verifier have to agree on: the block height, and the minimum value filter, so that they have the same keyset file. If you try to verify a proof with a different keyset it just doesn't verify, even if the utxo is shared between the two conflicting keysets, because it's a tree like a merkle tree, and the roots won't match.

Lightning works very well for this use case.

Question for nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg and others who work on ecash mints: is this kind of thing potentially useful for you guys (see linked post at the end)?

The reason I'm unsure needs unpacking: first, I've always been lukewarm on ecash as a generalized money (see my old London talk on the topic for a 2 hour expansion on that :) ), but I think both that the technology is really cool, and that there are niche use cases where it probably fits very well. So part the obvious reason for being lukewarm is the trust in the mint and that, even if you can figure out any kind of audit of reserves that makes sense, it wouldn't *in itself* prevent the possibility of absconding with user funds. Still, that doesn't mean auditing is useless; it could function as a stabilizer (and .. you can make various arguments).

So, given that context, my suggestion of this kind of *private* audit of reserves is, I can imagine there being a future where mints have to be purely pseudonymous to some or other degree, to avoid attack by the state, albeit this makes trusting them complicated. In that case, it would not be ideal if audits of reserves actually showed a blockchain fingerprint. The advantage of the private-proof-of-taproot-assets protocol I described there is, its' super fast to verify so it should in theory be really easy for the mint's clients to check it. (as opposed to other ZKP techniques which could be super cumbersome here).

nostr:nevent1qqs9c6kj7n6k3myvwpqyaxapnw6660q4txmuq0tj3akll7mwplntqcgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qrqsqqqqqp7lfpwp

It took me a good 15-20 minutes, seeing Qg2 was quite hard, and so was seeing that moving the bishop back to its starting square is mate :)

Bh1! If b6/b5 then Qg2; if Ra8 then Ra8. if e4 then Rg5. And if f6/f5 then Bd5.

Pass the prize on to the next puzzle :)

Understood. I agree it's a can of worms to do it at scale. Maybe for some smaller scale projects it can be a valid choice.

Porque no los dos? :)

Re : "No, I don't want to reconstruct the key", I don't really understand; I didn't use the word 'reconstruct' in that. "I just want these providers to construct sigs safely which apparently FROST can do". But the point that's at issue here is you want them to do that with *your* key. FROST and MuSig both allow multiple parties to collaborate to create signatures safely, with the main difference being that the former allows it for t of n and not only n of n. *Neither* provide for the key to come from some central party. As for distributed key gen, yes they both do it, they have to; but they do it in radically different mathematical ways (because of the t of n requirement for a start). And retrofitting them to allow you to start with a key "x" and then split it up and give it to them probably can work, but my caveat point is, if you care that they can collude to take the whole key, between them, then that's not great.** In FROST's case, it happens to be polynomial evaluations that you share, but it's still designed so that t of those shares (in a t of n scheme) are enough to reconstruct your signing key.

**In any such collaborative signing scheme, by definition, the key can be reconstructed by the authorised threshold t, because they can share their nonce contributions and extract the private key using the nonce. This isn't usually discussed, but here we have an external party that'd prefer not to be attacked by the group, so to speak.

About initial setup/delegation, my thinking is: a protocol could allow you to delegate authority to do specific things (like sign) by a direct signature on your main key saying "this sub-key is authorised to sign these events" and then that subkey could be generated collaboratively in a normal way. Common way of using digital signatures (delegation to another key), but admittedly it can be a can of worms...

Pretty sure I agree that FROST is closer to the mark in what @fiatjaf is looking for, but specifically the signing algorithm and not the keygen algorithm. FROST (and Pedersen DKG before it) were advancing the state of the art by allowing for no central party (or aggregator/dealer) to be in possession of the whole private key at any time, either in key generation, or in signing. Here I guess you want to reset back to the earlier SSS basic idea of having the central party know the key in advance, then construct the individual shares such that they sum to the pre-existing key x, instead of following FROST's KeyGen to generate the shares.

But the "massive caveats" I mentioned in the other post still apply; it seems unlikely you'd want to allow the possibility to collude to take your full key.

OK yes I see. It seems difficult because a musig aggregated key is not a linear sum, to avoid the possibility that less than N can forge a full signature using key subtraction attacks. Constructing the key is an interactive process that produces an unpredictable final key, by design.

Perhaps you can attach a proof of knowledge of each "key portion" works though: you distribute secret keys x1, x2 and x3 such that x1 + x2 + x3 =x, your key. Then when they go through the signing process they add a signature over their key portion at the start. This prevents them from doing key subtraction to forge with < N parties. Then they can go through the normal process of 3 round MuSig - commit to their R portion, then reveal their R, then the final signature on P is the sum of the signatures on P1, P2, P3. Two obvious problems stand out: they can collude to extract your full key; usually that is not acceptable. And of course the fact that signing becomes interactive.

Overall it doesn't seem very practical, and heck, don't even quote me that it's possible or sound, I'm not sure. Even with the massive caveats above. Various kinds of delegation or setup with the initial key, whether using existing FROST or MuSig, feel like they make for a sounder approach.

Great work.

I agree that of the several fascinating things about the story, the depositing of 5M in cash to a bank, is the most incredible.

Lol. Good point. But what is good here. Don't traffic lights go yellow (amber) to green?

I remember thinking "I don't know if that's possible" but also thinking "does that question make sense"? If i use some xor/whatever to make 3 shards, don't I still have the original secret key. If that doesn't matter, and you just want the others to attest, or something, then just use their own keys? I guess I just don't get your point.

Obviously both N of N and M of N collaborative control of newly generated keys is well understood (albeit a bit complicated!).

Vid appears to be working here, let me know if it doesn't load for you, I'm curious.