Topic: Ultimate Bitcoin Privacy - Discussion (Read 1648 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: