Topic: Ultimate Bitcoin Privacy - Discussion (Read 1573 times)

I just got my first note funded.

In the meantime I wait to  lower fees ti transfer to my private address, I am enjoying a 12% APR.

https://whirlwind.money/faq#anonymityMining

I admit I didn’t read the whole thread, so I do apologise if I am making a stupid question.

Currently, I am aware of three “mixing” techniques/wallet/software, each of them with peculiar pros and cons: Wasabi, Samurai and Joinmarket.

How would you position Whirlwind regarding those position advantages/disadvantages?

I don't get what it would do. Say Bob sends Alice money to a Note. Bob gets a LoG to prove it, and Alice withdraws her money to her on-chain Bitcoin address. What would Alice need a LoG for?

My intention was to make it clear that Whirlwind addresses don't need to be 'initialized' in any way. if someone sends you funds through Whirlwind without you ever entering the website before you can still access them with your private key.

The sender could make an on-chain transfer to your address, but that means he would know where you withdrew your Bitcoin. If he uses Pay to Note then you are anonymous even to the sender. of course you should always know beforehand where you will be sent the funds, I wouldn't appreciate this kind of 'surprise' either.

Nothing will ever be as strong as on-chain evidence, but for the Pay to Note feature you need to rely on the Letter of Guarantee since there are no on-chain transactions being executed. We could also provide a Letter of Guarantee to the receiver which would be downloadable from the 'Dashboard' page for the first x hours after the transaction. Do you think this would be useful in any way?

I'm quoting OP from another topic to bring the discussion here:
(I've shortened the quotes a bit to focus on the relevant parts)

I have some doubts: if I'm expecting a Bitcoin transaction, I wouldn't appreciate being told to use a third party to collect my money. The sender could instead have withdrawn the note himself, and sent an on-chain transaction to my address.
As a sender, I also wouldn't really want to rely on a third party to send funds and provide evidence. No matter how trusted your service becomes, it's never as strong as on-chain evidence. Unless you don't want an on-chain transaction trail of course.

We simply do not want to add more moving parts where they are not necessarily needed in order to improve stability. The backend and signers have to validate every single action and adding more friction at the withdrawal stage by making the fees dynamic doesen't seem like a good idea. We'd prefer to eliminate them altogether if this is really an issue, we want the system to work without ever needing our intervention and we achieved this in the current form.

It's a misunderstanding, Blinded Certificates are not implemented in the current version. I explained how it would work in Whirlwind's case in the messages I'll quote below, but we are not really in a rush to implement it as it's quite apparent most users don't care that much about this aspect so it's not yet a priority.


And here is a more technical explanation for why Blinded Signatures are not enough in Whirlwind's case and why we would need to use zk-snarks instead:

Apologies for my difficulty to comprehend blinded certificates, but I still don't understand what prevents you from keeping logs which would give away the activity of the users. For example, I created a note and deposited money to an address tied to that note. You could have kept that. Then, when someone sent me money to my public address, you could have known which note was spent in which public address.

Unless the front-end is coded in such manner that prevents the unveiling of that information, I don't know how provable privacy is ensured.  

Okay, but that doesn't answer on why having arbitrary fee rate. The network could be flooded with transactions such that maybe 2500 sat/addy is neither enough.

Multiple reasons:
1)Security is our top priority so in order for the signers to be able to register and validate each deposit 100% reliably, the transaction from the intermediary address to the multi-sig needs to be broadcasted. We are sacrificing some sats paid extra in fees for an unbreakable system in regards to loss of funds for any reason other than us, the operators, acting maliciously.
2)We might not necessarily pay extra in fees since right now we can broadcast all deposit transactions deposit x > multisig on a very low fee regardless of congestion. Output transactions from the multi-sig need to be broadcasted with higher fees so they don't get stuck.
3)We want to leave some UTXO's available in case a transaction still gets stuck even with a higher fee

