I've written a blog with a proof of being a satoshi millionaire, that does not reveal where my funds are on-chain. Bukele and Coinbase take note pls :)

https://reyify.com/blog/privacy-preserving-proof-of-taproot-assets

Reply to this note

Please Login to reply.

Discussion

Coinbase works with US government agencies so they won't need it. Not sure about Bukele either.

Yeah there's both a cynical and a non-cynical dismissal of my suggestion to Coinbase custody here.

The non-cynical one would mention that the taproot-only restriction is very significant to them (both smaller anon set and disruption of their workflow; for their security measures they'd probably dismiss such a disruption out of hand; don't underestimate how slowly tech processes can change in big institutions). It would also mention that this is only addressing proof of *assets* not liability proofs which has tended to be the much bigger sticking point. For myself, I would find even *just* a proof of assets from entities like Coinbase custody or Bukele, to be a very good thing.

Binance uses zk-SNARKs for proof of solvency, but it made no difference: https://www.binance.com/en/blog/tech/how-zksnarks-improve-binances-proof-of-reserves-system-6654580406550811626

I like aut-ct, though I believe it has different use cases. In fact, I recently mentioned it in this thread: https://delvingbitcoin.org/t/proving-utxo-set-inclusion-in-zero-knowledge/1142/2

Yes, I did see (at least what's publically written) about Binance. It's not really either clear what you are saying (it didn't make a difference to what, precisely?), nor what the right choice is for each situation. A ZkSNARK nor a bulletproofs or other similar ZKP system won't be needed for the *assets* side of a proof of reserves, *if* you don't care about onchain privacy - which Binance doesn't; they just publish all the onchain addresses. While those systems can help a lot with the trickier proof of liabilities. If you do care about onchain privacy, these systems have tradeoffs; to get a bigger anon set on bitcoin than taproot, you have to address the hashing problem. The original Provisions protocol of Bunz completely sidestepped this problem; with zksnarks you *can* address it but it is quite, quite tough because you have to build multiple non-algebraic hash function circuits. The result is that at the very least, pre-processing takes horrendous amounts of time.

Also, thanks for the link to halseth's post, very interesting!

In this system, can't I create a taproot key with pubkey (xG+tH) contributing (xG+(t+v)H) to the curvetree, and use that to provide a false proof that I have t sats more than I ever had (and t+v sats more than I can spend, since such a pubkey is unspendable)?

The tree is constructed publically (so both by the prover and the verifier, and whoever), from the public data of taproot pubkeys and sat values of the utxos. The privacy comes from the select-and-rerandomize algo, which makes a blinded version of the commitments xG + vH (in this application), adding rJ. So you can't claim a pubkey or amount that is different, and your knowledge of the private key is ensured by the proof of representation (see 3.6 in the paper).

Is there a comparable proof with segwit or pre segwit utxos?

It's a lot more difficult, because the pubkeys are hidden behind hashes, so without the owner's cooperation you would have to use ZKPs of SHA2 and RIPEMD hash preimages, which is very expensive/complex comparatively.

Is there a how to somewhere to be found? I'd like to try this for a possible usecase of mine. Maybe even a ready script? Would pay for it.

Yes, the docs of the repo explain how it can be done (the readme links to auditor-docs at the top).

It's a pretty involved process, for several reasons.

I'm looking into building a GUI right now.