calle's avatar
calle calle@cashu.me 1 year ago
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?
↑ Parent

Replies (1)

waxwing's avatar
waxwing 1 year ago
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.
1 replies ↓
↑