Other than working on other features and exploring ways to decentralize the service completely our job should now be as easy as this: pay the servers and change them once in a while just in case. Whirlwind could be considered a blockchain, the only missing piece is decentralization meaning more signers. We are considering a system where in order to be a signer you are required to deposit a certain amount of BTC, and we implement a slashing mechanism to deal with bad actors. We will give more details once we have an actual plan, until then we're patiently waiting to see if demand for something like this actually exists. From a technical point of view we are by far the superior privacy solution available for Bitcoin today, so if something like this isn't used (even when it's essentially free) then it's certainly not worth wasting time to develop it further.

It looks like you're first sending all deposit to your own multisig address, and then consolidating them again into the same address. Why don't you skip a step by consolidating deposits while processing withdrawals?
So instead of:
deposit A > multisig
deposit B > multisig
multisig > multisig + withdrawal C
You'd get:
deposit A + deposit B + multisig > multisig + withdrawal C

blindmixer might be a nice example of this: we already utilize blind schnorr signatures, and have full non-repudiation:

every action taken by the client requires a signature that only the client can generate, as such we cannot dupe any single user with it being proveable.

A consequence of this is that it is a little more complex than a single webpage: the client needs to actively generate signatures and store them. JS will be required. Still, we believe that we packaged it as simple as possible for the average user.

A huge drawback currently is that our scheme is centralized, meaning that we can exit-scam at any point. We have looked into using a MuSig scheme with multiple signers, and it should definitely be possible. Don't think it will play very nicely with lightning as of right now, but that will undoubtedly change in the future.

We could let users withdraw arbitrary amounts like before too after clicking a checkbox saying something along the lines of "I understand that if I withdraw an arbitrary amount my withdrawal could be deanonymized under certain conditions", but there are not many arguments in favor of it since the privacy levels increased by multiple folds with the introduction of fungible outputs, and if you are really that concerned about the 2500 sats fee you can just keep the balance on the Note until you reach a fixed amount that you can withdraw at once. Transfers between Notes are 100% free, not subject to any 2500 sats fee.

We can't let users choose the fees themselves because all transactions are sent from the same multi-sig so we can't really afford to have any of them stuck for a long time. Assuming the user chooses 0% donation if we pay more than 10 sats/vb for his individual withdraw then we're losing money. On the other hand in a month we lowered the fee 6x from 15000 sats to 2500 so this is already some good progress and cheaper than anything else, and depending on the profitability we'll eliminate this altogether.

Our multi-sig is always visible at this address:

https://mempool.space/address/bc1qf8h5k6sash8007vpesymxkw2xsg5d0r3j4l5vmcrwpz2pqu66fjstzgd3r

We are showing the Anonymity set on the website too so users are aware of the exact level of anonymity they are getting when using Whirlwind and to make it easier for them to figure out when new deposits were made without having to check the chain themselves. Again this is public knowledge so there is no reason not to show it.

Tried it. I created two notes, got their public addresses, and sent bitcoin back and fourth. The inconvenience I notice is that I must withdraw fixed amounts (e.g., 0.001, 0.005, 0.01 etc.). Fixed amounts isn't the problem per se. What might annoy someone is that you enforce an arbitrary fee rate (2500 sats per address). I don't get why you don't let the users choose themselves. At the moment, I have about 800,000 sats in notes, and I'll have to mix another 200,000, so I can merge them together into 0.01, to save 7500 sats in fees.

You're also showing in the main page how many anonymity sets there are. Is it because it's trivial for an advisory to figure that out in the chain?

Crossposting this - very exciting news, please let us know what you think!



We just completed the most important upgrade to date, the changelog is available at the end of this message. Some major changes have been made so we suggest everyone reads the FAQ again and perhaps even give the service a try with a small amount since it's essentially free now. We will also work on video tutorials now that the platform will be mostly unchanged going forward. ANN thread presentation will also be updated to reflect the latest changes.

We are most excited about the introduction of the Pay to Note feature and fungible outputs.

The Pay to Note feature enables instant, feeless and anonymous BTC transactions. Gone are the days where you want to send some Bitcoin to your friend but you worry about him checking out your past transactions so instead you are forced to use Monero. Now it's possible to do everything with Bitcoin with much more convenience and in much better conditions since all transfers are instant and free. Whirlwind is the first and only service to ever implement such a feature and we hope that our users see the value and opportunities that this brings.

Outputs are now fungible, meaning every single withdraw will look exactly the same for outside observers. This greatly increases privacy for all users since it's much harder to track what is happening behind the scenes only by looking at transactions.

We are ready to answer any questions and looking forward to read your feedback.

p.s. Clearnet is still under DDoS and offline, please use the Tor version for now. We will solve this issue too in the following days, apologies for any inconvenience caused but this was not a priority.

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.


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.


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.

Can you (significantly) increase the resolution? The small font doesn't do it justice.

---

---

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:

Excellent stuff, but I think you should make the image a little bigger, as it is hard to read the small parts of the text without clicking.


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?


Of course, the rouge moneyball gallery want everyone to use CDBCs instead of dollar notes, so nothing to see here.

Banks shouldn't really be concerned about mixers. That's more of the Fed's problem.

Absolutely, it's important to understand that Whirlwind goes above and beyond the standard, generic mixer, assuming we trust their word, which I do (but that's up to everyone here to make their own decision).


Thanks! What I think is so industry-changing about the blind certificate model is how these blind certificates are as good as cash, so they're transferrable, fungible, and they store value. No other mixer creates something like that. You could have secondary markets built where people could swap around their blind certificates to further enhance their privacy, which is something Theymos proposed back in 2018 when he briefly discussed blind certificates. It's exciting to be a witness to the beginning of all of this because for once, it's something bigger than just a single mixer. If successful, it creates an entirely new, layered system where others can build off the blind certificate model that Whirlwind creates.

