Topic: Ultimate Bitcoin Privacy - Discussion - page 5. (Read 1648 times)

Blinded bearer certificates are indeed a bit complicated to comprehend, but really the only thing that you have to understand is that by using these it becomes possible to prove possession of information without revealing it, and this is very useful for privacy. For example we have 100 users that each has a Certificate worth 1BTC, so 100 BTC in total. It is possible for any of the 100 users to prove that he is owed 1BTC without revealing which BTC was originally his.

In order to understand why something like this is needed in the first place you have to be aware of the issues of all current centralized mixing solutions:
1.Can't trust the no-logs policy as there is no way the service can prove it doesen't log information
2.Operator is a single point of failure, so there is always theft risk/servers being seized etc.

This makes it impossible to be sure that your "mixing" was done properly and that your coins are really anonymous. Even if you trust the operator other entities may be "listening" so really you can assume that everything is an open book.

We aim to solve both of these issues starting with the first one, but the backend was built in such a way that it's pretty easy to decentralize everything completely assuming we find the right people to run signers alongside ourselves.

Everything will be explained in a much more professional and easy to understand manner before we actually start the service, for now I just wanted to start a discussion and see how the community reacts to something like this. Given that it's something completely new in the Bitcoin space I expect lots of questions, but I'm sure once you understand how it really works you will see the value.

Our service will be very easy to use, there are just a few steps involved for any method you would choose, the flows are as follows:
For fast: select withdrawal addresses/amounts/fees->deposit BTC->receive BTC
For slow: save Note->deposit BTC   /to withdraw from Note: input Note->select withdrawal addresses/amounts->receive BTC
For blinded certificates: Note->blinded certificates   /to withdraw from blinded certificates: blinded certificates->Note

Exchanging your Notes for Blinded Certificates and then back to Notes will make you completely anonymous to any observer including the operators. Essentially if you want to ensure anonymity the flow would be: save Note->deposit BTC->Blinded Certificates->Note->select withdrawal addresses/amounts->receive BTC

I will consider launching a testnet version too, but at the very least we will pay for a review campaign and have very low/no fees for the first few weeks in case we don't do it.

I think that's because blinded bearer certificates are quite complicated to understand. I read about it a few times, and I read your OP, but it's still unclear how it would work exactly.
Can you start by creating a live working version on testnet, before going for real Bitcoin? My guess is you'll have much more users testing your service when they don't risk real funds.

Agreed. If you can't present how it works in such a way that the reader quickly understands it, he'll move on to another service.

Point No 1 Op please make sure to edit your post and make it worth reading as its very hard to find what is ongoing in the particular section of the topic.
For your policy first I would like to read the question you raised about the depositor's information I would like to know how you are going to take us in confidence that your policy is best with the blind bearer certificates? or if there is something else
Because the question you raised is first pointed to your model what is the guarantee of the user's funds security and anonymity because the archive download is the problem?

More information is needed as it's not enough to convince someone

I am not familiar with the maximum mixers working but for the basic part, I understand it well.

Edit
For the download problem i got my answer in above reply ... rest of the things lets see how others respond to it.

Thank you for the suggestion but this is just a topic to get some feedback, not to promote the business so I'm not focusing on optics too much for now.

I wish you would've read my post entirely and check the facts before replying, this is a "real plan". Pretty much all of your concerns were addressed but I'll go through each point again
You don't necessarily have to download the archive, you could copy each certificate manually. And if this is still not enough, we will open-source the front-end and you could run your own build and check that the certificates are generated by yourself in the front-end, not by our backend.

Blind Certificates seems like a new concept (to me).  But if some body does not trust you.  How do you expect them to trust DOWNLOADING an archive that supposedly contains nothing else other than the Blind Certificates?  If I had close to zero trust in some website and they told me they can fix this by letting me download some archive, I would close the tab right away and pick an alternative business.

-
Regards,
PrivacyG

So you are making a mixer.
And then you reference tornado cash. Those developers wound up getting arrested and lots of people lost access to funds.

Come back with a real plan on how you are going to secure the funds, make sure 'the man' can't get your info, how you will protect against hacks, how you will avoid possible regulations, and so on.

-Dave
 

If you're serious, you'd better edit the post, separating the paragraphs properly. Presenting a business model in this way looks messy and therefore not very appealing, no matter how interesting the business may be.

Later this month I will be launching a unique service aimed at making your Bitcoin history private in a provable way, something that was suggested for a long time, but has not been done until now. The goal of this topic is to start a discussion about this model and get as much feedback as possible from the community prior to launch.

