Oddbean

Question for @calle 👁️⚡👁️ 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

That's very interesting, it would indeed be very useful for mints not having to reveal their UTXOs for a proof of reserves. Thanks for noting that. I haven't been able to look at your protocol yet so I have a rather basic bunch of questions that come to mind: - The ~55 Mb keyset file you load seems to have information up to a certain block height. Is this file generic for the entire chain or custom to the prover? - The processing of the file takes quite some time and you mention this can be done once and proofs can be checked faster after that. Does the client need to do the processing or could someone else do it for them? - Does it require processing custom to the prover or can it be used to prove anyone's claim? - Is there a window for cheating when the file is for a lower block height than the current one? Since I don't know the UTXOs, is there a way to make sure the coins haven't been moved since the proof was made? - The range was from 100k to a power of two, you say it's just the way you set it up. Can the range be arbitrarily precise?

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.

I’m intrigued but lack the background to really understand these things. I plan to learn more soon, but would appreciate if anyone could point me to a solid resource for understanding ZKPs and the like as a starting point

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.