Another thing that is so interesting IMO is how applying blind certificates to payments/money was first proposed 40 years ago. You have to wonder "how has this not been built before?" I think once in a lifetime, you might get lucky and stumble upon sort of "ancient wisdom" (for lack of a better term) that has been merely forgotten until now. My favorite entrepreneur example of this sort of thing is Gose: a type of beer that is becoming very popular only in recent years, yet it was invented in the 1200s. It went completely extinct before being rediscovered and reintroduced in the 1980s by a normal man who owned a pretty small pub in Germany. This was a man who searched through history to find an "ancient wisdom" sort of drink and reintroduce roughly the same formula in modern time. And boom, he became a multi-millionaire. That's what we're seeing happen with this blind certificate model - something that was first proposed very publicly 40 years ago, but then for one reason or another, no one stepped up to actually put it into practice.

If we could debate the reasons why, I'd argue that the corporate banking system has had a hand in suppressing this technology. It's utterly a direct threat to their existence. There's no other way to put it.

Great explanation and I'm glad you found the idea interesting enough to allocate time for this!

I want to mention that while we certainly could store logs about every transaction and we can't prove that we don't, in case you believe that we don't then I'll tell you how the current system works: we only store a Notes public key and balance in the database, when you generate a Note that is its corresponding private key. So in the database the Notes are not stored in chronological order, it's random. There is no link between a Note's public key and its corresponding deposit because we don't store anything about that. If you want to take it a step further you could withdraw a small percentage of the Note or combine 2 of them together so you alter the link between the exact deposit amount and Note public key balance in our database.

Whirlwind is built in a way that makes it possible to implement Blind Certificates, as an example our version would look like this:

There will be 5 Blind Certificates denominations, 10BTC | 1BTC | 0.1BTC | 0.01BTC | 0.001BTC

Each one will have it's own Anonymity set, which means that if there are 100 x 1BTC Blind Certificates issued, if you redeem one of them it could be any of the 100 issued certificates from Whirlwind's perspective. The only known information to anyone including us is that one of the 100 issued certificates was redeemed.

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.

For the moment I'll wait until people understand how Whirlwind works in it's current form and the service starts to see some more serious usage, and if this concept generates interest until then I'll implement it in a fairly short timeframe.

I hate the word "revolutionize," so I mean it when I say that blind certificates could actually revolutionize the mixer industry. They're going to be important to understand if you're in this space, so as a weekend project, I tried my best to create an easy-to-understand explanation graphic. Of course my guide simplifies the info a little, but it's meant to explain this stuff to beginners. There's more to add at a later date, but this should be a good start!

Crossposting this - very important update!


Update completed - everything is back online working in normal conditions | Please keep in mind that if you experience issues with the Clearnet version it's most likely because of our DDoS protection system, I am still tweaking it while we are under attack continuously. I'll sort it out without a doubt but it takes some time to do that, so until everything is set please use the Tor version if you experience any issues on Clearnet, that will most likely work without any issues at all.

I am working on displaying the anonymity set on the main page for each one of your selected outputs (number of deposits it could have originated from), so users know exactly how anonymous their bitcoin really is after using our service. I still feel like most users are not yet aware of how Whirlwind actually works and why it's the superior choice from a privacy perspective, so understanding what anonymity set means and seeing it grow each time you enter the website should make it easier for everyone to grasp the concept. It's just a matter of time until everyone gets used to the system and understands the undeniable advantages it offers.

I believe the decision to make the fees optional is wise for 2 reasons:
1. The only disadvantage of Whirlwind's mechanism is that at the start of the service the privacy set is weak due to the fact that there are few deposits. Making the fees optional should encourage more users to give the service a try, and by doing this they are helping all future users by increasing the anonymity set, making everything more secure.
2. A donation based business model was already proven to work before

The current plan is to leave the fees optional indefinitely, but if we won't generate enough revenue to be sustainable after the first 3 months we will have to implement a minimum fee again.

I'll answer any question or concern you might have!

Great question - the short answer is no, it wouldn't be possible for us to exit scam at that point.

Technical explanation

Whirlwind is based on a backend + validator (signer) model. The backend interacts with users by generating deposit addresses and processing withdrawals, while the validators (signers) validate all of the backend's actions. Whenever a withdraw transaction is being sent, the signatures must be retrieved from all validators which are able to verify the transaction is correct.

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 Note 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 Note’s private keys. Again, the proofs are deleted after their use.

Comments

As explained above the signers are doing way more than just signing transactions, that's why I previously said that the only way we could get exploited is if an attacker gains access to all signers at once without us noticing.
Everything I said above would be provable at that point since the whole codebase would be open-source (if not open-source then at the very least all signers would have complete access to frontend/backend/signers code)

Let's assume there are multiple trusted signers, and the system is nicely decentralized. Would it still be possible for you to pull an exit scam by creating notes that give you access to large funds? Wouldn't the signers just sign it? And if not: how would the signers know whether or not the note was created legitimately after a deposit?

Yes you have been open and transparent about Whirlwind and your posts demonstrate it. I think that is what people here appreciate when a team member or owner interacts with them in a transparent manner taking the time to provide explanations and answer questions no matter how difficult to explain or articulate.

As you stated, members only have your word to go by but the reviews and feedback of the website are positive and as your service progresses members will begin to make their own judgements in increasing numbers about the service and quality of service you provide. I tested the service and posted my review, it is a very simple service to use.

As for mixers seemingly launching on a daily basis, I have to say I cannot recall a time here when this many were being promoted via signature campaigns or a time when this many were using ANN threads frequently. It does provide competition for each other but if you have created something unique from your competitors from a technical perspective then they will have to play catch up.

Thank you for the feedback! Everything is working as usual now.

Update
-Clearnet is back online with improved DDoS protection and stability
-Added "You can withdraw as many times as you want from a single Note." on the Withdraw Note page
-Added "All deposits made within 24 hours will be considered valid, regardless if they are still pending or confirmed." on the Deposit page

Can confirm I've received the funds about 1 hour ago.
Thank you for the quick reply. Will use your service again for sure. 

Apologies for the delay, as I said in the ANN thread I'm currently working on some features so that's why withdrawals may be a bit delayed. You have nothing to worry about, all withdrawals will be processed as soon as the upgrade is done in the next hours.

Deposits are unaffected, you can still use the service. Thanks for understanding

Any known problems with the site? 300$ are stuck, it's been 1 hour since 2 confirmations and the site keeps saying "in 0 hours". The input address forwared the coins already to another address so...

edit: Wrong thread I appologize, but I guess you'll see my message anyway.

Both, but at this point I'm only relying on the camera. If I observe anything out of the ordinary then I'll just get another server and set it up in the backup location, but I highly doubt it will come to this.

Yes, everything besides the frontend Tor link and the clearnet reverse proxy server will be changed. The frontend server will be changed too, we will only keep the current Tor link so it's less confusing for users.

I don't want to cause any issues for anyone, let alone hurt the whole forum so I'll stop discussing this here, the only reason I did in the first place was because I thought users would prefer this over having to trust me, but I'll run the service this way for a while and whenever I'll get the chance to make everything trustless I will. If anyone has any ideas in this direction you're welcome to DM or email me and I'll gladly discuss further.

It's impossible to answer this question in a way that would have any sort of weight and I don't want to appear like I'm asking users to trust me just because I'm writing some messages here. My expertise/intentions will become clear from my actions as time goes on and that's the only way I can prove myself other than decentralizing the service.

I've been very transparent about every detail of Whirlwind, I've built everything from the ground up. I took the time to analyze every aspect of this business and I believe I came up with something unique in the Bitcoin space, something that our competitors don't even come close to from a technical standpoint.

It seems like a different mixer launches every day, but if you have a more in-depth look you will notice that each one of them has some major issues.
Use of jambler.io as their backend/very weak privacy set/ use of Cloudflare/ use of mixing codes which basically means keeping logs.

Even though I could have taken a lot of shortcuts in order to get the service out in 10x less time,  I chose to do everything the right way and made no compromises at all.

Or just as a hidden service.

After a quick navigation of the website anybody can see it is simple to use and the Fast or Notes options are extremely easy to select. It is a basic no-nonsense to the point website that is easy to navigate and that is a plus for end users and that should play a very important part as your business grows.

Having said that one of the fears people must have is about sending funds to mixers at the unfortunate time the mixer decides to exit scam (and to my knowledge it does happen from to time because people end up posting about getting scammed). Keeping that in mind this would be a very difficult question to answer but what can you say here and now to give confidence to forum members that a future exit scam is the furthest thing from your mind and what your very long term strategy is?

So since he said it's true, this means we can run this thing in the same fashion as a Tor exit node. Therefore, you should take exactly the same precautions as you would when you run a Tor exit node - use ISPs that are Tor-friendly, make sure you have lawyers and a good legal team, use hosting providers and datacenters that are OK with Tor traffic, and so on.

Just like how some countries try to charge Tor node operators with shady darknet actions that its users do, so these countries will try to charge those who host decentralized mixer frontends and backends, so everyone make sure you guys are not hosting them in countries hostile to mixers, such as the USA.

---

Buuuut....

