Bitcoin Wiki - User contributions [en]

CoinJoin

2021-09-20T18:13:33Z

Aapachi: /* See Also */

'''CoinJoin''' is a trustless method for combining multiple Bitcoin payments from multiple spenders into a single transaction to make it more difficult for outside parties to determine which spender paid which recipient or recipients. Unlike many other privacy solutions, coinjoin transactions do not require a modification to the bitcoin protocol.

This type of transaction was first described in posts<ref>[https://bitcointalk.org/?topic=139581 I taint rich! (Raw txn fun and disrupting 'taint' analysis; >51kBTC linked!)]</ref><ref>[https://bitcointalk.org/?topic=279249 CoinJoin: Bitcoin privacy for the real world]</ref> by gmaxwell.

==Motivation==

Bitcoin is often promoted as a tool for privacy but the only privacy that exists in Bitcoin comes from pseudonymous addresses which are fragile and easily compromised through reuse, "taint" analysis, tracking payments, IP address monitoring nodes, web-spidering, and many other mechanisms. Once broken this privacy is difficult and sometimes costly to recover.

Traditional banking provides a fair amount of privacy by default. Your inlaws don't see that you're buying birth control that deprives them of grand children, your employer doesn't learn about the non-profits you support with money from your paycheck, and thieves don't see your latest purchases or how wealthy you are to help them target and scam you. Poor privacy in Bitcoin can be a major practical disadvantage for both individuals and businesses.

Even when a user ends address reuse by switching to [http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html BIP 32 address chains], they still have privacy loss from their old coins and the joining of past payments when they make larger transactions.

Privacy errors can also create externalized costs: You might have good practices but when you trade with people who don't (say ones using "green addresses") you and everyone you trade with loses some privacy. A loss of privacy also presents a grave systemic risk for Bitcoin: If degraded privacy allows people to assemble centralized lists of good and bad coins you may find Bitcoin's fungibility destroyed when your honestly accepted coin is later not honored by others, and its decentralization along with it when people feel forced to enforce popular blacklists on their own coin.

==Concept==

The idea is very simple, first some quick background:

[[Image:Twotx.png|class=fullwidth]]

A Bitcoin transaction consumes one or more inputs and creates one or more outputs with specified values.

Each input is an output from a past transaction. For each input there is a distinct signature (scriptsig) which is created in accordance with the rules specified in the past-output that it is consuming (scriptpubkey).

The Bitcoin system is charged with making sure the signatures are correct, that the inputs exist and are spendable, and that the sum of the output values is less than or equal to the sum of the input values (any excess becomes fees paid to miners for including the transaction).

It is normal for a transaction to spend many inputs in order to get enough value to pay its intended payment, often also creating an additional 'change' output to receive the unspent (and non-fee) excess.

There is no requirement that the scriptpubkeys of the inputs used be the same; i.e., no requirement that they be payments to the same address. And, in fact, when Bitcoin is correctly used with one address per payment, none of them will be the same.

When considering the history of Bitcoin ownership one could look at transactions which spend from multiple distinct scriptpubkeys as co-joining their ownership and make an assumption: How else could the transaction [[Common-input-ownership heuristic|spend from multiple addresses unless a common party controlled those addresses?]]

In the illustration 'transaction 2' spends coins which were assigned to 1A1 and 1C3. So 1A1 and 1C3 are necessarily the same party?

This assumption is incorrect. Usage in a single transaction does not prove common control (though it's currently pretty suggestive), and this is what makes '''CoinJoin''' possible:

The signatures, one per input, inside a transaction are '''completely''' independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.

To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size. The transaction would have N outputs of that size and potentially N more change outputs if some of the users provided input in excess of the target. All would sign the transaction, and then the transaction could be transmitted. No risk of theft at any point.

In the illustration 'transaction 2' has inputs from 1A1 and 1C3. Say we believe 1A1 is an address used for Alice and 1C3 is an address used for Charlie. Which of Alice and Charlie owns which of the 1D and 1E outputs?

The idea can also be used more casually. When you want to make a payment, find someone else who also wants to make a payment and make a joint payment together. Doing so doesn't increase privacy much, but it actually makes your transaction smaller and thus easier on the network (and lower in fees); the extra privacy is a perk.

Such a transaction is externally indistinguishable from a transaction created through conventional use. Because of this, if these transactions become widespread they improve the privacy even of people who do not use them, because no longer will input co-joining be strong evidence of common control.

There are many variations of this idea possible, and all can coexist because the idea requires no changes to the Bitcoin system. Let a thousand flowers bloom: we can have diversity in ways of accomplishing this and learn the best.

==Example==

An example 2-party coinjoin transaction. https://chain.localbitcoins.com/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046
The outputs to addresses 1MUzngtNnrQRXRqqRTeDmpULW8X1aaGWeR and 1Fufjpf9RM2aQsGedhSpbSCGRHrmLMJ7yY are coinjoined because they are both of value 0.01btc.

Another example is this 3-party coinjoin. https://chain.localbitcoins.com/tx/92a78def188053081187b847b267f0bfabf28368e9a7a642780ce46a78f551ba

==FAQ==

===Don't you need tor or something to prevent everyone from learning everyone's IP?===

Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)

However, gumming up "taint analysis" and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.

===Don't the users learn which inputs match up to which outputs?===

In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

Similar things can be accomplished with various zero-knowledge proof systems.

===Does the totally private version need to have a server at all? What if it gets shut down?===

No. The same privacy can be achieved in a decentralized manner where all users act as blind-signing servers. This ends up needing n^2 signatures, and distributed systems are generally a lot harder to create. I don't know if there is, or ever would be, a reason to bother with a fully distributed version with full privacy, but it's certainly possible.

===What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?===

Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.

However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.

In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.

Gaining DOS immunity in a decentralized system is considerably harder, because it's hard to tell which user actually broke the rules. One solution is to have users perform their activity under a zero-knowledge proof system, so you could be confident which user is the cheater and then agree to ignore them.

In all cases you could supplement anti-DOS mechanisms with proof of work, a fidelity bond, or other scarce resource usage. But I suspect that it's better to adapt to actual attacks as they arise, as we don't have to commit to a single security mechanism in advance and for all users. I also believe that bad input exclusion provides enough protection to get started.

===Isn't the anonymity set size limited by how many parties you can get in a single transaction?===

Not quite. The anonymity set size of a single transaction is limited by the number of parties in it, obviously. And transaction size limits as well as failure (retry) risk mean that really huge joint transactions would not be wise. But because these transactions are cheap, there is no limit to the number of transactions you can cascade.

In particular, if you can build transactions with m participants per transaction you can create a sequence of m*3 transactions which form a three-stage [http://en.wikipedia.org/wiki/Clos_network switching network] that permits any of m^2 final outputs to have come from any of m^2 original inputs (e.g. using three stages of 32 transactions with 32 inputs each 1024 users can be joined with a total of 96 transactions). This allows the anonymity set to be any size, limited only by participation.

In practice I expect most users only want to prevent nosy friends (and thieves) from prying into their financial lives, and to recover some of the privacy they lost due to bad practices like address reuse. These users will likely be happy with only a single pass; other people will just operate opportunistically, while others may work to achieve many passes and big anonymity sets. All can coexist.

===How does this compare to [http://zerocoin.org/ zerocoin]?===

As a crypto and computer science geek I'm super excited by Zerocoin: the technology behind it is fascinating and important. But as a Bitcoin user and developer the promotion of it as the solution to improved privacy disappoints me.

Zerocoin has a number of serious limitations:
* It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).
* It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).
* It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)
* Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.
* The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.
* Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance.

Some of these things may improve significantly with better math and software engineering over time.

But above all: '''Zerocoin requires a soft-forking change to the Bitcoin protocol''', which all full nodes must adopt, which would commit Bitcoin to a particular version of the Zerocoin protocol. This cannot happen fast—probably not within years, especially considering that there is so much potential for further refinement to the algorithm to lower costs. It would be politically contentious, as some developers and Bitcoin businesses are very concerned about being overly associated with "anonymity". Network-wide rule changes are something of a suicide pact: we shouldn't, and don't, take them lightly.

'''CoinJoin transactions work today''', and they've worked since the first day of Bitcoin. They are indistinguishable from normal transactions and thus cannot be blocked or inhibited except to the extent that any other Bitcoin transaction could be blocked.

(As an aside: ZC could potentially be used externally to Bitcoin in a decentralized CoinJoin as a method of mutually blinding the users in a DOS attack resistant way. This would allow ZC to mature under live fire without taking its costs or committing to a specific protocol network-wide.)

The primary argument I can make for ZC over CoinJoin, beyond it stoking my crypto-geek desires, is that it may potentially offer a larger anonymity set. But with the performance and scaling limits of ZC, and the possibility to construct sorting network transactions with CJ, or just the ability to use hundreds of CJ transactions with the storage and processing required for one ZC transactions, I don't know which would actually produce bigger anonymity sets in practice. E.g. To join 1024 users, just the ZC redemptions would involve 20k * 1024 bytes of data compared to less than 3% of that for a complete three-stage cascade of 32 32-way joint transactions. Though the ZC anonymity set could more easily cross larger spans of time.

The anonymity sets of CoinJoin transactions could easily be big enough for common users to regain some of their casual privacy and that's what I think is most interesting.

===How does this compare to [https://bitcointalk.org/index.php?topic=277389.0 CoinWitness]?===

CoinWitness is even rocket-sciency than Zerocoin, it also shares many of the weaknesses as a privacy-improver: Novel crypto, computational cost, and the huge point of requiring a soft fork and not being available today. It may have some scaling advantages if it is used as more than just a privacy tool. But it really is overkill for this problem, and won't be available anytime real soon.

===Sounds great! Where is it?===

The two main ready-to-use software CoinJoin implementations are [[Wasabi Wallet]] (https://wasabiwallet.io/) and [[JoinMarket]] (https://github.com/Joinmarket-Org/joinmarket-clientserver). Currently, crypto-processing [[Apirone]] (https://apirone.com/) use pre-mix of UTXO based on CoinJoin technology.

Wasabi works thanks to a CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) who cannot steal from, nor breach the privacy of the participants. The company makes its income by taking a fee (0.003% * anonymity set) from each CoinJoin transaction.

JoinMarket, instead, works by creating a new kind of market consisting of one group of participants (called market makers) that will always be available to take part in CoinJoins at any time and another group participants (called market takers) that can create a CoinJoin at any time. The takers pay a fee which incentivizes the makers.

==See Also==
* [[User:Gmaxwell/state_of_coinjoin]]
* [[Common-input-ownership heuristic]]
* [[JoinMarket]]
* [https://btcwalletmixer.com Coinjoin Service Online]

==References==
<references>
</references>

[[Category:Privacy]]

Mixing service

2021-09-19T21:47:58Z

Aapachi: /* See Also */

{{outdated}}Using bitcoins is an excellent way to stay anonymous while making your purchases, donations, and p2p payments, without losing money through inflated transaction fees. But Bitcoin transactions are never truly anonymous. Bitcoin activities are recorded and available publicly via the blockchain — a comprehensive database which keeps a record of bitcoin transactions. And when you finally use Bitcoin to pay for goods and services, you will of course need to provide your name and address to the seller for delivery purposes. It means that a third party can trace your transactions and find ID information. To avoid this, such mixing service provide the ability to exchange your bitcoins for different ones which cannot be associated with the original owner.

Prior to the advent of trustless alternatives, '''mixing services''' (also called '''tumblers''') were used to mix one's funds with other people's money, intending to confuse the trail back to the funds' original source. In traditional financial systems, the equivalent would be moving funds through [[Wikipedia:Offshore bank|banks located in countries with strict bank-secrecy laws]], such as the Cayman Islands, the Bahamas and Panama.

When mixing bitcoins, you send your money to an anonymous service and, if they are well-intentioned, they will send you someone else's tainted coins. So, now, whatever those coins were used for may now be traceable back to you. Additionally, mixing large amounts of money may be illegal, being in violation of [[Wikipedia:Structuring|anti-structuring laws]].

==See Also==

* [[Anonymity]]
* [[:Category:Mixing Services]]
* [http://www.bitcoin.org/smf/index.php?topic=2893.0 RFC: Bitcoin Mixnet]
* [https://www.btcwalletmixer.com Bitcoin mixer]

{{wp|Cryptocurrency_tumbler}}

[[Category:Financial]]
[[Category:Privacy]]

Transaction accelerator

2021-09-19T21:04:16Z

Aapachi: /* Bitcoin transaction accelerators */

=What to Do if Your Bitcoin Transaction Gets "Stuck"=

The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)

Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.

This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.

==Fee Bumping==

The recommended approach to "accelerating" a transaction is to perform a [[fee bumping]] methods, either [[replace by fee|replace-by-fee]] (RBF), or [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]] (CPFP), which are available to:

* Sender of the Bitcoin transaction: Replace-by-fee (RBF), and Child-pays-for-parent (CPFP)
* Recipient of the Bitcoin transaction: Child-pays-for-parent (CPFP)

==Bitcoin transaction accelerators==

===Mining Pool Accelerators===

A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average.

* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.

* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - Working as of December 30, 2020. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 10 sat/B. The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit (of 100) and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next hour to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.

* [https://pushtx.com PushTX] - [[Poolin]] provides a transaction accelerator service in cooperation with several leading mining pools. PushTX is a [https://www.btcaccelerator.io bitcoin transaction accelerator] that allows you to get faster confirmations on your unconfirmed transaction.

* [https://btcnitro.com BTC Nitro] - Similar to the services listed above, BTC Nitro works with a number of mining pools and will insert your transaction into a block about to be be mined for a flat fee of $25 USD. They also guarantee a full refund of the fee if the transaction you want to accelerate doesn't get confirmed within 24 hours of payment. BTC Nitro also offer free rebroadcasting service for those who just wish to rebroadcast their transaction to the blockchain.

* [https://www.btcaccelerator.io BTC Accelerator] - btcaccelerator.io works with a number of mining pools and will insert your transaction for free.

===Third Party Accelerators===
There are additional services claiming to be able to "accelerate" a transaction. Their ability to get a transaction confirmed faster is limited to re-[https://en.bitcoin.it/wiki/Transaction_broadcasting broadcasting] your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a "stuck" transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.

It is likely these "transaction accelerators" that are not the mining pools themselves '''are not actually helping to get a transaction confirmed faster'''.

* https://btcnitro.com/ This is the free service offered by BTC Nitro that just rebroadcasts your transaction to the blockchain using various public and private nodes.
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.

Transaction accelerator

2021-09-19T20:54:19Z

Aapachi: /* Bitcoin transaction accelerators */

=What to Do if Your Bitcoin Transaction Gets "Stuck"=

The number of transactions on the Bitcoin network has steadily increased over the years. This means more blocks are filling up. And as not all transactions can be included in the blockchain straight away, backlogs form in miners’ “mempools” (a sort of “transaction queue.”)

Miners typically pick the transactions that pay the most fees and include these in their blocks first. Transactions that include lower fees are “outbid” on the so called “fee market,” and remain in miners’ mempools until a new block is found. If the transaction is outbid again, it has to wait until the next block.

This can lead to a suboptimal user experience. Transactions with too low a fee can take hours or even days to confirm, and sometimes never confirm at all.

==Fee Bumping==

The recommended approach to "accelerating" a transaction is to perform a [[fee bumping]] methods, either [[replace by fee|replace-by-fee]] (RBF), or [[Transaction fees#Feerates_for_dependent_transactions_.28child-pays-for-parent.29|child-pays-for-parent]] (CPFP), which are available to:

* Sender of the Bitcoin transaction: Replace-by-fee (RBF), and Child-pays-for-parent (CPFP)
* Recipient of the Bitcoin transaction: Child-pays-for-parent (CPFP)

==Bitcoin transaction accelerators==

===Mining Pool Accelerators===

A mining pool may offer a premium service in which they will prioritize a transaction, usually for a fee. The ability for that pool to get a transaction confirmed is limited to their ability to get a block confirmed -- and most pools have a tiny [https://www.blockchain.com/pools fraction of the hashrate]. For example, if a pool has 10% of the hashrate, they mine about a block every 100 minutes (1 hour and 40 minutes), on average. If a pool has 5% of the hashrate, then they mine one block about every 200 minutes (3 hours and 20 minutes), on average.

* https://pushtx.btc.com: This service is provided by BTC.com in cooperation with several main mining pools. The fee was around 70 USD on December 20, 2017 and the transaction was confirmed within 3 hours. You can pay by BCH or country-specific methods and they estimate the fee based on the transaction size. They promise a chance of 75% for including transactions in the next block within one hour. Within 4 hours the chance is claimed to be at 98%. They guarantee that if the transaction isn’t confirmed in 12 hours, the fees will be fully refunded to your card within 10 ~ 15 days. This policy is not applicable to the transactions which are removed or double-spent during the acceleration process.

* [https://pool.viabtc.com/tools/txaccelerator/ ViaBTC] - Working as of December 30, 2020. ViaBTC implemented this service to protest against the prior 1MB limitation of the Bitcoin network. ViaBTC gives priority to user-submitted transactions for the next mined blocks by the ViaBTC pool. The only requirement is the transaction must include a minimum fee of 10 sat/B. The free-to-use nature of the service may have made it widely popular as every hour, the number of transaction requested reaches its limit (of 100) and it is common to be presented with the message “Submissions are beyond limit. Please try later.” on the top middle of the page. This means one must wait for the next hour to try a new submission. After submitting a transaction, there is a wait for the next block to be mined by ViaBTC Pool.

* [https://pushtx.com PushTX] - [[Poolin]] provides a transaction accelerator service in cooperation with several leading mining pools. PushTX is a bitcoin transaction accelerator that allows you to get faster confirmations on your unconfirmed transaction.

* [https://btcnitro.com BTC Nitro] - Similar to the services listed above, BTC Nitro works with a number of mining pools and will insert your transaction into a block about to be be mined for a flat fee of $25 USD. They also guarantee a full refund of the fee if the transaction you want to accelerate doesn't get confirmed within 24 hours of payment. BTC Nitro also offer free rebroadcasting service for those who just wish to rebroadcast their transaction to the blockchain.

* [https://www.btcaccelerator.io BTC Accelerator] - btcaccelerator.io works with a number of mining pools and will insert your transaction for free.

===Third Party Accelerators===
There are additional services claiming to be able to "accelerate" a transaction. Their ability to get a transaction confirmed faster is limited to re-[https://en.bitcoin.it/wiki/Transaction_broadcasting broadcasting] your transaction, to help in the situation where that mining pool has dropped your transaction already. The Bitcoin Core client already does re-broadcast a "stuck" transaction periodically to peer nodes, though these services possibly may broadcast a transaction directly to known mining pool nodes. These services could also pay a mining pool to include your transaction, just as you could do that yourself.

It is likely these "transaction accelerators" that are not the mining pools themselves '''are not actually helping to get a transaction confirmed faster'''.

* https://btcnitro.com/ This is the free service offered by BTC Nitro that just rebroadcasts your transaction to the blockchain using various public and private nodes.
* https://bitaccelerate.com/ Free Bitcoin transaction accelerator. The service actually rebroadcasts your transaction via different nodes.