Quote from: NotATether on April 11, 2023, 07:25:51 AM

Quote from: whirlwindmoney on April 11, 2023, 03:12:36 AM

The flow looks like this: User deposits 1.1BTC using the Note method and now holds a private key. With this private key he would then issue two Blind Certificates, one of them for 1BTC, and the other for 0.1BTC. Now his deposit is provably anonymous. Whenever he wants to withdraw, he redeems the two Blind Certificates for one or more Notes, and he follows the normal Note withdrawal procedure. In this case the user would be protected by 2 Anonymity sets, the public one which is the one that is now shown on the website, and by the Blind Certificates one, which proves beyond any doubt that you indeed got complete anonymity using the service.

I don't completely understand where the two anonymity sets come from. Do you mean the coins are taken from the 1BTC and 0.1BTC anonymity sets? And in which order?

My bad, in fact in my example there are 3 Anonymity sets involved. One of them is the public Anonymity Set visible to anyone on the website (total number of deposits), the second one is the 1BTC Blind Certificate Anonymity Set, and the third one is the 0.1BTC Anonymity Set.

For an outside observer only the public Anonymity Set matters since he won't even be able to know if you used Blind Certificates or not. As long as you believe we don't store logs then the public Anonymity Set should be the only one that matters to you too. But if you are concerned that we store logs/act maliciously then the figure you should care about is the specific blind certificate's anonymity set that you are using at that time.

Quote from: LoyceV on April 11, 2023, 08:02:21 AM

While discussing Bitcoin privacy and blind certificates, I think this topic (from 2016) never received the attention it deserves: Hiding entire content of on-chain transactions. The same author later implemented it as blackbytes, but it never took off. I'm not quoting the entire post, please just read the topic. I'll only post this summary:

Very interesting - I think it's important I mention that when applied to our use-case actual Blind Certificates would introduce at least one huge security issue, but thankfully we already found a solution to this in case we ever need to implement it.

Quote from: tonych on September 09, 2016, 12:32:05 PM

Quote from: dinofelis on September 09, 2016, 11:23:31 AM

You are reinventing zerocoin.

Not at all. Zerocoin is based on zero knowledge proofs, while Byteball's private payments don't rely on any advanced crypto, just plain old hashes.

Our implementation would have to involve zero knowledge proofs and in short here is why:

We decided to use Groth16 ZK-SNARKS for this, instead of blind signatures, because of an important security problem in our architecture with blind signatures: if the private key which is used for the blind signatures is stored on the backend server, an attacker which compromises it would be able to forge certificates which the validators will trust, and therefore draining the wallet, basically making the backend+validator architecture that I explained in a previous message useless.

With a ZK-proof, the attacker would not be able to do this, because the secret witnesses used to prove a certain withdraw is valid is generated by the user in the frontend, so not even the backend can forge these proofs. At some point, we will make the frontend open source, which will reveal all of the backend’s endpoints, so you can build/host your own frontend for this, or even create a CLI.

The architecture would look like this: we store a merkle tree of the users’s public statements in the database. When a user redeems a note for certificates, we store the user’s public statements in the tree. When a user wants to redeem the certificates for a note, the frontend, using the user’s secret witness, will be able to prove to the backend (AND the validators) that he has the secret witness of a certain leaf in the tree, without actually saying which leaf it is. This makes it totally anonymous towards us, the operators, as well.