Bitcoin Wiki - User contributions [en]

CoinJoin

2023-06-13T16:12:52Z

TheHiddenWiki:

'''[https://bitcoin-mixer.xyz/ 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 grandchildren, 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 more 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 Wallet implements the [https://eprint.iacr.org/2021/206 WabiSabi] protocol for the construction of CoinJoin transactions with the aid of a central 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. Coinjoining coins with a value above 0.01 BTC costs 0.3% as a [https://github.com/zkSNACKs/WalletWasabi/tree/master/WalletWasabi.Backend coordinator fee] + [https://mempool.space/ mining fees]. Inputs of 0.01 BTC or below do not pay coordinator fees, nor remixes, even after one transaction. Thus, a payment made with coinjoined funds allows the sender and the recipient to remix their coins without paying coordinator fees.

{| class="wikitable" style="text-align:center;"
|- style="text-align:left;"
!
! > 0.01 BTC
! 0.01 BTC and less
|- style="vertical-align:middle;"
| Fresh input
| 0.3% coordination fee + mining fees
| mining fees
|- style="vertical-align:middle; background-color:rgba(73, 88, 107, 0.1);"
| Remix*
| mining fees
| mining fees
|- style="text-align:left;"
|}
<nowiki>*</nowiki>Remix includes a 1 hop 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]]

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

[[Category:Privacy]]
[[Category:Mixing_Services]]

Wasabi Wallet

2023-06-01T19:44:25Z

TheHiddenWiki:

'''[https://wasabimixer.com Wasabi Mixer Wallet]''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop that implements trustless '''[[CoinJoin]]'''. The code is on GitHub at [https://github.com/https://github.com/zkSNACKs/WalletWasabi zkSNACKs/WalletWasabi] where anyone can see, verify, and contribute to the project. Wasabi Wallet is trustless by design, meaning neither the public nor the developers can breach your privacy. This is accomplished via [https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki client-side block filtering](BIP158), communication over the [https://www.torproject.org Tor anonymity network], and the [https://github.com/zkSNACKs/WabiSabi WabiSabi] protocol: an anonymous credential scheme for centrally coordinated coinjoin transactions. The coinjoin coordinator is run by zkSNACKS Ltd., the company that sponsors the development of Wasabi Wallet. The developers have gone to great lengths to ensure that the coordinator cannot steal nor breach the privacy of any participant. This can all be verified by examining the open-source code.

Wasabi Wallet strives toward establishing solid industry best practices and standards. It implements [https://en.bitcoin.it/wiki/Deterministic_wallet Hierarchical Deterministic wallets] , [https://en.bitcoin.it/wiki/Address_reuse address reuse avoidance], as well as mandatory coin labeling. The wallet uses BIP-158 client-side block filtering to obtain its own transaction history in a private way and it has a one-click partial full node integration as it ships with Bitcoin Knots. If the user already has a Bitcoin full node on a local or remote device, then it is possible to specify the IP address and port, or the Tor onion service, and Wasabi will use it to verify and enforce the rules of Bitcoin.

In addition to this, Wasabi has advanced cutting-edge features like Opt-in PayJoin and [https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-is-the-dust-threshold Dust attack] protections. You can find a full list of [https://docs.wasabiwallet.io/using-wasabi/BIPs.html#what-is-supported supported BIPs] in the wallet documentation. This is part of Wasabi Wallet’s [https://docs.wasabiwallet.io/ complete and detailed documentation] containing descriptions about the architecture and functionality of the wallet, as well as helpful tutorials on how to use it. There is also a [https://www.youtube.com/watch?v=ry6qIyQmzRE&list=PLPwc75tPMdsi2bSYL6qi79izHIvps2E6b tutorials playlist] on YouTube with short videos on how to use and interact with Wasabi Wallet.
=Wasabi Wallet installation=
[[File:Wasabiwallet.io.png|thumb|right|WasabiWallet.io homepage]]

Wasabi Wallet is easy to install. First, you have to go to https://wasabiwallet.io or http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion (for the onion service) and download the version for your own operating system. Wasabi is available in most operating systems with 64-bit architecture.

Linux, Windows and macOS (intel & M1) are the officially supported operating systems. For the complete compatibility list check the [https://github.com/zkSNACKs/WalletWasabi/blob/master/WalletWasabi.Documentation/WasabiCompatibility.md Wasabi Compatibility document]. It is also possible to manually verify the PGP signatures and the deterministic builds.

For a step-by-step tutorial on the installation and PGP verification, you can follow the [https://docs.wasabiwallet.io/using-wasabi/InstallPackage.html relevant chapter in the documentation].

Once the software is installed, icons will be created on the desktop and on the menu, you can click on them to open the program. If you have downloaded the ''.tar.gz'' version, then first extract it and then run the ''./wassabee'' command.

=Run Wasabi Wallet=

When you run Wasabi for the first time, you will be prompted to generate a wallet. You have the option to create a new wallet, connect to a hardware wallet, import a wallet from a file, or recover a wallet with a 12 word seed. When you generate the wallet, you will then be prompted to choose a unique name for it; choose a name that reflects the purpose of the wallet. If you create a new wallet you will be presented with 12 recovery words to record ([https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP39]), followed by the option to encrypt your wallet with a secure password ([https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki BIP38]). You will always need the password in order to login to your wallet and whenever you spend your bitcoins, so remember to properly backup both the password and the 12 recovery words.

=Send and Receive bitcoin via Wasabi Wallet=

As explained above, Wasabi has '''mandatory coin labeling'''. This means that in order to send or receive bitcoin we have to specify custom labels for the address. These labels should be the name of any entities who know that this address is yours. Properly annotated labels is one of the most important features in Wasabi Wallet because it helps you better manage your privacy. A simple example of labeling is as follows: Alice pays you back for last night's pizza, so you label your receive address as ''Alice''. Now you have a record of the specific UTXO that Alice is aware of and can trace on the [[Block chain]].

'''Receiving Bitcoin'''
# Click ''Receive'' button
# Add Labels
# Scan or copy the unused bitcoin address.

'''Sending Bitcoin'''
# Click ''Send'' button
# Paste bitcoin address
# Enter amount in BTC or USD
# Add Labels
# Preview Transaction (option to specify custom transaction fee rate)
# Enter password.

=Coinjoin via Wasabi Wallet=

[[File:Wasabi Wallet Coinjoin.png|thumb | right |Wasabi Wallet 2.0]]

'''Coinjoins''' are the most important feature of Wasabi Wallet. '''Schnorr blind signatures''', (which is similar to the cryptography used in chaumian blind signatures and [[blinded bearer certificates]]) make it possible to run '''trustless''' (meaning nobody can steal) and '''private''' (meaning even the coordinator cannot spy) coinjoins where nobody learns the linkage between the mixed transaction inputs and outputs.

Wasabi Wallet implements the [https://eprint.iacr.org/2021/206 WabiSabi] protocol, which is an anonymous credential scheme for central coordinated coinjoin transactions. The zkSNACKs Ltd. company is who coordinates the coinjoin transactions for Wasabi Wallet. They take a fee for coordinating the coinjoin and use these funds to sponsors the Wasabi developers. The fee structure is as follows: coins with a value above 0.01 BTC costs 0.3% as a [https://github.com/zkSNACKs/WalletWasabi/tree/master/WalletWasabi.Backend coordinator fee] + [https://mempool.space/ mining fees]. Inputs of 0.01 BTC or below do not pay coordinator fees, nor remixes, even after one transaction. Thus, a payment made with coinjoined funds allows the sender and the recipient to remix their coins without paying coordinator fees.

<br>

{| class="wikitable" style="text-align:center;"
|- style="text-align:left;"
!
! > 0.01 BTC
! 0.01 BTC and less
|- style="vertical-align:middle;"
| Fresh input
| 0.3% coordination fee + mining fees
| mining fees
|- style="vertical-align:middle; background-color:rgba(73, 88, 107, 0.1);"
| Remix*
| mining fees
| mining fees
|- style="text-align:left;"
|}
<nowiki>*</nowiki>Remix includes a 1 hop transaction

<br>

[https://github.com/zkSNACKs/WabiSabi WabiSabi] was introduced in Wasabi Wallet 2.0 and improves upon the original [https://github.com/nopara73/ZeroLink ZeroLink] protocol of Wasabi Wallet 1.0. WabiSabi is a novel communication protocol for creating bitcoin coinjoin transactions with arbitrary amounts, which provides more privacy at less cost for the user. This new protocol utilizes keyed verification anonymous credentials and homomorphic value commitments to enable novel use cases and reduced overhead. WabiSabi enables the emergence of much larger coinjoins rounds with hundreds of inputs and outputs (e.g., [https://mempool.space/tx/4f0436e9406e5930f9cdaaf94144de72b2b204690e7b19fe5f80067545440a7c 4f0436e9406e5930f9cdaaf94144de72b2b204690e7b19fe5f80067545440a7c]).

=Controversies=

On March 13 2022, Wasabi announced that its zkSNACKs coordinator had plans for blacklisting tainted coins, which would prevent them from participating in CoinJoins.<ref>https://www.coindesk.com/tech/2022/03/14/wasabi-wallets-coinjoin-coordinator-to-blacklist-certain-bitcoin-transactions/</ref> This was met with backlash from some parts of the Bitcoin community who did not like the concept of taint.<ref>https://bitcointalk.org/index.php?topic=5405325.0</ref>. Wasabi has stated that they do not have access to any information that can link user identities, and acknowledged that the decision to blacklist tainted outputs was done proactively, with no legislation requiring them to do so.<ref>https://bitcoinist.com/wasabi-side-reasons-blacklisting-from-coinjoin/</ref>

[[Category:Privacy]]

=References=

Bitcoin mixer

2023-04-14T16:56:18Z

TheHiddenWiki: Created page with "'''Bitcoin mixer''' is software (or a service like CoinJoin) that accepts Bitcoin from multiple users, mixes them so you can’t identify who sent how much, and then sends..."

'''Bitcoin mixer''' is software (or a service like [[CoinJoin]]) that accepts Bitcoin from multiple users, mixes them so you can’t identify who sent how much, and then sends out different bitcoins to their destinations.

If you were to view such a transaction on an explorer, you’d find the address of the mixer as the recipient (in the case of an outgoing transaction from your wallet) instead of a Bitcoin address. Similarly, if you typed in a transaction recipient’s address, and looked to see where the coins came from, all you’d find would be the tumbler’s address.

It’s called a “mixer” because it mixes your coins with other holders' coins to the point that none of them can be connected back to their original wallet addresses.

Hence, when you use this solution, you can send Bitcoin or receive it while remaining completely anonymous.

These anonymous transactions aren’t always free. Some of these Bitcoin tumblers require you to pay service fees for mixing your coins.

==See Also==

* [[Anonymity]]
* [[:Category:Mixing Services]]

Help:Introduction

2023-01-26T21:51:04Z

TheHiddenWiki:

The purpose of this page is to provide a general overview of the Bitcoin system and economy.

==Basic Concepts==

===Currency===

Alice wants to buy the [[Alpaca|Alpaca socks]] which Bob has for sale. In return, she must provide something of equal value to Bob. The most efficient way to do this is by using a medium of exchange that Bob accepts which would be classified as currency. Currency makes trade easier by eliminating the need for [https://en.wikipedia.org/wiki/Coincidence_of_wants coincidence of wants] required in other systems of trade such as barter. Currency adoption and acceptance can be global, national, or in some cases local or community-based.

===Banks===

Alice need not provide currency to Bob in-person. She may instead transfer this value by first entrusting her currency to a bank who promises to store and protect Alice's currency notes. The bank gives Alice a written promise (called a "bank statement") that entitles her to withdraw the same number of currency bills that she deposited. Since the money is still Alice's, she is entitled to do with it whatever she pleases, and the bank (like most banks), for a small fee, will do Alice the service of passing on the currency bills to Bob on her behalf. This is done by Alice's bank by giving the dollar bills to Bob's bank and informing them that the money is for Bob, who will then see the amount the next time he checks his balance or receives his bank statement.

Since banks have many customers, and bank employees require money for doing the job of talking to people and signing documents, banks in recent times have been using machines such as ATMs and web servers that do the job of interacting with customers instead of paid bank employees. The task of these machines is to learn what each customer wants to do with their money and, to the extent that it is possible, act on what the customer wants (for example, ATMs can hand out cash). Customers can always know how much money they have in their accounts, and they are confident that the numbers they see in their bank statements and on their computer screens accurately reflect the number of dollars that they can get from the bank on demand. They can be so sure of this that they can accept those numbers in the same way they accept paper banknotes (this is similar to the way people started accepting paper dollars when they had been accepting gold or silver).

Such a system has several disadvantages:
* It is costly. [https://en.wikipedia.org/wiki/Electronic_funds_transfer EFTs] in Europe can cost 25 euros. Credit transactions can cost several percent of the transaction.
* It is slow. Checking and low cost wire services take days to complete.
* In most cases, it cannot be anonymous.
* Accounts can be frozen, or their balance partially or wholly confiscated.
* Banks and other payment processors like PayPal, Visa, and Mastercard may refuse to process payments for certain legal entities.

Bitcoin is a system of owning and voluntarily transferring amounts of so-called ''bitcoins'', in a manner similar to an on-line banking, but pseudonymously and without reliance on a central authority to maintain account balances. If bitcoins are valuable, it is because they are useful and limited in supply.

==Bitcoin Basics==

===Creation of coins===

The creation of coins must be limited for the currency to have any value.

New coins are slowly [[Mining|mined]] into existence by following a mutually agreed-upon set of rules. A user [[Mining|mining]] bitcoins is running a software program that searches for a solution to a very difficult math problem the difficulty of which is precisely known. This difficulty is automatically adjusted on a predictable schedule so that the number of solutions found globally for a given unit of time is constant: the global system aims for 6 per hour. When a solution is found, the user may tell everyone of the existence of this newly found solution along with other information packaged together in what is called a "[[Block|block]]". The solution itself is a [[Proof of work| proof-of-work]] or PoW. It is hard to find, but easy to verify.

Blocks create 12.5 new bitcoins at present [October 2016]. This amount, known as the block reward, is an incentive for people to perform the computation work required for generating blocks. Roughly every 4 years, the number of bitcoins that can be "mined" in a block reduces by 50%. Originally the block reward was 50 bitcoins; it halved in November 2012; it then halved again in July 2016. Any block that is created by a malicious user that does not follow this rule (or any other rules) will be rejected by everyone else. In the end, no more than 21 million bitcoins will ever exist.

Because the block reward will decrease over the long term, miners will some day instead pay for their hardware and electricity costs by collecting [[Transaction_fee|transaction fees]]. The sender of money may voluntarily pay a small transaction fee which will be kept by whoever finds the next block. Paying this fee will encourage miners to include the transaction in a block more quickly.

===Sending payments===

To guarantee that a third-party, let's call her Eve, cannot spend other people's bitcoins by creating transactions in their names, Bitcoin uses [[Wikipedia:Public-key_cryptography|public key cryptography]] to make and verify digital signatures. In this system, each person, such as Alice or Bob, has one or more addresses each with an associated pair of public and private keys that they may hold in a [[Wallet|wallet]]. Only the user with the private key can sign a transaction to give some of their bitcoins to somebody else, but anyone can validate the signature using that user’s public key.

Suppose Alice wants to send a bitcoin to Bob.
* Bob sends his address to Alice.
* Alice adds Bob’s address and the amount of bitcoins to transfer to a message: a 'transaction' message.
* Alice signs the transaction with her private key, and announces her public key for signature verification.
* Alice broadcasts the transaction on the Bitcoin network for all to see.

(Only the first two steps require human action. The rest is done by the Bitcoin client software.)

Looking at this transaction from the outside, anyone who knows that these addresses belong to Alice and Bob can see that Alice has agreed to transfer the amount to Bob, because nobody else has Alice's private key. Alice would be foolish to give her private key to other people, as this would allow them to sign transactions in her name, removing funds from her control.

Later on, when Bob wishes to transfer the same bitcoins to Charley, he will do the same thing:
* Charlie sends Bob his address.
* Bob adds Charlie's address and the amount of bitcoins to transfer to a message: a 'transaction' message.
* Bob signs the transaction with his private key, and announces his public key for signature verification.
* Bob broadcasts the transaction on the Bitcoin network for all to see.

Only Bob can do this because only he has the private key that can create a valid signature for the transaction.

Eve cannot change whose coins these are by replacing Bob’s address with her address, because Alice signed the transfer to Bob using her own private key, which is kept secret from Eve, and instructing that the coins which were hers now belong to Bob. So, if Charlie accepts that the original coin was in the hands of Alice, he will also accept the fact that this coin was later passed to Bob, and now Bob is passing this same coin to him.

===Preventing [[double-spending]]===

The process described above does not prevent Alice from using the same bitcoins in more than one transaction. The following process does; this is the primary innovation behind Bitcoin.

* Details about the [[Transactions|transaction]] are [[Network|sent and forwarded]] to all or as many other computers as possible.
* A constantly growing chain of [[Blocks|blocks]] that contains a record of all transactions is collectively maintained by all computers (each has a full copy).
* To be accepted in the chain, transaction blocks must be valid and must include [[proof of work]] (one block generated by the network every 10 minutes).
* Blocks are chained in a way so that, if any one is modified, all following blocks will have to be recomputed.
* When multiple valid continuations to this chain appear, only the longest such branch is accepted and it is then extended further.

When Bob sees that his transaction has been included in a block, which has been made part of the single longest and fastest-growing block chain (extended with significant computational effort), he can be confident that the transaction by Alice has been accepted by the computers in the network and is permanently recorded, preventing Alice from creating a second transaction with the same coin. In order for Alice to thwart this system and double-spend her coins, she would need to muster more computing power than all other Bitcoin users combined.

===Anonymity===

When it comes to the Bitcoin network itself, there are no "accounts" to set up, and no e-mail addresses, user-names or passwords are required to hold or spend bitcoins. Each balance is simply associated with an address and its public-private key pair. The money "belongs" to anyone who has the private key and can sign transactions with it. Moreover, those keys do not have to be registered anywhere in advance, as they are only used when required for a transaction. Transacting parties do not need to know each other's identity in the same way that a store owner does not know a cash-paying customer's name.

A [[Address|Bitcoin address]] mathematically corresponds to a public key and looks like this:

:1PHYrmdJ22MKbJevpb3MBNpVckjZHt89hz

Each person can have many such addresses, each with its own balance, which makes it very difficult to know which person owns what amount. In order to protect his [[Anonymity|privacy]], Bob can generate a new public-private key pair for each individual receiving transaction and the Bitcoin software encourages this behavior by default. Continuing the example from above, when Charlie receives the bitcoins from Bob, Charlie will not be able to identify who owned the bitcoins before Bob.

===CoinJoin===

[[CoinJoin]] open source project allowing bitcoin users to maintain their privacy. In each CoinJoin transaction, the input bitcoins are exchanged instantly for unrelated bitcoins sent by another CoinJoin participant. No trail is left. No centralized authority can record this transaction.

===Capitalization / Nomenclature===

Since Bitcoin is both a currency and a protocol, capitalization can be confusing. Accepted practice is to use ''Bitcoin'' (singular with an upper case letter B) to label the protocol, software, and community, and ''bitcoins'' (with a lower case b) to label units of the currency.

==Where to see and explore==

You can directly explore the system in action by visiting [https://btc.com/ BTC.com], [https://www.biteasy.com/ Biteasy.com], [https://blockchain.info/ Blockchain.info], [http://btc.blockr.io/ Blokr.io Bitcoin Block Explorer] or [https://blockexplorer.com/ Bitcoin Block Explorer].
The site shows you the latest blocks in the block chain. The [[Block_chain|block chain]] contains the agreed history of all transactions that took place in the system.
Note how many blocks were generated in the last hour, which on average will be 6. Also notice the number of transactions and the total amount transferred in the last hour (last time I checked it was about 64 and 15K).
This should give you an indication of how active the system is.

Next, navigate to one of these blocks.
The block's [[hash]] begins with a run of zeros. This is what made creating the block so difficult; a hash that begins with many zeros is much more difficult to find than a hash with few or no zeros. The computer that generated this block had to try many ''Nonce'' values (also listed on the block's page) until it found one that generated this run of zeros.
Next, see the line titled ''Previous block''. Each block contains the hash of the block that came before it. This is what forms the chain of blocks.
Now take a look at all the transactions the block contains. The first transaction is the income earned by the computer that generated this block. It includes a fixed amount of coins created out of "thin air" and possibly a fee collected from other transactions in the same block.

Drill down into any of the transactions and you will see how it is made up of one or more amounts coming in and out.
Having more than one incoming and outgoing amount in a transaction enables the system to join and break amounts in any possible way, allowing for any fractional amount needed. Each incoming amount is a past transaction (which you can also view) from someone's address, and each outgoing amount is addressed to someone and will be part of a future transaction (which you can also navigate down into if it has already taken place.)

Finally, you can follow any of the [[Address|addresses]] links and see what public information is available for them.

To get an impression of the amount of activity on the Bitcoin network, you might like to visit the monitoring websites [[Bitcoin Monitor]] and [[Bitcoin Watch]]. The first shows a real-time visualization of events on the Bitcoin network, and the second lists general statistics on the amount and size of recent transactions.

===How many people use Bitcoin?===

This is quite a difficult question to answer accurately. One approach is to count how many bitcoin clients connected to the network in the last 24 hours. We can do this because some clients transmit their addresses to the other members of the network periodically;

*In September 2011, this method suggested that there were about {{formatnum:60000}} users.

*In October 2014, according to [https://www.coindesk.com/state-of-bitcoin-q3-2014-report-maturing-ecosystem-price-pressure/ Coindesk report] there were more than 7.5 million bitcoin wallets.

*In October 2016, according to [https://Blockchain.info blockchain.info] user counts based on Blockchain wallet, there are about 8.8 mln registered Bitcoin users on its platform. [https://cointelegraph.com/news/counting-them-all-how-to-figure-out-actual-number-of-bitcoin-users Cointelegraph report]

*According to [https://blockchain.info/charts/my-wallet-n-users blockchain.info], from October 2016 till January 2018 the Bitcoin user base has almost tripled for total of 22 million users.

==See Also==
* [http://bitcoinhelp.net Bitcoin Help] — the simple guide to Bitcoin.
* Learn the entire history of Bitcoin in the interactive timeline at [http://historyofbitcoin.org History of Bitcoin].
* [https://www.weusecoins.com What Is Bitcoin?]
* [https://www.bitcoinmining.com What Is Bitcoin Mining?]

[[zh-cn:简介]]

[[de:Einführung]]
[[fr:Introduction]]

CoinJoin

2023-01-03T21:19:34Z

TheHiddenWiki:

'''[https://coin-join.com/ 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 grandchildren, 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 more 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 Wallet implements the [https://eprint.iacr.org/2021/206 WabiSabi] protocol for the construction of CoinJoin transactions with the aid of a central 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. Coinjoining coins with a value above 0.01 BTC costs 0.3% as a [https://github.com/zkSNACKs/WalletWasabi/tree/master/WalletWasabi.Backend coordinator fee] + [https://mempool.space/ mining fees]. Inputs of 0.01 BTC or below do not pay coordinator fees, nor remixes, even after one transaction. Thus, a payment made with coinjoined funds allows the sender and the recipient to remix their coins without paying coordinator fees.

{| class="wikitable" style="text-align:center;"
|- style="text-align:left;"
!
! > 0.01 BTC
! 0.01 BTC and less
|- style="vertical-align:middle;"
| Fresh input
| 0.3% coordination fee + mining fees
| mining fees
|- style="vertical-align:middle; background-color:rgba(73, 88, 107, 0.1);"
| Remix*
| mining fees
| mining fees
|- style="text-align:left;"
|}
<nowiki>*</nowiki>Remix includes a 1 hop 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]]

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

[[Category:Privacy]]
[[Category:Mixing_Services]]

CoinJoin

2023-01-03T20:42:17Z

TheHiddenWiki:

User talk:Luke-jr

2014-09-11T14:53:08Z

TheHiddenWiki:

* My comments on [[Tonal Bitcoin]] are not "trolling". They are my opinions, and you can discuss it on the talk page based on the merits. If you delete my comments again from a discuss page, I will ask the administrators to ban your account. That is not acceptable wikipedia behavior [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]])

== Thanks for helping on the [[Heaven Sent Gaming]] article. ==

The bias was sloppy copyediting on my part, thanks for fixing it. [[User:Anon y Mouse|Anon y Mouse]] ([[User talk:Anon y Mouse|talk]]) 10:55, 24 August 2014 (UTC)

== Headers ==

Hi Luke, can you restore the [[Headers]] article please? It was useful for finding information about headers, and it's not obvious where people need to go without this reference article. There's already an article for [[block]]s, so I don't see why you needed to delete this, since it was useful.

: There was no useful information, it was just a stub. Furthermore, headers are not a thing, they are just a part of a block... --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 21:03, 5 September 2014 (UTC)

== deep web ==

Luke-jr, bitcoin and deep web is closely related, as I previosly said... Your wiki contains bitcoin services as well as hidden wiki, it is only info ( nothing illegal) [[User:TheHiddenWiki|TheHiddenWiki]] ([[User talk:TheHiddenWiki|talk]]) 14:53, 11 September 2014 (UTC)

User talk:Luke-jr

2014-09-11T14:51:42Z

TheHiddenWiki: /* deep web */ new section

Hidden Service

2014-09-11T13:16:16Z

TheHiddenWiki: hidden service

Tor can also provide anonymity to websites and other servers. Servers configured to receive inbound connections only through Tor are called hidden services. Rather than revealing a server's IP address (and thus its network location), a hidden service is accessed through its [[.onion|onion address]]. The Tor network understands these addresses and can route data to and from hidden services, even to those hosted behind firewall or network address translators (NAT), while preserving the anonymity of both parties. Tor is necessary to access hidden services.

Hidden services have been deployed on the Tor network since 2004. Other than the database that stores the hidden-service descriptors, Tor is decentralized by design; there is no direct readable list of all hidden services, although a number of hidden services catalog publicly known onion addresses.

Because hidden services do not use exit nodes, connection to a hidden service is encrypted end-to-end and not subject to eavesdropping. There are, however, security issues involving Tor hidden services. For example, services that are reachable through Tor hidden services ''and'' the public Internet, are susceptible to correlation attacks and thus not perfectly hidden. Other pitfalls include misconfigured services (e.g. identifying information included by default in web server error responses), uptime and downtime statistics, intersection attacks, and user error.
== See also ==

* [[Deep Web]]
* [[The Hidden Wiki]]
* [[Tor]]

User talk:Luke-jr

2014-09-11T12:59:44Z

TheHiddenWiki: /* hidden wiki */ new section

* My comments on [[Tonal Bitcoin]] are not "trolling". They are my opinions, and you can discuss it on the talk page based on the merits. If you delete my comments again from a discuss page, I will ask the administrators to ban your account. That is not acceptable wikipedia behavior [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]])

== Thanks for helping on the [[Heaven Sent Gaming]] article. ==

The bias was sloppy copyediting on my part, thanks for fixing it. [[User:Anon y Mouse|Anon y Mouse]] ([[User talk:Anon y Mouse|talk]]) 10:55, 24 August 2014 (UTC)

== Headers ==

Hi Luke, can you restore the [[Headers]] article please? It was useful for finding information about headers, and it's not obvious where people need to go without this reference article. There's already an article for [[block]]s, so I don't see why you needed to delete this, since it was useful.

: There was no useful information, it was just a stub. Furthermore, headers are not a thing, they are just a part of a block... --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 21:03, 5 September 2014 (UTC)

== hidden wiki ==

Hi, deep web and bitcoin is very close related. Original wikipedia contains a lot information about hidden services of deep web... Your wiki is more closely related to deep web and it's normal to keep articles about it on your wiki [[User:TheHiddenWiki|TheHiddenWiki]] ([[User talk:TheHiddenWiki|talk]]) 12:59, 11 September 2014 (UTC)