Will Taproot eventually make Centralized Mixers obsolete?

[100bitcoin]

Because...

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

-snip-

* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.

-snip-

[Charles-Tim]

That is one of the advantages of taproot, for example in P2SH and P2WSH multisig wallet, it is quite clear to any blockchain observer that the transaction is multisig, but if pay-to-taproot is used, it will make multisig transactions to be indistinguishable from single public key transactions, blockchain observers will not be able to know if the transaction is multisig or not.

Taproot will help in atomic swap with the help of schnorr adaptor signature.

Know that there is a decentralized means of mixing which is coinjoin like while using Wasabi wallet to coinjoin, but yet there are still mixers.

What might make CoinJoin more possible with taproot is cross-input aggregation, but this is not included in BIP340-BIP342. With cross-input aggregation, it will be possible for many inputs to be combined together with just a single signature which can be used to spend all the inputs.

Mixers will still function appropriately and not yet getting obsolete.

[o_e_l_e_o]

I think you are misinterpreting what is meant by "all outputs and cooperative spends indistinguishable from each other". Taproot will not make every output indistinguishable from an identification point of view. Nor will it make it any more difficult to link a specific output to a specific transaction or input.

What taproot will do is to make every taproot output indistinguishable from a locking script point of view. It will be impossible tell if a taproot output, once spent, was spent using a single signature, a multi-signature, a Lightning channel close transaction, some unique smart contract, a coin swap, etc. In short, taproot obfuscates the spending conditions of the output, but it doesn't obfuscate the output itself.

Although this is an improvement for your privacy, as you can hide exactly how you are spending your inputs, it does very little to assist with the type of privacy improvements which can be gained from using a mixing service.

[DaveF]

...as you can hide exactly how you are spending your inputs...

I don't know if hide is the best word or if obfuscate is a better choice.
Hiding seems to imply that they can't be seen. They can be seen, others just don't know what is happening to a certain extent.

-Dave

[cabron]

All I know is that this taproot is Segwit version 1 but they are saying that this is the way to go to be more private and decentralized, unlike the LN. But isn't Segwit part of LN?

Can you say you don't need Mixers anymore if you want to make transactions untraceable?

[o_e_l_e_o]

...as you can hide exactly how you are spending your inputs...

I don't know if hide is the best word or if obfuscate is a better choice.
Hiding seems to imply that they can't be seen. They can be seen, others just don't know what is happening to a certain extent.

-Dave

Sure, I take your point, but I'm not sure what I said was incorrect. You aren't hiding your inputs and you aren't hiding the fact you are spending, but you are hiding how you are spending them (i.e. how you signed the transaction - single sig, multi-sig, etc.)

but they are saying that this is the way to go to be more private and decentralized, unlike the LN. But isn't Segwit part of LN?

Private, sure, but taproot doesn't make bitcoin any more or less decentralized. Segwit was initially proposed to solve transaction malleability, which is needed for Lightning to function effectively, but I wouldn't say that Segwit is "part" of Lightning.

[BlackHatCoiner]

Charles-Tim and o_e_l_e_o summarized how will taproot help and why we won't stop using mixers. I just want to comment something.

It seems that, from this point of view, taproot is more like a practical improvement for making large transactions' fees less rather than a privacy improvement while it's promoted the opposite. The media have spread that the main purpose of this soft fork is to improve the script capabilities and mostly privacy, but they don't consider those secondary. The fact that the system becomes more efficient is the significant fact, in my opinion.

Since there're far better solutions when it comes to privacy (Ring signatures), I find it excessive to say that's a serious improvement. Its main purpose is efficiency and due to efficiency there's a slight improvement in privacy.

[o_e_l_e_o]

The media have spread that the main purpose of this soft fork is to improve the script capabilities and mostly privacy, but they don't consider those secondary.

That's what the text of BIP 341 states:

This proposal aims to improve privacy, efficiency, and flexibility of Bitcoin's scripting capabilities without adding new security assumptions.

Taproot only makes large transactions' fees lower when considering transactions with multiple inputs, precisely because of the above improvements. The impact on consolidation transactions using P2TR inputs being cheaper than when compared to using P2WPKH inputs is secondary to the above changes. Transactions with multiple P2TR outputs will actually be larger than equivalent transaction with multiple P2WPKH transactions.

I think this is similar to when people say that the main point of segwit was to reduce fees. It wasn't, as again can be seen in the relevant BIP (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Motivation). The main purpose was to fix transaction malleability to make Lightning possible. The reduction in transaction fees was a secondary consideration.

[garlonicon]

Since there're far better solutions when it comes to privacy (Ring signatures)

Ring signatures can be implemented to some extent with taproot. For example: a typical ring signature is something like that: "rct=xG+aH(G)". You need "rct" as your "Ring Confidential Transaction". You have "x" as your private key, so "xG" is your public key. You can use "H(G)" as some point chosen as a public key with x-value equal to the hash of something, so everyone can see it is just "burning key" with unknown private key. Then, a-value allows you to hide everything, so that nobody knows your public key "xG" just by knowing "rct".

Then you can compare this "rct" with taproot: you have some public key, encoded directly in your taproot address. You can spend by key or spend by script. If you spend by key, you need a signature matching your "rct", so if "H(G)" is provably unspendable, you cannot spend by key. So you spend by script, you reveal your key, where everything is accumulated, you publish your "aH(G)". Then, that value can be subtracted and to spend your funds, you have to sign it with "xG".

In this case above, you have one x-value, your own private key. But imagine there are more participants. You have Alice with rctA=xG+aH(G) and Bob with rctB=yG+bH(G). Then you can create rctA+rctB=(x+y)G+(a+b)H(G) and pretend it is your rctC=zG+cH(G), where z=x+y and c=a+b. Even if you spend by script, nobody can tell if there is one participant or maybe 40 people mixing their coins for months by doing off-chain transactions for many months.

Also note that you can hide more things in this way, not only your private key. You can hide everything you want to sum, for example coin amounts. If you spend by script, you can prove that nobody can mess up with H(G) and spend it directly without other participants. I can imagine a sidechain peg-in by that kind of output, where you have one huge N-of-N multisig and by looking on-chain you can only check how many coins are locked, but you have no idea how many participants are inside and who owns what. As long as people cooperate, there is no need to touch on-chain coins.