I suggest not relying only on Bitcointalk community members. Try to involve the greater bitcoin community in this, for example, on reddit, twitter, and the various Bitcoin conventions. The last thing the forum administration wants is the resemblance that it's openly facilitating mixer activity.

Did you mean physical access? Or does this mean there's a camera pointed at the server?

When you move a server to a different provider, do you also create a new multisig (so the privkey/seed from the retired server is no longer valid)?

I am taking opsec very seriously so even though the answers to these questions might seem obvious to me I'll say it out loud for the record

1.Where do you run this? Your home, or you use some provider?
I can't disclose the exact setup that we're running but there are >5 servers, all but one are from different providers. The last one is one of the signers and it's a physical server in a secure location that we have visual access to 24/7, so it can't be tampered with.

2.How much access does the site provider have?
The other providers besides the one where we run the clearnet server (which is public) should not even be aware that we are using them. Regardless even if they knew there is nothing they can do since no single server holds all keys. So noone besides me has access to anything unless they break into all servers at once without me noticing, including the physical server. I will also change all servers and rotate providers once in a while just to be sure.

3.What rights do they have? How much information do they have about you?
They have 0 information about me, same as everyone else. Worst they could do is shut down a server, and that really doesen't do anything since we can replace it in 10 minutes and have everything up and running again like it never happened.

4.Are you doing everything via anonymous networks?
Yes

If as an operator you can't even protect yourself, then there is no way you can protect your users and this is what this service is all about. I'm also willing to put my money where my mouth is, so if anyone can manage to find the IP of any of the signers (no time limit and no requirement to hack it, only finding the IP is enough) I will offer a considerable bounty.

Correct

Where do you run this? Your home, or you use some provider? How much access does the site provider have? What rights do they have? How much information do they have about you? Are you doing everything via anonymous networks?

Alright, so everyone can setup a front end (whose source code, as I've read, you'll publish at some point) and connect to some backend that is hosted by the trusted members?

The goal of this thread is to have a discussion regarding this issue. If at any point we come to the conclusion that it's riskier to run Whirlwind as a community project then I will simply continue to do it myself. I don't understand your point about Bitcointalk as a forum getting dragged into this since it has nothing to do with Whirlwind

Correct

-Can you be more specific about this question? What do you mean by what's our setup
-No idea at the moment, we would all have to agree on a "procedure"
-If we manage to implement the multi-sig with multiple trusted members, then even if I go missing 1 hour after that it does not matter. The remaining members can run the service as if it never happened, so the service can continue with or without me

1.I'm still trying to figure out if there is a way to do this, if I have any ideas I will write about them before I implement anything. Here is an idea I had, but we need the Blind Certificates in order for it to work. It would be possible to prove your funds are not coming from specific addresses without revealing which one your deposit actually is.
2.Your first point is my biggest concern and something for which I'm not convinced that a solution even exists. We will come to a conclusion together after more discussions, whatever that may be

I'd suggest when selecting trusted members of the community to act as additional signers, those members reside in regions that:

a) aren't openly hostile to Bitcoin,
b) aren't aligned with US/EU interests and
c) aren't all in the same place  

That alone will make it more resilient to takedown.  It's not just about trusting the individuals, it's about what their respective governments might do.

Thank you for your responses, hope you don't mind if I ask you some deep questions:
1. Do you do something or plan to do something to prevent abuse of your service? I mean to minimize it cause nothing is totally preventable. There are people who care about their privacy and there are people who want to do illegal things, do you have a plan to make your service unlikeable for the people who do illegal things? To get rid of them. Do you think are there any measurements that you can take while keep your service functional for people who care about their privacy?
I know this question can sound strange but it's still an interesting one. More likely I mean, you may be able to get list of addresses that are known to be found in illegal activities and you may include these addresses in your blacklist to not be able to use your service.

2. I think, you understand that doesn't matter how trusted someone is on this forum, there is a chance that any signer can actually be a spy. By the way, what do you think, what's the number of signers that can make you feel safe and get rid of cooperation to steal money? Definitely 3/3 or 7/7 won't work, you need something like 2/3 or 5/7 at least. I think this is a huge challenge.

So, as far as I've understood (without giving much emphasis on the details), whirlwind is a mixer that knows the input, but doesn't know the output (i.e., I send 0.01 BTC, but they don't know which 0.01 BTC output I will spend). Is that correct?

I have some questions:

• First of all, what's your setup, as NotATether said? ChipMixer was proved to have poor setup, and even if your service isn't prone to failure due to centralization, your absence would lead to the corruption of the service (at least now that it's brand new).
• How do you plan to select anonymous trustworthy members?
• Who grants us that the authorities will not try to shut down the federation? AFAIK, from what I've read, the trustworthy members will only protect the users in case whirlwind is shutdown, and it protects their privacy using blinded certificates, but it doesn't grant that the service will continue being online after whirlwind (the user) disappears.

Very interesting implementation, I hope it goes well.

That's a good point, and one I did not consider. For an external observer using blockchain analysis, then a fast mix appears identical to someone using notes. They can see the deposit being made, but since they don't know if the user is using fast or notes, they are unable to reach any conclusions about the time frame of when the withdrawal will be made or how much will be withdrawn. Both fast and notes users benefit from being in the larger anonymity set provided by the other type of user, and having the different process help to obfuscate what is happening.

The way you are trying to involve individuals from the community  and keep talking about community in the main operations with the multi signature addresses and things, I wonder what the three letter agency will feel about it when they will target your project. If you become bigger then today or tomorrow they will come after you and the people with you working in the managerial level holding the keys.

If they get the false sense of understanding that the mixer is running by bitcointalk community then immediately they will come after bitcointalk and destroy it.

If we didn't have the Notes then I agree, Fast mode would have the same disadvantages as any other mixer. But since outputs from Notes and Fast look exactly the same there is no way for any outside observer to know which mode you used. So Fast mode is as secure as the Notes from a privacy set standpoint. I would still recommend using Notes regardless because they offer the end-user full control over the process.

Yes you understood correctly, I have total control. I explained in previous messages that the multi-sig's purpose is to protect against external attackers, not against myself.

It sure is a valid question and I understand the concern, I'll share my view on this issue. As I said since before I even launched the service, I am hoping for the best while preparing for the worst.

I also want to emphasize that I have not commited any crimes while creating Whirlwind, for example identity theft.

Even though I don't believe I have anything to worry about, I'd still prefer to add more signers to the multi-sig so I don't have full control anymore. This would make it safer for everyone, I really do not like the fact that users have to trust me. For now this is the only option though, and I will not take any steps in this direction unless I am 100% sure it's done in a safe way. The community would also have to agree with the plan before I set it in motion

Considering the recent situation with Chipmixer, I think this is definitely a valid question.

I'll ask again: If you have access to the backup where the seeds of all signers are stored, finally total control comes down to you. Did I understand correctly? If I didn't, please enlighten me cause seems I didn't get it then.

That's kinda strange question, if he says that he does in order to save himself from the claws of government, would it make sense in terms of security?
By the way, another question that I have, is, why does someone want to create a mixer when this happened to chipmixer? Or why does any of them want to continue to operate? When you enter the ocean, you enter the food chain.

If I would not be mistaken Chipmixer was the biggest Mixing company in the community, until it demised and presently whirlwindmoney has taken over that Chipmixer's position in the community. Well you can't give an inductive reasoning on whirlwindmoney and Chipmixer, I am not saying that you should trust them but where (the root of launching) the mixer is entirely different from Chipmixer therefore they have different operations and managers.


Really this is my first time of hearing this blind certificate, if the transactions are anonymity to the public then they can make the whole system anonymous to every users for fair transactions. In any system trust is the most important thing to keep. I will want whirlwindmoney to be transparent in all their dealings with their customers and both in the community and in the site.

Rather than asking a few questions about user privacy, I will ask another kind of question.

What preventative measures have you taken to protect yourself from arrest and federal government seizure of website assets (i.e: how do you plan to avoid Cipmixer's fate)?

I remember reading that report thoroughly at the time it was shared. I agree that the structure that ChipMixer used, and the similar structure that Whirlwind is now using, meant that they can't be broken in the same way as traditional mixers exactly for the reasons whirlwindmoney has given above. By allowing users to deposit different amounts to different addresses at different times, to combine and split these amounts freely, to do so over any period of time desired, and then to withdraw any amount of coins from their vouchers/notes, it becomes impossible to track inputs and outputs in the same way this report does. Of course users can still make mistakes such as combining mixed and unmixed UTXOs, but the service itself is not at fault in such cases.

My feeling would be that the fast option would potentially be breakable in the same way that every other mixer is, but notes would not be breakable in the same way that ChipMixer wasn't.

And of course if things get as far as blinded certificates, then it becomes provably impossible to link deposits and withdrawals via blockchain analysis, since certificate issuing, trading, spending, and redeeming, all happens off chain and Whirlpool are blinded to the individual certificates.

I went through his report and altough I'm sure we already fixed the issues outlined by him, I will still try to get him to do a paid review for your confirmation.

Coinmixer.se (the service used as example in the report) works like most mixers on the market today, and they all have the same big issues in common:
1.Maximum delay time is limited
2.Maximum amount of output addresses is limited
3.No option to have higher outputs than inputs
4.Use of mixing codes

These issues make it possible for anyone to perform blockchain analysis with relative ease. The privacy set (number of deposits your output transaction could have originated from) which is the most important figure in my opinion, is reduced to only the transactions that were performed during the time limits imposed by the "maximum delay". And since you also know the maximum number of output transactions each deposit has, it's not that difficult to deanonymize it.

We solve all these issues by introducing the Note mechanism. Let's see how the above issues apply to Whirlwind:
1.Maximum delay time is unlimited
2.Maximum amount of output addresses is unlimited
3.Outputs can be higher than inputs (combine Notes)
4.We don't use mixing codes

Since the user has the option to deposit and withdraw whenever he likes and we don't impose a limit, blockchain analysis becomes useless. In the case of coinmixer.se it's written in the report that they had about ~1000 deposit transactions a week. If we assume we'll have the same, then the privacy set of Whirlwind will grow by 1000 every week.

After 10 weeks every output transaction could originate from any of the 10,000 deposits into Whirlwind, and this figure will only grow as time goes on. With other mixers it doesen't matter how many deposits they have in total, the privacy set doesen't increase.

The use of mixing codes by a service confirms that the privacy set is very weak and introduces other risks since it can link your transactions. If a mixer does what it's supposed to do, it shouldn't matter if you get 'your own coins' back because anyone that ever used the service could have withdrawn those coins.

 Since you are open to hearing opinions, I hope you will visit this link ----> Breaking Mixing Services



Contact him, and if he accepts to give a paid review, I think that this will contribute a lot to gaining trust in your mixer service (at least for some here)

How is it misinformation if it is implemented?

I suggest you read some of the earlier messages here to understand the purpose of the multi-sig

I'm here for any questions if something is unclear

It sounds complicated. If I have all cosigners seed then having a multi-sig is just giving a false security. It's again down to trusting one person. On the other hand it's risky for other two cosigners as they might be blamed for any mishandling. Their reputation will be at risk.

I am coming from your response on the Ann. As I said, right now telling about multi-sig feature is a misinformation until it's implemented.

I mean, if something happens to those one or two users, you can use your backup that you hold for all 3 signers, right? This means, finally the control system is still centralized and in reality, we don't get pure 3 signers service because after all, you are capable to use those keys anytime you wish and finally it comes to whether we trust personally you or not, right? Or did I misunderstood something here?
Btw I'm not saying whether you are trustworthy or not, I'm neutral here.

Thinking very long term here because I know in the near term challenge is just to find three separate trusted members, but it would be really neat to someday set up a system with separate groups of 3 signers and allow the user to choose which group to engage with. This would reduce the trust to place in the service for picking the three members and give us more autonomy on choosing exactly who we can trust. It would also set up a very neat system where people could essentially form their own mixer on your service. Three people join together, they each control separate certificates to form a mixing/trust cluster, and they get a portion of the mixing fee (as does Whirlwind). These people would then be super promoters of Whirlwind because they'd be promoting their own mini mixer within the Whirlwind system. They might even fund their own signature campaigns and other sort of referral programs. I worked with developing a referral program years ago and it was the single best thing the company did for acquiring new users. The company paid the users well for their referrals, and it practically 10x-ed growth.

Understandable, but that's the advantage of blind certificates. You won't need to trust that we don't keep logs, it would be impossible to log anything even if we tried. This will be provable beyond any doubt at any point since it's code, not just our words.

Great idea, we will do that once we get some traction with the current version

Currently I am all 3 "users", the point is that if you have a 2 server setup for the whole infrastructure, like in a case where we all know for a fact this is the truth, then the entire service including funds are at risk of being hacked/seized//the list goes on. I can't disclose the exact setup that we are running for obvious reasons but there are >5 servers, and all but the clearnet frontend one are not exposed. While risk still exists with our setup too, it's mitigated to a minimum. I am not trying to pretend that I don't have access to funds or anything like that, I said multiple times that unless there will be more signers besides me in the multi-sig, then users will have to trust me and it's just how it is. But at least if you assume I am honest, then you don't have to worry about much else. I don't believe you have this luxury with many other services.

We will phase out the Fast mode only if we migrate to a setup with multiple signers. (I explained before it's because all signers could keep logs for Fast mode and we can't take that risk) As for trust I was planning to run a review campaign and lock a few BTC in escrow, Hhampuz is looking to find a 3rd party to hold these funds. Not much else to do besides this other than running the service reliably, time will tell

I have no idea right now to be perfectly honest, but I hope that after some more time and discussions about this topic here we will come up with a reliable plan that we can execute.

After gaining trust, will the fast situation be deleted and only use notes? and what is your plans to get trust? only high-payment the signature campaign?

blinded bearer certificates is a new concept for me < will read about it and update.

What are the criteria for selecting *reputable users,* and will the contract be for decentralization and how will you deal with legal frameworks and how to make payments? Can anyone be a reliable member if he fulfills certain conditions, or is the list central?

3/3 is a case where three signature is required to sign a transaction. So, if one user isn't online or able to sign, then you are going to migrate to a new multi-sig with new signers and servers because you have the backup, you said that.
So, if you hold the backup for all 3 signers and you can always change the fate of situation, doesn't that mean that all you are doing by multi-sig is that you just put transparent curtains? I mean, what's the point of 3/3 multisig if you can always do whatever you want?

The blind certificates are certainly causing a lot of confusion since it's a relatively novel idea put into practice. Perhaps you all could create a graphic that would explain it clearly and in an illustrative manner? That would help a lot vs. reading paragraphs of text about it, and then it'd be easy to repost to answer this question moving forward.

Everyone has the right to rush to fill the big gap left by Chipmixer, but on the other hand, it has become very difficult for any mixer to gain the trust of the community because of this incident, which showed that the mixer was keeping user data.

I, as many here, do not know how blind certificates work completely, but what I do know is that it has become very difficult to trust any third-party services. I personally do not trust that any third-party service fully maintains privacy.

You need to decentralize the service almost completely to gain trust.

That makes sense. My assumption was the multisig is meant to protect against losing access, but it's against someone else gaining access. Unless someone skips the servers ans gains access to your backups directly.

Correct, the multi-sig's purpose in the current setup is not to protect against us acting maliciously, but against external actors.

Correct again, in this form users funds will be protected against external actors and us acting maliciously. I believe it could work well enough even with less than 9 other people, but the flow remains the same.

Nothing to correct. It was clear to us from the beginning that requiring trust from the end user would be the biggest issue, but until we find reputable users to add to the multi-sig there really is no way around it. We will try our best to migrate to the trustless version as soon as possible, it all depends on how fast we'll be able to find the right users for the multi-sig. Until then as you said funds are safe from external actors but we could scam anytime if we wanted.

I think maybe it would be worth clarifying the difference between the current set up and your future plans.

At the moment, with whirlwindmoney being the sole operator of the site, then they are in control of all 3 keys in a 3-of-3 multi-sig. This provides additional security against a single server being seized or infiltrated, but it still requires complete trust from the end user that whirlwindmoney won't scam them, as it would in a normal single-sig set up.

In the future with blinded bearer certificates and the involvement of other third parties, then presumably the best option in that scenario would be to migrate to a different multi-sig. Let's say they recruit nine other people to be signers for the blinded certificates. Maybe something like a 7-of-10 multi-sig would be the best in that case, which provides a good mix of security against some of the signers being dishonest as well as redundancy against some of the signers being taken offline, seized, infiltrated, etc.

CMIIW.

We are the only ones who hold the backup (offline) for all 3 signers and the only ones who have access to the servers. One of the servers belongs to us, the other 2 are rented. The difference that we care about between the physical and rented ones is that for the physical one we are 100% sure it is not tampered with in any way. (can't disclose how for security reasons so you'll have to take my word on this) And if something were to ever happen we would find out with enough time in advance that we could just migrate to a new setup instantly.

It is a 3/3 multisig setup, 1/3 would defeat the purpose. The reasoning behind it is that if one signer will ever be seized or it stops for any reason there is no damage that can be done. Like I said the only real bad scenario is if all of them get hacked at the same time without us knowing. If we ever feel that something is not right with any one of the signers we can migrate to a new multi-sig with new signers and new servers in under an hour, in fact we were planning to do this once in a while by default just in case. Most if not all other services store their keys on a single server that may be infiltrated from day 1, there is just no way to be sure but we don't want to take any chances ourselves.

Where's the redundancy in this setup? Who holds for instance the backup to the keys used on the physical server? And doesn't the fact that someone has access increase the risk of losing funds?

If just 1 out of 3 is unavailable, the multisig transaction can't be signed anymore. Unless you mean a 1/3 multisig setup, but that creates other risks.

First of all the frontend will be open source very soon, so if the service gets seized/shutdown anyone can use that to withdraw assuming the multi-sig signers are still online. The only really bad scenario is if all 3 signer servers get seized at the same time. Chances of that happening are very slim since we would know about at least 1 of them with enough time in advance and no single server out of the whole infrastructure is exposed so even finding one of them would be quite challenging, let alone the signers.

If there was a 5/10 multi-sig for example, if only 5 of those signers are still running then anyone can use the open source frontend to withdraw. You don't have to contact anyone, theoretically even the signers don't have to know who the other ones are. As long as the required amount of multi-sig signers are still online then the service is online regardless if we the creators are around anymore or not.

EDIT: The only disadvantage to keep in mind for when there'll be more signers is that the "Fast" mode will be deprecated and we need Blind Certificates because all signers will know what happens on the platform and could keep logs so we can't take that risk.

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?

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.

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.

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?

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!

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.

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.


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

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?

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.

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

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.

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.

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

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://bitcointalksearch.org/topic/m.61883998), 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.

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