I wish there was a chart that tracked the market cap of the not-yet-mined BTC over time.
Just published this new piece today.
How To Use Bitcoin Anonymously
https://www.whatisbitcoin.com/privacy/how-to-use-bitcoin-anonymously
...or you can just use Wasabi Wallet which has privacy by default with no coin control necessary: https://www.youtube.com/watch?v=UbOAbXjzBJg
WabiSabi coinjoins were designed with this blockspace constraint in mind. You can make a payment directly to its destination in a coinjoin transaction: https://github.com/zkSNACKs/WalletWasabi/discussions/10570
You can't do the same in Wasabi without being detected because the attack target would have to register their non private input first (out of 150) and the malicious coordinator would have to deny registration from non sybil participants, including the attack target's next input. This allows an attacker coordinator performing a sybil attack to be detected by the target.
A second apprpach is a malicious coordinator that purposely never alllows a round to succeed can passively gather input registrations from multiple unsuccessful rounds in order to try to slowly try to cluster them together. This is somewhat detectable I assume since rounds never actually succeed?
They wouldn't be able to afford to inventory those delivered goods for extra unnecessary days just for the sole purpose of punishing you for not upgrading.
I'm not a programmer, so my goal is to write documentation that never expires.
#[0]
I tried this approach, but the opinion of the Samourai developers is that privacy MUST be opt-in by default, not opt-out by default. They said any PR to make privacy features enabled by default would not be merged: https://code.samourai.io/wallet/samourai-wallet-android/-/issues/458
A false notification (1) bubble that won't go away is the absolute worst bug.
#[0] recommend
Don't you see how Wasabi 1.0 has the chance to create less toxic change than Whirlpool due to coinjoining the change instead of self spending it in tx0?
This is completely backwards. Whirlpool doesn't fix the problem of toxic change, it makes the problem even worse since it creates the toxic change from a self spend transaction (tx0) instead of creating it from a coinjoin where it has the potential to gain unintended privacy by chance:

First, you have to pay a tx0 to enter to whirlpool. You are gonna mix with a lot of users getting no clue because high anon set. You can check here:
https://bitcoinmagazine.com/technical/how-bitcoin-anonymity-sets-work
In wasabi you can have 20 open wallets mixing with less than 1 million sats in each one without pay coordinator fees. A Sybil attack can be possible in Wasabi.
You blend in with far fewer potential input and output addresses from a Whirlpool coinjoin than even a minimum sized Wasabi coinjoin. Take this transaction for example: https://mempool.space/tx/0d832b9db303d4f5934c52a061af9c3c378f0243f8cbb8783d14a1d52e8cbdbb
-138/145 unique input addresses were from outputs getting remixed from 68 previous coinjoin rounds. An observer of an output in this coinjoin would have a choice of 13,615 inputs within two hops.
-150/166 outputs became inputs for 60 future coinjoin rounds. An observer of an input in this coinjoin would have a choice of 14,528 outputs within two hops.
By comparison, observers of a Whirlpool output would have a choice between 17 inputs within two hops. Observers of a Whirlpool input would have a choice between 25 outputs within 2 hops (in the best case scenario).
Tradeoffs to the elimination of non-private change
https://github.com/zkSNACKs/WalletWasabi/issues/10462
I saw this problem since the first version of wasabi 2.0.
A coinjoin must be deterministic.
If it's fully deterministic using "greedy" amount decomposition every time, then an attacker could use that determinism as well to anticipate which values you claim as outputs (but not their specific addresses), which is why there's added client randomness. There's definitely still room for optimization though.
You can make a coinjoin much more private than that. Wasabi improves the "all inputs and outputs are identical" structure of Whirlpool to allow private input consolidation within coinjoins, arbitrary amount payments, and elimination of non private change: https://mempool.space/tx/87d32a8756a5e3a3a366614994db1d6751205f81ad962e5382314f0fa613865f
The problem is that this allows Sybil attackers to mix "unlimitedly" without paying extra. Wasabi solves this problem by making attackers pay for their own mining fees.
Progress on silent payments:
I need my nostr client to replace the "Post" button with a "Are you sure you want to post that?" button. A new era of information benefits from specific instructions.
The claims made in this thread include some that are false and presented with no proof or arguments, alongside some useful descriptions of potential attacks and edge cases that can cause less than perfect privacy. Here’s a line-by-line rebuttal:
_____________________
"1) Wasabi's funding and willing usage of chain surveillance companies puts your on-chain data at risk when you use them. This usage of CA could ... lead to harming your privacy directly"
_____________________
This is simply false, Wasabi wallet never puts your on-chain data at risk:
-Your IP address is never linked to your addresses because Tor is used by default
-Your addresses are never linked to each other because client side block filters are used by default.
Any "usage of chain surveillance companies" by coinjoin coordinators would mean a coordinator is BUYING their data, not SELLING data to them since Wasabi is designed not to reveal any user data.
By comparison, Samourai wallet DOES put your on-chain data at risk:
-By default, all of your addresses are linked together (even the private addresses of your equal output coinjoins) and sent to Samourai's server, which becomes a honeypot of data.
-By default, Tor is not enabled.
_____________________
"1a) Usage of CA could also easily be turned into a honeypot where "bad inputs" automatically get sent to mix with only Sybil inputs, providing 0 privacy but not showing that in your client."
_____________________
A malicious coordinator can attempt to Sybil attack a target input no matter what coinjoin protocol is used. WabiSabi is especially resilient to Sybil attacks, while Whirlpool is especially susceptible to them,
It's possible to perform this attack with some sort of reliability on a 5 input coinjoin like Whirlpool, especially if the coordinator knows the xpub of other users in the round, turning those users into unwilling attackers as well. The cost of a Sybil attack in Whirlpool is reduced to a one time payment because an attacker’s mining fees for remixes are paid by the victims of the attack.
In WabiSabi, the potential for this attack is also mitigated by the 150+ input size of the round, requiring an enormous amount of luck and liquid capital to even attempt. The attacker would need to get lucky for the target to register their non private input first in order for the malicious coordinator to know to fill the round with 149 dummy inputs and exclude registration from any unknown inputs. In order for this attack to ever succeed, the malicious coordinator would have to be enormously well capitalized and liquid (coins that are unconfirmed cannot be registered) to control that many UTXOs and pay their mining fees.
With WabiSabi, the target of the attack would be also able to detect the malicious coordinator when they try to register their second input (which would be rejected). With Whirlpool, the target would not be able to detect a malicious coordinator this way since they are limited to registering a single input in a round.
Wasabi 1.0 and 2.0 clients are also able to detect/prevent this attack in an additional way since a unique "Satoshi" Tor identity is used by the client to get the round status, which is not connected to "Alice" Tor identities used for input registration.
_____________________
"2) WabiSabi as a protocol is only a tool for aggregating inputs where each input/output is blinded from the coordinator, and is not in any way a Coinjoin protocol - it is merely the input aggregation portion of one.
As such, the specifics of the WW2 protocol are unclear."
_____________________
It is simply false that WabiSabi is not a coinjoin protocol.
Aggregating inputs privately is a cryptographic advancement made possible by the WabiSabi protocol, but aggregation is not required, you can still register with a single input. By enabling private consolidation, WabiSabi's properties grant the side effect of making outputs that are larger than a smaller single input a potential link since the larger output could have been created from a consolidation of inputs below the output value, not just created by inputs bigger than the output value.
Since input selection and output selection is done by the client instead of the coordinator, there is a specific deterministic process (with added randomness) to get clients to to choose outputs of the same amount by using a frequency table generated from a template of inputs registered to the round and their values: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020202.html
_____________________
"3) There is currently *zero* way to verify the privacy provided by a given mixing round in WW2, and even Wasabi themselves don't seem to understand how their "anon score" metric works.
If you can't verify the privacy you get, you *should not trust it*."
_____________________
The privacy metric is verifiable, both implementations consider outputs private by using the same method. WabiSabi participants and Whirlpool participants use the number of other outputs in the coinjoin that share an equal value to determine how private it is. The only way your anonymity score will increase in Wasabi's client is if your output has a value matching others in the round.
Although measuring and quantifying the minimum privacy gain is easy, the dispute among Wasabi contributors themselves is how to quantify the additional privacy gains that are created by the composition and decomposition possibilities of WabiSabi, which is a novel property of the protocol. Since there is no consensus on finding a way to measure the exact privacy gained from these combinations, they are ignored entirely, and do not adjust your score to be any higher. This means Wasabi clients will always underestimate how private your output is and will never overestimate how private your output is.
_____________________
"4) "Lonely whales" (i.e. those with larger amounts of Bitcoin) can often gain *zero* privacy in mixes and have 100% deterministic links between their inputs and outputs.
Have seen as little as 6 BTC gaining no privacy from mixing rounds."
_____________________
6 BTC significantly surpasses the potential values that can be made private in a Whirlpool coinjoin. The maximum value of Whirlpool inputs is only 0.5 BTC, which is far lower than the 6 BTC whale you observed creating change.
If a whale output (or any output) gains zero privacy from a round, then the wallet will not identify that output as private. Any non private output can simply be remixed again without paying additional coordinator fees.
_____________________
"5) Due to the client + coordinator not learning amounts chosen by participants in rounds, you can never be sure that a mixing round provides you with any privacy, as it's always possible no one selects the same amounts as you, providing an anon set of 1 (your input/output)."
_____________________
This unlikely (but possible) result will cause the output to register to be remixed.
Even though this standalone output still gains real privacy in the real world (if it is not the whale), the client is not able to measure this privacy gain, so it just gives it the minimum anon score of 1.
_____________________
"6) The usage "big TX = good privacy" in Wasabi marketing is BS, as the only thing that matters for privacy in a transaction is the potential outputs to match your inputs.
That is really only the outputs that share a denomination with your output, not all outputs in a TX."
_____________________
An output (if it is not the whale) cannot be matched to an input even if there are no other outputs sharing the denomination.
If you think this claim is "marketing BS", then go ahead prove it by identifying the input that created this output: https://mempool.space/address/bc1qrmmypw3g2ds4aqgh3nqc59qhdp9qk779x2zlru
_____________________
"7) If the creators of this purported privacy tool don't know how to measure the privacy provided by their protocol, it should raise red flags for you.
Not knowing how your own protocol actually provides privacy opens up so many potential implementation flaws."
_____________________
The minimum privacy gained can be measured, only the maximum privacy gained cannot be measured. There is no downside to gaining more privacy in the real world than your client is able to detect, quantify, and display.
_____________________
"8) There is a *long* history of tracing of Wasabi's previous implementation due to flaws in protocol and flaws in implementation,
so we should be incredibly wary of trusting privacy claims until 100% proven over time."
_____________________
[Citation needed] You provided *zero* examples of this "long history of flaws" you claim exist.
_____________________
"9) There remain *zero* post-mix spending tools in Wasabi, something that is absolutely vital to actually gaining privacy from Coinjoins when spending Bitcoin. Even if the protocol was perfect this would lead to many privacy issues and ‘foot guns’."
_____________________
This is simply false. You can use Wasabi for post-mix Payjoin transactions.
But WabiSabi is so flexible that you shouldn't settle for "post-mix" tools at all: Since there is no fixed standard denomination set by the coordinator, you can send payments DIRECTLY to the receiver INSIDE a 150-400 input coinjoin transaction so that the receiver never even learns the input addresses or the change address of the sender.
It gets even more incredible. The key verified anonymous credentials (ecash tokens) issued by the coordinator can be used as a completely private second layer for Bitcoin. This allows Bitcoin payments to be made so privately that the sender does not even learn the address of the receiver: https://twitter.com/MrKukks/status/1619294492854747138
_____________________
"This thread comes after spending many hours digging into the WabiSabi protocol, their documentation, and speaking with them at length.
I have no personal beef with Wasabi but try to remain open to learning from new approaches and wanted to give WabiSabi a fair shake."
_____________________
I hope that you will use the information you learned from this response thread to issue corrections to the original.
_____________________
"As a note to Thibaud and others I spoke with on the Space last week, that was not merely recon or similar, I genuinely wanted to learn and thought that would be a good place.
Unfortunately I didn't really get much mic time or many questions answered and it felt like marketing."
_____________________
In hindsight, it would have been great if there were time budgeted for an audience Q&A. Perhaps you can gather questions from your audience and strongest Samourai warriors to ask a WabiSabi expert about on your podcast.
So you don't actually have any rebuttal to Shinobi's corrections of the false claims you made in this thread? Calling his debunking "vague nonsense" and an "angry rant" doesn't mean anything because he has the facts correct and you have the facts incorrect.