Brief Description
There will be 1 aggregate address for all deposits and withdrawals
There will be 2 modes, fast and slow
The fast mode works like most other tools where you get a deposit address, you select the number of withdrawal addresses together with the amount for each and the time delay (0-200 hours), and then you receive the Bitcoins to the indicated addresses.
The slow mode allows you to deposit Bitcoin and instead of sending all your Bitcoins to new addresses now, you get a “Note” in return. With this Note you can come back later at any point in time and withdraw any amount from it to as many addresses as you want. The notes can also be combined together so that you can have full control over the process. As an example you could deposit 0.5 BTC 5 times and get 5 different notes, combine them together and withdraw 1.5 BTC after 2 weeks and the remaining 1 BTC after another 2 weeks, making it very hard for any outside observer to know where your BTC came from since the originating transactions could have happened at any point since the launch of the service and both of your outputs are higher than any of the inputs.

These 2 modes both have one big drawback, your transactions are anonymous to the public but are not anonymous to us since there is no way for us to reliably prove that we enforce the strict no-logs policy. We came up with a solution to this issue, the Blind Certificates, which you will find out more about later on.

Detailed Description
Since we are using a single aggregate address for all deposits and withdrawals, holding its private key on a server would be a risky move. That is why we decided to use a backend+validator model. The backend’s job will be to interact with end users by generating deposit addresses, processing withdrawals, minting/burning blind certificates (explained below), etc. In the initial design, there will be x validators which will validate all of the backend’s actions (verify funds were received from the deposit address to the main aggregate address, verify submitted blind certificates or credit notes for withdrawals). These x validators will hold the multi-sig keys for the main address and will be hosted on different servers. Whenever a withdraw transaction is being sent, the signatures must be retrieved from all validators which are able to verify the transaction is correct. If an attacker manages to gain access to the backend, it would be pointless, as he will not be able to steal the funds (since the keys are on different servers), and he will not be able to forge proofs in order to withdraw another user’s BTC to his wallet. Using this model, we will be able to further decentralise this service by allowing other trusted members to run their own federated validators so that a single entity will no longer hold all of the multi-sig keys.

When a user deposits BTC using the fast withdraw method, the backend sends the deposit hash to the validators and whitelists the receiving addresses. After the signature is sent to the backend, the validators delete all proofs of those receiving addresses, keeping only the deposit transaction hash so that they would not accept a “duplicate proof”.
When a user deposits BTC using the slow withdraw method, the backend sends the deposit hash to the validators and they assign credit to the note’s public key. When the user wants to withdraw his BTC, he must send a signature to the backend which will process this. This signature will also be sent to the validators which will check it and remove credit from the note’s public key and whitelist the receiving addresses. If an attacker compromises the backend server, he would not be able to forge user note signatures in order to fool a validator to send him funds, because only the users have access to the notes’s private keys. Again, the proofs are deleted after their use.

But what if you don’t trust us? What if you don’t believe that we will delete these validator proofs? Well, this is where the Blind Certificates come in handy. You will be able to redeem your note received from a slow deposit in order to mint blind certificates. There will be 0.01, 0.1, 1 and 10 BTC blind certificates. For example, if you have a 11.245 BTC credit in your deposit address, you will receive a 10 BTC certificate, a 1 BTC certificate, 2 0.1 BTC certificates and 4 0.01 BTC certificates. You will be able to download all these certificates at once (probably in a ZIP file generated by the frontend), and then spend them however you like. The rest of 0.005 BTC will be left in the main wallet. You will then be able to redeem these certificates for credits in new notes, which you will then be able to use for withdrawals.
Blind certificates work in such a way that, even if we logged every single action, we would still not be able to connect a deposit -> note -> blind certificate action to its corresponding blind certificate -> note -> withdraw action.
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 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 is really similar to Tornado Cash’s architecture: 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.
We decided to use Tornado Cash’s exact ZK-SNARK circuit for 2 reasons:
A) Groth16 circuits require a setup procedure in order to generate verifying and proving keys (both public) to make the whole ZK system work. This must be done in a multi-party process called a ceremony. When generating these keys, multiple parties must participate. The more the better, since the circuit only becomes compromised if 100% of the participants acted with malicious intent. The ceremony which generated Tornado Cash’s circuits keys was one of the biggest ceremonies of this kind (1114 participants), so it’s highly unlikely that the circuit could be compromised. You can read more about it here: https://tornado-cash.medium.com/the-biggest-trusted-setup-ceremony-in-the-world-3c6ab9c8fffa
B) The system is battle tested. All of the system actions with Tornado Cash are completely public to everyone (in our case, theses actions would only be public to us), and it’s still 100% anonymous.

Looking forward to your questions/suggestions!


References: (https://www.reddit.com/r/Bitcoin/comments/5ksu3o/blinded_bearer_certificates/)
https://theymos.com/case_for_bcerts_18.pdf