Ultimate Bitcoin Privacy - Discussion

[whirlwindmoney]

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

[1714290739]

1714290739

[1714290739]

1714290739

[1714290739]

1714290739

[1714290739]

1714290739

[1714290739]

1714290739

[Cuenta Alternativa]

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 (https://www.reddit.com/r/Bitcoin/comments/5ksu3o/blinded_bearer_certificates/), but has not been done until now.

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.

[DaveF]

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
 

[PrivacyG]

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

[whirlwindmoney]

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 (https://www.reddit.com/r/Bitcoin/comments/5ksu3o/blinded_bearer_certificates/), but has not been done until now.

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.

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.

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
 

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

Those developers wound up getting arrested and lots of people lost access to funds.

NO ONE lost access to funds, it's technically not possible
Only one of the developers was arrested, another one is actually launching another mixer as we speak.

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.

The funds will be secured by a multi-sig from day 1. As explained in the first post we are also open to welcoming other trusted users to run their own signer so that no single entity has access to the funds by themselves anymore.

If you have some specific concerns/questions I'll be happy to answer

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

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.

[Hamza2424]

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.

[LoyceV]

something that was suggested for a long time

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.

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.

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.

[whirlwindmoney]

something that was suggested for a long time

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.

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.

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.

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.

[nioctib_100]

I'm looking forward to helping test and review this. The trust is a big challenge, but I'm willing to be open-minded and allow Whirlwind the opportunity to prove that this can work, which we will all see in the testing/review period.

I was right there when the idea was first floated (https://bitcointalk.org/index.php?topic=2827109.msg61883998#msg61883998), and Whirlwind wants to eventually evolve into a decentralized version. That's the ultimate final goal here, and as far as I can tell, it's never really been accomplished in a version of what was described. If we want that goal, I think we need to support this venture as best we can through the less trustworthy, centralized version with an understanding that in the end, a decentralized model will be delivered.

[whirlwindmoney]

I'm looking forward to helping test and review this. The trust is a big challenge, but I'm willing to be open-minded and allow Whirlwind the opportunity to prove that this can work, which we will all see in the testing/review period.

I was right there when the idea was first floated (https://bitcointalk.org/index.php?topic=2827109.msg61883998#msg61883998), and Whirlwind wants to eventually evolve into a decentralized version. That's the ultimate final goal here, and as far as I can tell, it's never really been accomplished in a version of what was described. If we want that goal, I think we need to support this venture as best we can through the less trustworthy, centralized version with an understanding that in the end, a decentralized model will be delivered.

I am open and would actually prefer to start the service in a decentralized manner, I just think it's difficult to find at least 3 trusted members of the community willing to be part of the multi-sig and run a signer. If anyone has ideas how this could be achieved then we just solved one of the 2 big issues as funds wouldn't be at risk anymore. The only issue left would be to ensure that the no-logs policy is enforced, and that will be achieved through the Blind Certificates. Even if we assume that logs are kept for fast and slow methods, if Blind Certificates are used then there is no way for us to log anything as we don't know the information in the first place.

Note: Infrastructure is created in such a way that the signers wouldn't know the rest of the signers/servers IP's so even if one would want to act maliciously and disclose all IP's from the rest of the infrastructure he couldn't

[LoyceV]

I just think it's difficult to find at least 3 trusted members of the community willing to be part of the multi-sig and run a signer.

Would that mean manually approving every withdrawal?

There's a complication: considering recent events, being directly involved in any form of coin mixing could mean legal problems. Since you're looking for trusted and thus well-known people, I doubt they'd want to risk that.

[whirlwindmoney]

Would that mean manually approving every withdrawal?

Everything is automated so any new signer would only have to set everything up once.

There's a complication: considering recent events, being directly involved in any form of coin mixing could mean legal problems. Since you're looking for trusted and thus well-known people, I doubt they'd want to risk that.

Someone that is trusted and anonymous would be a great candidate, but I agree that finding this will be very challenging. I will probably launch it by myself and then look into this again once we got some traction. Given the rewards signers would get it will hopefully become attractive enough to make it worth it for some to join us. Everything will be upgradeable so when we find the right people the whole transition process will take a few hours at most.

[Dunamisx]

From what i can sense in your post and your copper membership purchase is that you're giving a brief overview of what is expected from you in the proposed service you want to render which sounds to be a mixing service, well this could actually be a prelaunch advert on what you've got to offer and i will will further advise you try create a discussion thread on it under services development and technical discussion and appear the normal way and possibly create an ANN thread as well for your discussion, lastly you can as well advertise yourself by creating a signature campaign.

[nioctib_100]

I think it's going to be pretty tough or nearly impossible to find three trusted people who would be willing to be signers right now, both because of Chipmixer getting shut down and because you're still very new. I also think we could have a discussion/debate about if a set of 3 people as signers is decentralized. What number is sufficient? 5? 10? 100? I wonder if there's some sort of situation where this would be more decentralized than 3 people. Anyways though, as stated before, creating the centralized model first is the right path to test the waters and to gain trust in yourself. Are we any closer to seeing the first test version or anything like that?

[whirlwindmoney]

From what i can sense in your post and your copper membership purchase is that you're giving a brief overview of what is expected from you in the proposed service you want to render which sounds to be a mixing service, well this could actually be a prelaunch advert on what you've got to offer and i will will further advise you try create a discussion thread on it under services development and technical discussion and appear the normal way and possibly create an ANN thread as well for your discussion, lastly you can as well advertise yourself by creating a signature campaign.

I'll gladly move the topic to another category but I am not sure which one fits this discussion better. I will create an ANN thread and signature campaign so I will lock this once I start those.

I think it's going to be pretty tough or nearly impossible to find three trusted people who would be willing to be signers right now, both because of Chipmixer getting shut down and because you're still very new. I also think we could have a discussion/debate about if a set of 3 people as signers is decentralized. What number is sufficient? 5? 10? 100? I wonder if there's some sort of situation where this would be more decentralized than 3 people. Anyways though, as stated before, creating the centralized model first is the right path to test the waters and to gain trust in yourself. Are we any closer to seeing the first test version or anything like that?

3 people is by no means decentralized, but it's definitely better compared to only us while we're new and not trusted.  This number could easily grow to 100 assuming we have the right candidates and this is the right way to go, but I'm not sure it makes monetary sense. Anyways as you said it's too early for this kind of discussion, we'll come back to it once we're established.

The product is finished since more than 1 month, we just took the time to extensively test every feature since it's something new. We will launch the V1 in the first half of the upcoming week, start a review and signature campaign and see how things evolve from there. We will also deposit some BTC in escrow so users trust at least trying out the service as I'm sure once they do they won't look back

[whirlwindmoney]

I want to share some updates until we start our ANN thread and Signature campaign later this week, hope this category is fine.

The service is accessible using the following link:
whirlwct7ertqae6i7ivsm475kgia6v67zzxevgzkilykknrjke33cqd.onion

The fees range between 0.25%-4% depending on the user's choice. BTC will be continously added to the reserve during the next days.

The discussion around Blind Certificates remains open, we will develop the final system after more talks with the community since we feel like this could be a huge step forward for privacy if executed correctly, it's just too early for that.

[nioctib_100]

The site looks great! It's very accessible with a lot of the mixing inputs on the first page. Being able to mix coins in just a few minutes with above average anonymity is a great feature. Of course, everything relies on the trust of the provider, it's all a spectrum, and it's going to be great to see you all develop as time goes on. Improve and innovate quickly, there is a big gap to fill right now with Chipmixer gone!

[o_e_l_e_o]

A few questions:

Am I correct in saying the notes you talk about on the Tor site are not blinded bearer certificates? Rather, they function similarly to ChipMixer chips, in that I can combine or split them and redeem them later, but they are not blinded to you?

Once blinded bearer certificates are operational, how does the end user protect against your service/website being seized/shutdown? How could they redeem their certificates in such a case? How would they be able contact the threshold number of signers in order to redeem their certificate and receive the corresponding bitcoin from your multi-sig wallet?

[whirlwindmoney]

The site looks great! It's very accessible with a lot of the mixing inputs on the first page. Being able to mix coins in just a few minutes with above average anonymity is a great feature. Of course, everything relies on the trust of the provider, it's all a spectrum, and it's going to be great to see you all develop as time goes on. Improve and innovate quickly, there is a big gap to fill right now with Chipmixer gone!

Thanks, the privacy set will only grow stronger the longer the service will be running so I hope that once it gets traction we can find a solution to split the "ownership" of the platform with more users in order to minimize risks on all fronts.

A few questions:

Am I correct in saying the notes you talk about on the Tor site are not blinded bearer certificates? Rather, they function similarly to ChipMixer chips, in that I can combine or split them and redeem them later, but they are not blinded to you?

Once blinded bearer certificates are operational, how does the end user protect against your service/website being seized/shutdown? How could they redeem their certificates in such a case? How would they be able contact the threshold number of signers in order to redeem their certificate and receive the corresponding bitcoin from your multi-sig wallet?

You are correct, the notes are not blinded certificates as in we could keep logs if we chose to. We are not, but there is no way for me to prove this so this is why I want to implement the blinded certificates, after that the user won't have to trust us anymore.

Regarding the service getting shutdown, blinded certificates and notes hold the same risk as you store your BTC in our multi-sig until you decide to withdraw. I could give more technical details about our security, but all I will say for now is that we took the most extreme security precautions possible. Our "hot wallet" is a 3/3 multi-sig with one of the signers being a physical server, so funds are safe. The infrastructure looks like a mini blockchain (with only 3 validators or signers which are all run by us for now), so even if the frontend or backend servers would get hacked, no funds could be stolen since faking guarantee letters using the backend server doesen't do anything as the signers would also have to verify. It's complicated, but like I said before if I'll find willing trusted members to run signers with us I am willing to do it.

Having said all of the above as far as I'm concerned I am not doing anything illegal. I don't encourage illegal activity and will never promote the service on the darknet or for any illegal purposes, I'm a simple provider of privacy services. There are no statistics regarding % of CEX funds coming from illicit sources so we can't compare to what we know about mixers, but my guess is that the number is very similar if not higher for centralized exchanges. There are bad actors in every industry, you can't just shut down all businesses of one type because of a few bad apples. If the service will start to get seriously abused by bad actors and big pressure will be put on us then I'd much rather shut down the service early and honorably than put users funds and privacy at risk, but for now I still believe there has to be a way to run everything legally. This is not because I don't believe Bitcoin is fungible or anything of this sort, but regardless if the service gets seized or sanctioned, the end result is the same as in it can't really be used anymore, so everyone loses. Having great security is a must, but relying on this by itself doesen't generate any value for the long term. I'd much rather try to find a way in which everyone is happy, or at the very least not too unhappy, while users enjoy full privacy. This is what they pay for and nothing less is acceptable

With the Blind Certificates I talked about in my previous posts it may be possible for users to prove their funds don't come from specific addresses linked to hacks/ransom/etc., so if that is possible then honest users have a way to prove they are not thieves while retaining privacy, and bad actors are isolated so sending the BTC to whirlwind is pretty much useless if they plan to use centralized services afterwards since they couldn't prove they are not one of the bad actors. It's too early to talk about this since we need to get some users first and get some actual demand for something like I outlined above.

[o_e_l_e_o]

Our "hot wallet" is a 3/3 multi-sig with one of the signers being a physical server, so funds are safe. The infrastructure looks like a mini blockchain (with only 3 validators or signers which are all run by us for now), so even if the frontend or backend servers would get hacked, no funds could be stolen since faking guarantee letters using the backend server doesen't do anything as the signers would also have to verify.

I understand that, but my concerns was more about how users would be able to redeem their certificates should your service be seized or shutdown. It doesn't really matter that the funds are secure and cannot be stolen by third parties if the real owners cannot access them either.

And if you have a solution to this problem, how would that change if you move to multiple third party signers as you have mentioned above? Would I have to go to each signer individually and have them validate my certificate and approve my withdrawal? How would I even track down the signers in your absence?