https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Belcher&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-19T07:53:06ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Brainwallet&diff=69305Brainwallet2022-05-29T18:02:38Z<p>Belcher: /* Worked Example */ The correct name for this technique is the method of loci</p>
<hr />
<div>A '''brainwallet''' refers to the concept of storing Bitcoins in one's own mind by memorizing a [[seed phrase]]. If the seed is not recorded anywhere, the Bitcoins can be thought of as being held only in the mind of the owner. If a brainwallet is forgotten or the person dies or is permanently incapacitated, the Bitcoins are lost forever. Using memory techniques allow them to be memorized and recalled easily.<br />
<br />
To create a brainwallet, use Bitcoin wallet software to generate a seed phrase and then memorize it. Such seeds are generated by wallets like [[Electrum]], [[Armory]] and [[Mycelium]].<br />
<br />
Brainwallets are not recommended to be used in general because of fallible human memory. But in special situations they could be very useful, for example when fleeing a country as a refugee with only the clothes on your back.<br />
<br />
== Worked Example ==<br />
<br />
# Run [[Electrum]] and use it to generate a [[seed phrase]].<br />
# Memorize the phrase using https://en.wikipedia.org/wiki/Method_of_loci<br />
# When spending or saving, restore the wallet from memory using the phrase.<br />
<br />
=== Example memory palace technique ===<br />
To memorize a seed with this method you must invent a story which hits the words as "keynotes". The story should involve you in your imagination walking through a place very familiar to you, such as your childhood home. Try to make it like a fairy tale story, use imagery. Make it somehow striking and emotionally resonant. When remembering you just remember the key words, not all the other words - the other can be remembered more as images and thoughts (which are hard to write down)<br />
<br />
Let's say we have this seed:<br />
<br />
witch collapse practice feed shame open despair creek road again ice least<br />
<br />
You'd imagine walking through a building familiar to you, maybe your own home or workplace or school.<br />
<br />
* You imagine looking in the first room and seeing your mother dressed as a '''witch''', playing the jenga boardgame until the tower '''collapses'''.<br />
* You walk to the next room and see your father '''practising''' with a longbow, he shoots a chicken to '''feeds''' himself.<br />
* In the next room you see your brother naked in '''shame''' attempting to cover himself, he's looking through a window that's '''open''' and flapping in the wind.<br />
* Now you reach the kitchen, girlfriend is looking at Picasso's [https://en.wikipedia.org/wiki/Guernica_%28Picasso%29 Guernica] on the wall. She is in '''despair''' from it. Next to it is a television playing the show Dawson's '''Creek'''.<br />
* Next you're in the garage, your childhood friend is working on his car. He plans to go on a '''road''' trip for the 5th time this month, he's going '''again'''.<br />
* Finally to go outside to the garden. It's early spring and the ground is covered in melting '''ice'''. Two of your other friends are there, one friend has a huge basket of apples, the other has a smaller basket but you're holding only some apples. You've got the '''least''' apples.<br />
<br />
Repeat this story in your head several times over a short period - the first few days. It will sink in, deep, after that. You'll only have to revisit it very occasionally. After a while you can ignore it for months and it'll still come back, not that I'd recommend relying on that.<br />
<br />
=== Video Example of the Memory Loci Method ===<br />
<br />
From the BBC documentary The Human Mind (2003) by Professor Robert Winston. Approximately 31 minutes in. Memorizing a list of 30 random words.<br />
<br />
https://www.youtube.com/watch?v=lRhfQCW1f68&t=1867<br />
<br />
=== Fallible Memory Warning ===<br />
Despite the memory aids, human memory can be very fallible. So if your only storage is memory you may find that it just vanished one day.<br />
<br />
Data should always be backed up. Storing a seed phrase in one place is bad, even if that one place is your brain.<br />
<br />
== Obsolete Brainwallet Style ==<br />
<br />
An early old-style brainwallet was created by by memorization of a passphrase and converting it a [[private key]] with a hashing or key derivation algorithm (example: SHA256). That private key is then used to compute a Bitcoin address. This method was found to be very insecure and '''should not be used'''. Humans are not a good source of entropy. Using a single address also has problems associated with [[address reuse]].<br />
<br />
=== Low Entropy from Human-Generated Passphrases ===<br />
<br />
Practically everyone who knows about or cares loudly yells at people DO NOT USE BRAINWALLETS [GENERATED BY HUMANS]. We've seen pretty concrete evidence that users are resistant to good advice in this space, and they are shocked when their favorite quotation is cracked and they lose their coins (But it was 60 characters long! I even added a special character! how is this possible?!), the existing sites promoting this stuff won't use a KDF stronger than SHA256*1 because "users are stupid if they use weak passwords". <ref>[https://bitcointalk.org/index.php?topic=311000.msg3345309#msg3345309 Re: hardening brain-wallets with a useful blind proof of work ]</ref><br />
<br />
=== Ryan Castellucci DEFCON Talk === <br />
<br />
Ryan Castellucci gave a talk at DEFCON23 about cracking brainwallet passphrases. Although brainwallet passphrases were being exploited for years by this point, the talk helped bring the issues to more popular consciousness.<ref>[https://rya.nc/cracking_cryptocurrency_brainwallets.pdf Ryan Castellucci DEFCON Talk]</ref><ref>[https://www.reddit.com/r/Bitcoin/comments/3g9f1s/why_im_releasing_a_brainwallet_cracker_at_defcon/ Reddit thread on Ryan's talk]</ref><ref>[https://www.youtube.com/watch?v=foil0hzl4Pg a video of Ryan's talk]</ref><br />
<br />
=== Legacy Code ===<br />
<br />
If you have coins in an old-style brainwallet, the website http://www.bitaddress.org/ contains a GUI for generating the private key using the sha256(passphrase) algorithm. It's highly recommended you move the coins out as soon as you can.<br />
<br />
=References=<br />
<references><br />
</references><br />
<br />
[[Category:Instructional]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Spam_transactions&diff=69224Spam transactions2022-03-05T21:24:44Z<p>Belcher: Add outdated tag</p>
<hr />
<div>{{outdated}}<br />
Spam transactions are transactions which create undesirable extra load on the network due to not following Bitcoin best practices, either maliciously or out of ignorance. Even the very first versions of the Bitcoin software had some spam filtering rules, and these have been improved over time, but it is probably impossible to automatically filter ''all'' spam.<br />
<br />
Transaction spam is always more costly to the spammer than not spamming. Someone who is intentionally spamming the network will have to burn BTC constantly to do so, and so will eventually be forced to stop.<br />
<br />
The most common types of spam are:__NOTOC__<br />
<br />
==== Sending many without sendmany ====<br />
<br />
If you want to send payments to many people at around the same time, then you should not do tons of individual transactions one after the other. Doing so is grossly wasteful of network resources because each transactions produces a extraneous change output. Instead, all of the outgoing transactions should be bundled into one transaction. The bitcoind JSON-RPC command for doing this is <tt>sendmany</tt>.<br />
<br />
==== Signalling and data transmission ====<br />
<br />
Bitcoin is for storing & transferring value between people, and for limited hash-based timestamping. Transactions should never be used as a signal (such as a win/loss signal in a gambling game) or to send data directly.<br />
<br />
==== Useless transactions ====<br />
<br />
Attackers will sometimes waste network resources by sending BTC between their own addresses uselessly.<br />
<br />
==== Very-low-fee flooding ====<br />
<br />
A simplistic attack that people often try is to send tens of thousands of zero- or very-low-fee transactions at once. This makes the "mempool" number shown by some websites go up massively, which sometimes causes people to panic, but in reality it is only a slight drain on the network's bandwidth resources, and hardly a problem at all. Transactions with very low fees will never be confirmed, and will typically be expired from nodes' mempools after a few days.<br />
<br />
[[Category:Vocabulary]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Template:MainPage_Reasons&diff=69176Template:MainPage Reasons2022-01-24T15:04:54Z<p>Belcher: Reword to use "seed phrase" instead of privkey, as ordinary users shouldnt be touching privkeys</p>
<hr />
<div>Bitcoin is P2P electronic cash that is valuable over legacy systems because of the monetary autonomy it brings to its users. Bitcoin seeks to address the root problem with conventional currency: all the trust that's required to make it work -- Not that justified trust is a bad thing, but trust makes systems brittle, opaque, and costly to operate. Trust failures result in systemic collapses, trust curation creates inequality and monopoly lock-in, and naturally arising trust choke-points can be abused to deny access to due process. Through the use of cryptographic proof, decentralized networks and open source software Bitcoin minimizes and replaces these trust costs.<br />
<br />
* Bitcoin [[Transactions]] are:<br />
** '''Permissionless''' and '''borderless'''. The software can be installed by anybody worldwide.<br />
** '''Anonymous'''. Bitcoin does not require any ID to use making it suitable for the unbanked, the privacy-conscious, computers or people in areas with underdeveloped financial infrastructure.<br />
** '''Private'''. When used with care bitcoin can support [[Privacy|strong financial privacy]].<br />
** '''Censorship-resistant'''. Nobody is able to block or freeze a transaction of any amount.<br />
** '''Fast'''. Transactions can be made almost as fast as data can travel over the Internet.<br />
** '''Cheap'''. Fees can be [[Lightning Network|very very low]].<br />
** [[Irreversible Transactions|'''Irreversible''']] once settled, like cash. (but [[Myths#Bitcoin_has_no_built-in_chargeback_mechanism_and_this_is_bad|consumer protection is still possible]].)<br />
** Online and available '''24 hours a day, 365 days per year'''.<br />
<br />
Bitcoin can also be a [[Bitcoin as an investment|store of value]], some have said it is a "swiss bank account in your pocket".<br />
* Stored Bitcoins:<br />
** Cannot be printed or debased. '''Only [[Controlled supply|21 million bitcoins]] will ever exist'''.<br />
** Have '''no storage costs'''. They take up no physical space regardless of amount.<br />
** Are '''easy to protect and hide'''. Can be stored on a phone, computer, encrypted on a [[Storing bitcoins|paper backup]] or [[Brainwallet|memorized in your head]].<br />
** '''No counterparty risk'''. If you keep the [[seed phrase]] of a bitcoin wallet secret and the transaction has enough [[confirmation|confirmations]], then nobody can take them from you no matter for what reason, no matter how good the excuse, no matter what.<br />
** Can be under '''divided possession''' with [[Multisignature]]. For example with a 2-of-3 multisig scheme there would be ''three'' private keys, of which ''any two'' is enough to spend the money. Those three keys can be spread anywhere, perhaps in multiple locations or known by multiple people. No other asset does this, for example you cannot hold gold coins under multisig.</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68934Privacy2021-10-06T16:01:11Z<p>Belcher: /* Forced address reuse */ Write about payments to addresses for which the coins are still unspent</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use these ''forced payments'' as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]] and thereby leak more privacy-relevant information. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
If the forced-payment coins have landed on already-used ''empty'' addresses, then the correct behaviour by wallets is to not spend those coins ever. If the coins have landed on addresses which are not empty, then the correct behaviour by wallets is to fully-spend all the coins on that address in the same transaction.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Another option is to spend the coins individual directly to miner fees. Here are instructions for how to do this with Electrum or Bitcoin Core: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
{{Main|PayJoin}}<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
{{Main|Confidential transactions}}<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. StonewallX2 is a scheme that creates transactions that are identical to Stonewall but involve two participants, making it an actual [[CoinJoin]] transaction. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Mixing_service&diff=68918Mixing service2021-09-21T13:51:21Z<p>Belcher: </p>
<hr />
<div>{{outdated}}Using bitcoins is a flawed way to stay [[Anonymity|anonymous]] while making your purchases, donations, and p2p payments. 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.<br />
<br />
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.<br />
<br />
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]].<br />
<br />
==See Also==<br />
<br />
* [[Anonymity]]<br />
* [[:Category:Mixing Services]]<br />
<br />
<br />
<br />
{{wp|Cryptocurrency_tumbler}}<br />
<br />
[[Category:Financial]]<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Mixing_service&diff=68917Mixing service2021-09-21T13:50:30Z<p>Belcher: </p>
<hr />
<div>{{outdated}}Using bitcoins is a flawed way to stay [[anonymous]] while making your purchases, donations, and p2p payments. 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.<br />
<br />
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.<br />
<br />
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]].<br />
<br />
==See Also==<br />
<br />
* [[Anonymity]]<br />
* [[:Category:Mixing Services]]<br />
<br />
<br />
<br />
{{wp|Cryptocurrency_tumbler}}<br />
<br />
[[Category:Financial]]<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Mixing_service&diff=68916Mixing service2021-09-21T13:49:12Z<p>Belcher: Reverted edits by Aapachi (talk) to last revision by Belcher</p>
<hr />
<div>{{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.<br />
<br />
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.<br />
<br />
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]].<br />
<br />
==See Also==<br />
<br />
* [[Anonymity]]<br />
* [[:Category:Mixing Services]]<br />
* [http://www.bitcoin.org/smf/index.php?topic=2893.0 RFC: Bitcoin Mixnet]<br />
<br />
<br />
<br />
{{wp|Cryptocurrency_tumbler}}<br />
<br />
[[Category:Financial]]<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=CoinJoin&diff=68914CoinJoin2021-09-21T13:49:03Z<p>Belcher: Reverted edits by Aapachi (talk) to last revision by Apirone.com</p>
<hr />
<div>'''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.<br />
<br />
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.<br />
<br />
==Motivation==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Concept==<br />
<br />
The idea is very simple, first some quick background:<br />
<br />
[[Image:Twotx.png|class=fullwidth]]<br />
<br />
A Bitcoin transaction consumes one or more inputs and creates one or more outputs with specified values.<br />
<br />
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).<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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?]]<br />
<br />
In the illustration 'transaction 2' spends coins which were assigned to 1A1 and 1C3. So 1A1 and 1C3 are necessarily the same party?<br />
<br />
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:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Example==<br />
<br />
An example 2-party coinjoin transaction. https://chain.localbitcoins.com/tx/c38aac9910f327700e0f199972eed8ea7c6b1920e965f9cb48a92973e7325046<br />
The outputs to addresses 1MUzngtNnrQRXRqqRTeDmpULW8X1aaGWeR and 1Fufjpf9RM2aQsGedhSpbSCGRHrmLMJ7yY are coinjoined because they are both of value 0.01btc.<br />
<br />
Another example is this 3-party coinjoin. https://chain.localbitcoins.com/tx/92a78def188053081187b847b267f0bfabf28368e9a7a642780ce46a78f551ba<br />
<br />
==FAQ==<br />
<br />
===Don't you need tor or something to prevent everyone from learning everyone's IP?===<br />
<br />
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)<br />
<br />
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.<br />
<br />
===Don't the users learn which inputs match up to which outputs?===<br />
<br />
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.<br />
<br />
More complicated implementations are possible where even the server doesn't learn the mapping.<br />
<br />
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.<br />
<br />
Similar things can be accomplished with various zero-knowledge proof systems.<br />
<br />
===Does the totally private version need to have a server at all? What if it gets shut down?===<br />
<br />
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.<br />
<br />
===What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Isn't the anonymity set size limited by how many parties you can get in a single transaction?===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===How does this compare to [http://zerocoin.org/ zerocoin]?===<br />
<br />
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.<br />
<br />
Zerocoin has a number of serious limitations: <br />
* 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).<br />
* It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).<br />
* It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
Some of these things may improve significantly with better math and software engineering over time.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
(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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
===How does this compare to [https://bitcointalk.org/index.php?topic=277389.0 CoinWitness]?===<br />
<br />
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.<br />
<br />
===Sounds great! Where is it?===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==See Also==<br />
* [[User:Gmaxwell/state_of_coinjoin]]<br />
* [[Common-input-ownership heuristic]]<br />
* [[JoinMarket]]<br />
<br />
==References==<br />
<references><br />
</references><br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Seed_phrase&diff=68800Seed phrase2021-07-17T08:00:44Z<p>Belcher: Add warning about sample keys</p>
<hr />
<div>{{sample}}<br />
<br />
A '''seed phrase''', '''seed recovery phrase''' or '''backup seed phrase''' is a list of words which [[Storing bitcoins|store]] all the information needed to recover Bitcoin funds [[Transaction|on-chain]]. Wallet software will typically generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to get their bitcoins back.<br />
<br />
Anybody else who discovers the phrase can steal the bitcoins, so it must be kept safe like jewels or cash. For example, it must not be typed into any website.<br />
<br />
Seed phrases are an excellent way of backing up and [[storing bitcoins]], so they are used by almost all well-regarded wallets.<ref>[https://bitcoin.org/en/choose-your-wallet Bitcoin.org: Choose your wallet]</ref><br />
<br />
Seed phrases can only backups funds on the [[block chain]]. They cannot store funds involved in [[off-chain transactions]] such as [[Lightning Network]] or [[Blinded bearer certificates]]. Although these technologies are in their infancy as of 2019 so its possible in future seed phrases could be used to backup them.<br />
<br />
== BIP39 and its flaws ==<br />
<br />
[[BIP_0039|BIP39]] is the most common standard used for seed phrases. One notable example is [[Electrum|Electrum wallet]], which is using its own standard, and for good reasons. BIP39 has some flaws, known in the technical community but not known much wider. They are described [https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation here on this electrum doc page]. Most seriously, BIP39 flaws mean it is not true to say that backing up a BIP39 seed phrase and name of wallet software is the only thing a user needs to do to keep their money safe. BIP39 works this way because its designers wanted their hardware wallet to also support [[altcoin]]s. [https://walletsrecovery.org/ walletsrecovery.org] is an attempt at helping with this issue, but ideally there will be a better solution in the future.<br />
<br />
<br />
== Example ==<br />
<br />
An example of a non-BIP39 seed phrase is:<br />
<br />
witch collapse practice feed shame open despair {{taggant private key}}creek road again ice least<br />
<br />
The word order is important.<br />
<br />
[[File:Mnemonic-seed-still-life.jpg|300px|thumb|none|alt=An example seed phrase written on paper|Example seed phrase on paper.]]<br />
<br />
== Explanation ==<br />
<br />
A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The seed phrase can be converted to a number which is used as the seed integer to a [[Deterministic wallet|deterministic wallet]] that generates all the [[Private key|key pairs]] used in the wallet.<br />
<br />
The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,<ref>[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic BIP39: Generating the mnemonic]</ref> so the actual security of a 12-word BIP39 seed phrase is only 128 bits. This is approximately the same strength as all Bitcoin private keys, so most experts consider it to be sufficiently secure.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Security BIP32: Security]</ref><br />
<br />
It is not safe to invent your own seed phrase because humans are bad at generating randomness. The best way is to allow the wallet software to generate a phrase which you write down.<br />
<br />
As seed phrases use natural language words, they have excellent error correction. Words written in bad handwriting can often still be read. If one or two letters are missing or unreadable the word can often still be deduced. The [[#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it. This compares well with writing down a raw [[private key]] where a single letter being unreadable or incorrect can make the private key useless (depending on the serialization format).<br />
<br />
== Two-factor seed phrases ==<br />
<br />
Seed phrases, like all backups, can store any amount of bitcoins. It's a concerning idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password.<br />
<br />
The password can be used to create a two-factor seed phrase where both ''"something you have"'' plus ''"something you know"'' is required to unlock the bitcoins.<br />
<br />
This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. Electrum and some other wallets call the passphrase a '''"seed extension"''', '''"extension word"''' or '''"13th/25th word"'''. The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum standard. If a passphrase is not present, an empty string "" is used instead.<br />
<br />
'''Warning''': Forgetting this password will result in the bitcoin wallet and any contained money being lost. Do not overestimate your ability to remember passphrases especially when you may not use it very often.<br />
<br />
'''Warning''': The seed phrase password should not be confused with the password used to encrypt the wallet file on disk. This is probably why many wallets call it an extension word instead of a password.<br />
<br />
== Storing seed phrases for the long term == <br />
<br />
Most people write down phrases on paper but they can be stored in many other ways such as [[Brainwallet|memorizing]], engraving or stamping on metal, writing in the margins of a book, chiselling into a stone tablet or any other creative and inventive way.<br />
<br />
In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, or corrupted SSD devices. It's also important to protect the seed from accidental loss.<br />
<br />
It could be a good idea to write some words of explanation on the same paper as the seed phrase. If storing for the long term you may forget what a phrase is how it should be treated. A sample explanation that can be adapted is:<br />
<br />
<blockquote>These twelve words have control over BITCOINS. Keep this paper safe and secret like cash or jewellery. The bitcoin information on this paper is encrypted with a passphrase. It is part of a multi-signature wallet and was made by Electrum bitcoin wallet software on 2019-01-01.</blockquote><br />
<br />
==== Paper and pencil backup ====<br />
<br />
Through bitter experience it has been found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.<br />
<br />
For storing on paper writing with pencil is much better than pen<br />
<ref>[http://www.joethorn.net/blog/2011/12/07/pencil-does-not-fade Pencil Does Not Fade]<br />
</ref><ref>[https://www.quora.com/How-do-I-maintain-a-paper-notebook-that-can-remain-for-years How do I maintain a paper notebook that can remain for years?]<br />
</ref>.<br />
Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture<br />
<ref>[https://www.loc.gov/preservation/care/deterioratebrochure.html Essential facts about preservation of Paper]<br />
</ref><ref>[https://www.quora.com/If-I-write-with-a-pencil-on-my-notebook-will-the-writing-last-for-a-long-time-say-50-years-or-will-it-just-fade-away-gradually Writing in a notebook with pencil]<br />
</ref><ref>[http://copar.org/bulletin14.htm CoPAR: Creating records that will last]</ref>.<br />
<br />
==== Metal backup ====<br />
<br />
Seed phrases can also be [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ stamped or engraved into metal] which is significantly more durable than paper. Metal backups are recommended if the threat model involves fire, water, extremes of temperature or physical stress.<br />
<br />
==== Methods that are not recommended ====<br />
<br />
Some methods that are not recommended are: storing in a file on a computer (including online), or storing online.<br />
<br />
Some people get the idea to split up their phrases, like storing 6 words in one location and the other 6 words in another location. This is a bad idea and should not be done, because if one set of 6 words is discovered then it becomes far easier to brute-force the rest of the phrase. Storing bitcoins in multiple locations like this should be done with [[multi-signature]] wallets instead.<br />
<br />
The [[Shamir Secret Sharing]] algorithm is sometimes promoted as a way to divide control of bitcoins, but in practice there are many pitfalls and trade-offs that make it not worth it.<ref>[https://blog.keys.casa/shamirs-secret-sharing-security-shortcomings/ Shamir's Secret Sharing Shortcomings] by Jameson Lopp, Casa blog, 2020</ref> <!-- See the main article: [[Shamir Secret Snakeoil]] (the other one redirects here, no need to have 2 wikilinks with different captions going to the same article --><br />
<br />
Another bad idea is to add random decoy words that are somehow meaningful to you and later remove them to be left with only the 12-word phrase. The phrase words come from a known dictionary (see next section), so anybody can use that dictionary to weed out the decoy words.<br />
<br />
It's possible but risky to memorize ([[Brainwallet]]s) seed phrases. This should probably only be done in situations that really need it, such as crossing a hostile border where one expects to be searched.<br />
<br />
== Word lists ==<br />
<br />
Generally, a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.<br />
<br />
The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md BIP39 wordlists]<br />
* [https://github.com/spesmilo/electrum/blob/1.9.8/lib/mnemonic.py Electrum old-style wordlist]<br />
* [https://github.com/spesmilo/electrum/blob/master/electrum/wordlist/english.txt Electrum new-style wordlist]<br />
<br />
== Alternative name "mnemonic phrase" ==<br />
<br />
Seed phrases are sometimes called ''mnemonic phrases'', especially in older literature. This is a bad name because the word "mnemonic" implies that the phrase should be memorized. It is less misleading to call them seed phrases.<br />
<br />
== The power of backups ==<br />
<br />
An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. At the London Inside Bitcoin conference, the keynote speaker showed 25 paper backups they were carrying&mdash;all password-protected. With that, one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen, then there is no risk because it is backed up elsewhere. That is powerful.<ref>https://www.reddit.com/r/Bitcoin/comments/2hmnru/poll_do_you_use_paper_wallets_why_why_not_what/</ref><br />
<br />
== See also ==<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP39 seed phrase standard]<br />
* [[Deterministic wallet]]<br />
* [[Storing bitcoins]]<br />
* [[Brainwallet]]<br />
* [https://github.com/6102bitcoin/FAQ/blob/master/seed.md FAQ regarding bitcoin seeds]<br />
* [https://www.hodlalert.com/2020/12/21/generating-cryptographically-secure-random-numbers-with-coins-and-a-cup/ Generating Bitcoin Seed Phrases With Coins and A Cup]<br />
<br />
==References==<br />
<references /><br />
<br />
<br />
[[Category:Technical]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Seed_phrase&diff=68799Seed phrase2021-07-17T07:57:41Z<p>Belcher: /* Example */ Add {{taggant private key}} to the seed phrase</p>
<hr />
<div>A '''seed phrase''', '''seed recovery phrase''' or '''backup seed phrase''' is a list of words which [[Storing bitcoins|store]] all the information needed to recover Bitcoin funds [[Transaction|on-chain]]. Wallet software will typically generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to get their bitcoins back.<br />
<br />
Anybody else who discovers the phrase can steal the bitcoins, so it must be kept safe like jewels or cash. For example, it must not be typed into any website.<br />
<br />
Seed phrases are an excellent way of backing up and [[storing bitcoins]], so they are used by almost all well-regarded wallets.<ref>[https://bitcoin.org/en/choose-your-wallet Bitcoin.org: Choose your wallet]</ref><br />
<br />
Seed phrases can only backups funds on the [[block chain]]. They cannot store funds involved in [[off-chain transactions]] such as [[Lightning Network]] or [[Blinded bearer certificates]]. Although these technologies are in their infancy as of 2019 so its possible in future seed phrases could be used to backup them.<br />
<br />
== BIP39 and its flaws ==<br />
<br />
[[BIP_0039|BIP39]] is the most common standard used for seed phrases. One notable example is [[Electrum|Electrum wallet]], which is using its own standard, and for good reasons. BIP39 has some flaws, known in the technical community but not known much wider. They are described [https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation here on this electrum doc page]. Most seriously, BIP39 flaws mean it is not true to say that backing up a BIP39 seed phrase and name of wallet software is the only thing a user needs to do to keep their money safe. BIP39 works this way because its designers wanted their hardware wallet to also support [[altcoin]]s. [https://walletsrecovery.org/ walletsrecovery.org] is an attempt at helping with this issue, but ideally there will be a better solution in the future.<br />
<br />
<br />
== Example ==<br />
<br />
An example of a non-BIP39 seed phrase is:<br />
<br />
witch collapse practice feed shame open despair {{taggant private key}}creek road again ice least<br />
<br />
The word order is important.<br />
<br />
[[File:Mnemonic-seed-still-life.jpg|300px|thumb|none|alt=An example seed phrase written on paper|Example seed phrase on paper.]]<br />
<br />
== Explanation ==<br />
<br />
A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The seed phrase can be converted to a number which is used as the seed integer to a [[Deterministic wallet|deterministic wallet]] that generates all the [[Private key|key pairs]] used in the wallet.<br />
<br />
The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,<ref>[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic BIP39: Generating the mnemonic]</ref> so the actual security of a 12-word BIP39 seed phrase is only 128 bits. This is approximately the same strength as all Bitcoin private keys, so most experts consider it to be sufficiently secure.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Security BIP32: Security]</ref><br />
<br />
It is not safe to invent your own seed phrase because humans are bad at generating randomness. The best way is to allow the wallet software to generate a phrase which you write down.<br />
<br />
As seed phrases use natural language words, they have excellent error correction. Words written in bad handwriting can often still be read. If one or two letters are missing or unreadable the word can often still be deduced. The [[#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it. This compares well with writing down a raw [[private key]] where a single letter being unreadable or incorrect can make the private key useless (depending on the serialization format).<br />
<br />
== Two-factor seed phrases ==<br />
<br />
Seed phrases, like all backups, can store any amount of bitcoins. It's a concerning idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password.<br />
<br />
The password can be used to create a two-factor seed phrase where both ''"something you have"'' plus ''"something you know"'' is required to unlock the bitcoins.<br />
<br />
This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. Electrum and some other wallets call the passphrase a '''"seed extension"''', '''"extension word"''' or '''"13th/25th word"'''. The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum standard. If a passphrase is not present, an empty string "" is used instead.<br />
<br />
'''Warning''': Forgetting this password will result in the bitcoin wallet and any contained money being lost. Do not overestimate your ability to remember passphrases especially when you may not use it very often.<br />
<br />
'''Warning''': The seed phrase password should not be confused with the password used to encrypt the wallet file on disk. This is probably why many wallets call it an extension word instead of a password.<br />
<br />
== Storing seed phrases for the long term == <br />
<br />
Most people write down phrases on paper but they can be stored in many other ways such as [[Brainwallet|memorizing]], engraving or stamping on metal, writing in the margins of a book, chiselling into a stone tablet or any other creative and inventive way.<br />
<br />
In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, or corrupted SSD devices. It's also important to protect the seed from accidental loss.<br />
<br />
It could be a good idea to write some words of explanation on the same paper as the seed phrase. If storing for the long term you may forget what a phrase is how it should be treated. A sample explanation that can be adapted is:<br />
<br />
<blockquote>These twelve words have control over BITCOINS. Keep this paper safe and secret like cash or jewellery. The bitcoin information on this paper is encrypted with a passphrase. It is part of a multi-signature wallet and was made by Electrum bitcoin wallet software on 2019-01-01.</blockquote><br />
<br />
==== Paper and pencil backup ====<br />
<br />
Through bitter experience it has been found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.<br />
<br />
For storing on paper writing with pencil is much better than pen<br />
<ref>[http://www.joethorn.net/blog/2011/12/07/pencil-does-not-fade Pencil Does Not Fade]<br />
</ref><ref>[https://www.quora.com/How-do-I-maintain-a-paper-notebook-that-can-remain-for-years How do I maintain a paper notebook that can remain for years?]<br />
</ref>.<br />
Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture<br />
<ref>[https://www.loc.gov/preservation/care/deterioratebrochure.html Essential facts about preservation of Paper]<br />
</ref><ref>[https://www.quora.com/If-I-write-with-a-pencil-on-my-notebook-will-the-writing-last-for-a-long-time-say-50-years-or-will-it-just-fade-away-gradually Writing in a notebook with pencil]<br />
</ref><ref>[http://copar.org/bulletin14.htm CoPAR: Creating records that will last]</ref>.<br />
<br />
==== Metal backup ====<br />
<br />
Seed phrases can also be [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ stamped or engraved into metal] which is significantly more durable than paper. Metal backups are recommended if the threat model involves fire, water, extremes of temperature or physical stress.<br />
<br />
==== Methods that are not recommended ====<br />
<br />
Some methods that are not recommended are: storing in a file on a computer (including online), or storing online.<br />
<br />
Some people get the idea to split up their phrases, like storing 6 words in one location and the other 6 words in another location. This is a bad idea and should not be done, because if one set of 6 words is discovered then it becomes far easier to brute-force the rest of the phrase. Storing bitcoins in multiple locations like this should be done with [[multi-signature]] wallets instead.<br />
<br />
The [[Shamir Secret Sharing]] algorithm is sometimes promoted as a way to divide control of bitcoins, but in practice there are many pitfalls and trade-offs that make it not worth it.<ref>[https://blog.keys.casa/shamirs-secret-sharing-security-shortcomings/ Shamir's Secret Sharing Shortcomings] by Jameson Lopp, Casa blog, 2020</ref> <!-- See the main article: [[Shamir Secret Snakeoil]] (the other one redirects here, no need to have 2 wikilinks with different captions going to the same article --><br />
<br />
Another bad idea is to add random decoy words that are somehow meaningful to you and later remove them to be left with only the 12-word phrase. The phrase words come from a known dictionary (see next section), so anybody can use that dictionary to weed out the decoy words.<br />
<br />
It's possible but risky to memorize ([[Brainwallet]]s) seed phrases. This should probably only be done in situations that really need it, such as crossing a hostile border where one expects to be searched.<br />
<br />
== Word lists ==<br />
<br />
Generally, a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.<br />
<br />
The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md BIP39 wordlists]<br />
* [https://github.com/spesmilo/electrum/blob/1.9.8/lib/mnemonic.py Electrum old-style wordlist]<br />
* [https://github.com/spesmilo/electrum/blob/master/electrum/wordlist/english.txt Electrum new-style wordlist]<br />
<br />
== Alternative name "mnemonic phrase" ==<br />
<br />
Seed phrases are sometimes called ''mnemonic phrases'', especially in older literature. This is a bad name because the word "mnemonic" implies that the phrase should be memorized. It is less misleading to call them seed phrases.<br />
<br />
== The power of backups ==<br />
<br />
An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. At the London Inside Bitcoin conference, the keynote speaker showed 25 paper backups they were carrying&mdash;all password-protected. With that, one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen, then there is no risk because it is backed up elsewhere. That is powerful.<ref>https://www.reddit.com/r/Bitcoin/comments/2hmnru/poll_do_you_use_paper_wallets_why_why_not_what/</ref><br />
<br />
== See also ==<br />
<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP39 seed phrase standard]<br />
* [[Deterministic wallet]]<br />
* [[Storing bitcoins]]<br />
* [[Brainwallet]]<br />
* [https://github.com/6102bitcoin/FAQ/blob/master/seed.md FAQ regarding bitcoin seeds]<br />
* [https://www.hodlalert.com/2020/12/21/generating-cryptographically-secure-random-numbers-with-coins-and-a-cup/ Generating Bitcoin Seed Phrases With Coins and A Cup]<br />
<br />
==References==<br />
<references /><br />
<br />
<br />
[[Category:Technical]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68716Privacy2021-07-03T13:14:37Z<p>Belcher: /* Confidential transactions */ Typo</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' or '''incentivized [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use the payments as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]]. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
The correct behaviour by wallets is to not spend coins that have landed on an already-used empty addresses.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Another option is to spend the coins individual directly to miner fees. Here are instructions for how to do this with Electrum or Bitcoin Core: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
{{Main|PayJoin}}<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
{{Main|Confidential transactions}}<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68715Privacy2021-07-03T13:12:56Z<p>Belcher: /* PayJoin */ Add link to main article payjoin</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' or '''incentivized [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use the payments as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]]. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
The correct behaviour by wallets is to not spend coins that have landed on an already-used empty addresses.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Another option is to spend the coins individual directly to miner fees. Here are instructions for how to do this with Electrum or Bitcoin Core: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
{{Main|PayJoin}}<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
Main article: [[Confidential transactions]]<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Fee_sniping&diff=68703Fee sniping2021-06-16T18:29:50Z<p>Belcher: Add link to bitcoinops page about fee sniping</p>
<hr />
<div>'''Fee sniping''' is a hypothetical outcome of bad incentives to bitcoin mining in the [[Controlled supply|low-inflation future]].<br />
<br />
For a large miner the value of the transactions in the best block and the mempool can be exceeded by the cost of deliberately attempting to mine two blocks to orphan the best block. However with anti-fee-sniping protection using [[NLockTime|nLockTime]] or [[NSequence|nSequence]] the bad miner will soon run out of transactions that can be put in the first block, which means they now need to go in the second. Anti-fee-sniping adds to the incentive to move the blockchain forward.<br />
<br />
The [[NLockTime|nLockTime]] field is being used this way today. It is implemented in [[Bitcoin Core]]<ref>https://github.com/bitcoin/bitcoin/pull/2340</ref> and [[Electrum]]<ref>https://github.com/spesmilo/electrum/blob/7e6d65ec11c0dccfc24478471c5951d3ae586937/electrum/wallet.py#L211-L224</ref>, and adopted by approximately 20% of all transactions<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of 2021.<br />
<br />
As of 2021 the subsidy is high enough, and transaction volume low enough, that fee sniping isn't a problem yet, but by implementing a fix now we ensure code won't be written that makes assumptions about [[NLockTime|nLockTime]] that preclude a fix later.<br />
<br />
The widespread use of [[NLockTime|nLockTime]] and [[NSequence|nSequence]] also provides a greater anonymity set for transactions which use these fields to implement [[Contract|smart contracts]]. For example if an observer of the [[blockchain|block chain]] sees a spend with an [[NSequence|nSequence]] value, then that could be either: a regular spend from a wallet, or the [[timelock]] branch of an [[Off-chain transactions|off-chain settlement transaction]]. The two cases would be indistinguishable, and this could greatly improve the [[privacy]] and [[fungibility]] of bitcoin.<br />
<br />
== See Also ==<br />
* https://bitcoinops.org/en/topics/fee-sniping/<br />
<br />
==References==<br />
<references /><br />
[[Category:Technical]]<br />
[[Category:Mining]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Timelock&diff=68696Timelock2021-06-10T12:32:26Z<p>Belcher: /* CheckLockTimeVerify */ Fix link</p>
<hr />
<div>A '''Timelock''' is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin [[Contracts|smart contracts]], including [[payment channels]] and [[Hashed Timelock Contracts|hashed timelock contracts]]. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make [[fee sniping]] less profitable, and for [[Techniques_to_reduce_transaction_fees#Pre-computed_fee_bumping|trustless precomputed fee bumping]].<br />
<br />
== Primitives ==<br />
<br />
=== nLockTime ===<br />
<br />
''Main article: [[nLockTime]]''<br />
<br />
In the original Bitcoin release, nodes would not relay nor mine transactions with nLockTime equal to or greater than the current block height (unless all inputs' sequence numbers were 0xffffffff), however they would accept blocks containing transactions with any value of nLockTime. In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-23cfe05393c8433e384d2c385f06ab93R406</ref> Then, starting from block 31001 (December of 2009), the nLockTime restrictions were activated as a rule that also applied to block acceptance.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-118fcbaaba162ba17933c7893247df3aR1222</ref> Later, in July of 2016, the time based locks were changed to operate on the [[median time past]] instead of the block's timestamp.<ref>https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki</ref><br />
<br />
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to <code>0</code>, meaning the transaction was valid in any block. Starting with [[Bitcoin Core]] 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized [[fee sniping]] less profitable<ref name="anti_fee_sniping"/>; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of early-2019.<br />
<br />
=== CheckLockTimeVerify ===<br />
<br />
In late 2015, the BIP65 soft fork<ref name="bip65"/> redefined the NOP2 opcode as the [[CheckLockTimeVerify]] (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CLTV is currently used in [[Payment_channels#CLTV-style_payment_channels|CLTV-style payment channels]].<br />
<br />
=== Relative locktime ===<br />
<br />
In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the [[nSequence]] field<ref name="bip68"/> that is a part of every transaction input, creating a "relative locktime"{{citation needed}}. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.<br />
<br />
=== CheckSequenceVerify ===<br />
<br />
Also part of the BIP68/112/113 soft fork was the [[CheckSequenceVerify]] opcode<ref name="bip112"/>, which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CSV is used by [[Lightning Network]] transactions.<br />
<br />
== Far-future locks ==<br />
<br />
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.<br />
<br />
OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries.<br />
<br />
Occasionally coins have been accidentally locked up for a long time.<ref>https://github.com/OutCast3k/coinbin/issues/35#issuecomment-167440998</ref><br />
<br />
== See Also ==<br />
<br />
* [https://coinb.in/#newTimeLocked coinb.in's time-locked page] javascript page for creating time-locked bitcoin wallets.<br />
* [https://www.reddit.com/r/Bitcoin/comments/4p4klg/bitcoin_core_project_the_csv_soft_fork_has/d4i01he/ Reddit discussion of the possible uses OP_CHECKSEQUENCEVERIFY]<br />
<br />
== References ==<br />
<references><br />
<ref name="bip65">[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]<br>Peter Todd<br>Retrieved 2016-04-12</ref><br />
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]<br>Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona<br>Retrieved 2016-04-12</ref><br />
<ref name="bip112">[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]<br>BtcDrak, Mark Friedenbach, Eric Lombrozo<br>Retrieved 2016-04-12</ref><br />
<ref name="anti_fee_sniping">[https://bitcoin.org/en/release/v0.11.0 Bitcoin Core 0.11.0 release notes]<br>Bitcoin.org<br>Retrieved 2016-11-06</ref><br />
</references><br />
<br />
[[Category:Technical]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Fee_sniping&diff=68695Fee sniping2021-06-10T12:30:41Z<p>Belcher: Reword and add link</p>
<hr />
<div>'''Fee sniping''' is a hypothetical outcome of bad incentives to bitcoin mining in the [[Controlled supply|low-inflation future]].<br />
<br />
For a large miner the value of the transactions in the best block and the mempool can be exceeded by the cost of deliberately attempting to mine two blocks to orphan the best block. However with anti-fee-sniping protection using [[NLockTime|nLockTime]] or [[NSequence|nSequence]] the bad miner will soon run out of transactions that can be put in the first block, which means they now need to go in the second. Anti-fee-sniping adds to the incentive to move the blockchain forward.<br />
<br />
The [[NLockTime|nLockTime]] field is being used this way today. It is implemented in [[Bitcoin Core]]<ref>https://github.com/bitcoin/bitcoin/pull/2340</ref> and [[Electrum]]<ref>https://github.com/spesmilo/electrum/blob/7e6d65ec11c0dccfc24478471c5951d3ae586937/electrum/wallet.py#L211-L224</ref>, and adopted by approximately 20% of all transactions<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of 2021.<br />
<br />
As of 2021 the subsidy is high enough, and transaction volume low enough, that fee sniping isn't a problem yet, but by implementing a fix now we ensure code won't be written that makes assumptions about [[NLockTime|nLockTime]] that preclude a fix later.<br />
<br />
The widespread use of [[NLockTime|nLockTime]] and [[NSequence|nSequence]] also provides a greater anonymity set for transactions which use these fields to implement [[Contract|smart contracts]]. For example if an observer of the [[blockchain|block chain]] sees a spend with an [[NSequence|nSequence]] value, then that could be either: a regular spend from a wallet, or the [[timelock]] branch of an [[Off-chain transactions|off-chain settlement transaction]]. The two cases would be indistinguishable, and this could greatly improve the [[privacy]] and [[fungibility]] of bitcoin.<br />
<br />
<br />
==References==<br />
<references /><br />
[[Category:Technical]]<br />
[[Category:Mining]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Fee_sniping&diff=68694Fee sniping2021-06-10T12:28:34Z<p>Belcher: Create page</p>
<hr />
<div>'''Fee sniping''' is a hypothetical outcome of bad incentives to bitcoin mining in the [[Controlled supply|low-inflation future]].<br />
<br />
For a large miner the value of the transactions in the best block and the mempool can be exceeded by the cost of deliberately attempting to mine two blocks to orphan the best block. However with anti-fee-sniping protection using [[NLockTime|nLockTime]] or [[NSequence|nSequence]] the bad miner will soon run out of transactions that can be put in the first block, which means they now need to go in the second. Anti-fee-sniping adds to the incentive to move the blockchain forward.<br />
<br />
The [[NLockTime|nLockTime]] field is being used this way today. It is implemented in [[Bitcoin Core]]<ref>https://github.com/bitcoin/bitcoin/pull/2340</ref> and [[Electrum]]<ref>https://github.com/spesmilo/electrum/blob/7e6d65ec11c0dccfc24478471c5951d3ae586937/electrum/wallet.py#L211-L224</ref>, and adopted by approximately 20% of all transactions<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of 2021.<br />
<br />
As of 2021 the subsidy is high enough, and transaction volume low enough, that fee sniping isn't a problem yet, but by implementing a fix now we ensure code won't be written that makes assumptions about [[NLockTime|nLockTime]] that preclude a fix later.<br />
<br />
The widespread use of [[NLockTime|nLockTime]] and [[NSequence|nSequence]] also provides a greater anonymity set for transactions which use these fields to implement [[Contract|smart contracts]]. For example if an observer of the [[blockchain|block chain]] sees a spend with an [[NSequence|nSequence]] value, then that could be either: a regular spend from a wallet, or an off-chain settlement transaction spent with a [[timelock]]. The two cases would be indistinguishable, and this could greatly improve the [[privacy]] and [[fungibility]] of bitcoin.<br />
<br />
<br />
==References==<br />
<references /><br />
[[Category:Technical]]<br />
[[Category:Mining]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=NLockTime&diff=68693NLockTime2021-06-10T12:25:32Z<p>Belcher: /* See Also */ Add link to transaction page</p>
<hr />
<div>{{stub}}<br />
<br />
'''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.<br />
<br />
* If <code>nLockTime < 500000000</code><br />
** Specifies the block number after which this transaction can be included in a block.<br />
* Otherwise<br />
** Specifies the UNIX timestamp after which this transaction can be included in a block.<br />
<br />
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]] (the median timestamp of the 11 blocks preceding the block in which the transaction is mined), and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically.<br />
<br />
For transaction relay, nLockTime must be <= the current block's height (block-based) or <= the current median time past (if time based). This ensures that the transaction can be included in the next block.<br />
<br />
==See Also==<br />
* lock_time in [[Protocol_specification#tx|the protocol specification]]<br />
* [[Transaction]]<br />
* [[Timelock]]<br />
* [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP113]<br />
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]<br />
<br />
[[Category:Technical]]<br />
{{lowercase}}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Mystery_shopper_payments&diff=68691Mystery shopper payments2021-06-08T16:11:05Z<p>Belcher: /* Bad privacy example - Receiving donations spied on with mystery shopper payments */ Typo</p>
<hr />
<div>Mystery shopper payments are a class of [[privacy]] attack. A mystery shopper payment is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information.<br />
<br />
For example, if the target is an online merchant then the adversary could buy a small item from the store. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant such as income, turnover, etc. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
Mystery shopper payments are usually used as a starting point and then combined with other privacy attack techniques such as the [[common-input-ownership heuristic]] and change address detection. They work even if [[address reuse]] is avoided.<br />
<br />
Mystery shopper payments can be resisted by awareness of what information is leaked. Care must be taken when spending incoming funds.<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[#Mystery_shopper_payment|mystery shopper payments]] ===<br />
# You want to [[Receiving donations with bitcoin|accept bitcoin donations]] but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs in one transaction, thereby linking them all together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
== See also ==<br />
<br />
* [[Privacy]]<br />
* [[Receiving donations with bitcoin]]<br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Difficulty&diff=68663Difficulty2021-05-13T13:58:23Z<p>Belcher: Add link to good reddit discussion</p>
<hr />
<div>''See also: [[target]]''<br />
<br />
=== What is "difficulty"? ===<br />
<br />
Difficulty is a measure of how difficult it is to find a hash below a given target.<br />
<br />
The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.<br />
Mining pools also have a pool-specific share difficulty setting a lower limit for shares.<br />
<br />
=== How often does the network difficulty change? ===<br />
<br />
Every 2016 [[block|blocks]].<br />
<br />
=== What is the formula for difficulty? ===<br />
<br />
difficulty = difficulty_1_target / current_target <br />
<br />
(target is a 256 bit number)<br />
<br />
difficulty_1_target can be different for various ways to measure difficulty.<br />
Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff").<br />
The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").<br />
<br />
===How is difficulty stored in blocks?===<br />
<br />
Each block stores a packed representation (called "Bits") for its actual hexadecimal [[target]]. The target can be derived from it via a predefined formula. For example, if the packed target in the block is 0x1b0404cb (stored in little-endian order: <code>cb 04 04 1b</code>), the hexadecimal target is<br />
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000<br />
<br />
Note that this packed format contains a sign bit in the 24th bit, and for example the negation of the above target would be 0x1b<b>8</b>404cb in packed format. Since targets are never negative in practice, however, this means the largest legal value for the lower 24 bits is 0x7fffff. Additionally, 0x008000 is the smallest legal value for the lower 24 bits since targets are always stored with the lowest possible exponent.<br />
<br />
===How is difficulty calculated? What is the difference between bdiff and pdiff?===<br />
<br />
The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of<br />
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000<br />
<br />
It should be noted that pooled mining often uses non-truncated targets, which puts "pool difficulty 1" at<br />
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
<br />
So the difficulty at 0x1b0404cb is therefore:<br />
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /<br />
0x00000000000404CB000000000000000000000000000000000000000000000000 <br />
= 16307.420938523983 (bdiff)<br />
And:<br />
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /<br />
0x00000000000404CB000000000000000000000000000000000000000000000000 <br />
= 16307.669773817162 (pdiff)<br />
<br />
Here's a fast way to calculate bitcoin difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:<br />
<br />
<source lang="cpp"><br />
#include <iostream><br />
#include <cmath><br />
<br />
inline float fast_log(float val)<br />
{<br />
int * const exp_ptr = reinterpret_cast <int *>(&val);<br />
int x = *exp_ptr;<br />
const int log_2 = ((x >> 23) & 255) - 128;<br />
x &= ~(255 << 23);<br />
x += 127 << 23;<br />
*exp_ptr = x;<br />
<br />
val = ((-1.0f/3) * val + 2) * val - 2.0f/3;<br />
return ((val + log_2) * 0.69314718f);<br />
} <br />
<br />
float difficulty(unsigned int bits)<br />
{<br />
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);<br />
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));<br />
}<br />
<br />
int main()<br />
{<br />
std::cout << difficulty(0x1b0404cb) << std::endl;<br />
return 0;<br />
}<br />
</source><br />
<br />
To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:<br />
<br />
<source lang="python"><br />
import decimal, math<br />
l = math.log<br />
e = math.e<br />
<br />
print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))<br />
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))<br />
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))<br />
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))<br />
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)<br />
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)<br />
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)<br />
</source><br />
<br />
=== What is the current difficulty? ===<br />
[http://blockexplorer.com/q/getdifficulty Current difficulty], as output by Bitcoin's getDifficulty.<br />
<br />
[http://bitcoin.sipa.be Graphs]<br />
<br />
=== What is the maximum difficulty? ===<br />
<br />
There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).<br />
<br />
The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)<br />
<br />
=== Can the network difficulty go down? ===<br />
Yes it can. See discussion in [[target]].<br />
<br />
=== What is the minimum difficulty? ===<br />
The minimum difficulty, when the target is at the maximum allowed value, is 1.<br />
<br />
=== What network hash rate results in a given difficulty? ===<br />
The difficulty is adjusted every 2016 blocks based on the [[Block_timestamp|time]] it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.<br />
<br />
To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is<br />
0xffff * 2**208<br />
and for difficulty D is<br />
(0xffff * 2**208)/D<br />
<br />
The expected number of hashes we need to calculate to find a block with difficulty D is therefore<br />
D * 2**256 / (0xffff * 2**208)<br />
or just<br />
D * 2**48 / 0xffff<br />
<br />
The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was<br />
D * 2**48 / 0xffff / 600<br />
over the previous 2016 blocks. Can be further simplified to<br />
D * 2**32 / 600<br />
without much loss of accuracy.<br />
<br />
At difficulty 1, that is around 7 Mhashes per second.<br />
<br />
At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was<br />
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.<br />
<br />
=== How soon might I expect to generate a block? ===<br />
(The [https://www.bitcointalk.org/index.php?topic=1682.0 eternal question].)<br />
<br />
The average time to find a block can be approximated by calculating:<br />
time = difficulty * 2**32 / hashrate<br />
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.<br />
<br />
For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:<br />
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"<br />
23.85<br />
and find that it takes just under 24 hours on average.<br />
<br />
* Any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts your hardware can make per second.<br />
* You need to know the difficulty (above) and your khash/sec rate (reported by the client).<br />
** [[Mining Hardware Comparison]] has some stats that may help you predict what you could get.<br />
* Visit a calculator or perform the maths yourself,<br />
** http://www.alloscomp.com/bitcoin/calculator.php<br />
** http://www.vnbitcoin.org/bitcoincalculator.php<br />
** https://bitknock.com/calculator<br />
**https://99bitcoins.com/bitcoin-mining-calculator<br />
* Remember it's just probability! There are no guarantees you will win every N days.<br />
<br />
== Why is bitcoin not designed to update the difficulty more frequently? ==<br />
<br />
Discussion: https://old.reddit.com/r/Bitcoin/comments/mtugta/mentor_monday_april_19_2021_ask_all_your_bitcoin/gv86j6b/?context=5<br />
<br />
==Related Links==<br />
<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AiFMBvXvL2dtdEZkR2J4eU5rS3B4ei1iUmJxSWNlQ0E Bitcoin Difficulty History]<br />
* [https://www.bitcoinmining.com/what-is-bitcoin-mining-difficulty/ What is Bitcoin Mining Difficulty?]<br />
* See also: [[target]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
[[pl:Trudność]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68643PayJoin adoption2021-05-05T11:54:05Z<p>Belcher: /* Stores */ add ideas like flames</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| BTCPay Server || {{Yes}} || {{Yes}} || https://docs.btcpayserver.org/Payjoin/<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| Bluewallet || {{Yes}} || {{Planned}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{Planned}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{Planned}} || {{Planned}} || https://twitter.com/hodlhodl/status/1352266122389827584<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|-<br />
| Max Hillebrand's donation page || {{Yes}} || https://towardsliberty.com/btcpay/apps/27jLc1qpN8UXcQanHgeAsaEgLAio/pos ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|-<br />
| Ideas Like Flames || {{Yes}} || https://twitter.com/ideaslikeflames/status/1389746824009949191<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=JoinMarket&diff=68642JoinMarket2021-04-30T13:37:20Z<p>Belcher: Add link to bitcoinkpis which tracks volumes</p>
<hr />
<div>[[File:Coinjoin-joinmarket.png|700px|thumb|right|A [[CoinJoin]] [[transaction]] almost-certainly created by JoinMarket.]]<br />
<br />
'''JoinMarket''' is a [[CoinJoin]] implementation aimed at improving the [[privacy]] and [[fungibility]] of bitcoin transactions.<br />
<br />
A [[CoinJoin]] transaction requires other people to take part. The right resources (coins) have to be in the right place, at the right time, in the right quantity. This isn't a software or tech problem but an economic problem. JoinMarket works by creating a new kind of market that allocates these resources in the best way.<br />
<br />
This works by allowing coinjoin transactions to be paid-for. On one side there are time-rich coinjoiners who collect fees when other peers create coinjoins with them, called market makers. On the other side there are time-stressed coinjoiners who can coinjoin instantly and pay a fee, called market takers. <br />
<br />
Because of this market for coinjoins, JoinMarket can be used to send equal-amount [[CoinJoin]] transactions of any amount up to about 200 btc (as of 2019), at any time desired by the user. The use of [[CoinJoin]] makes the system non-custodial as the [[private key]]s never leave the user's control. As the supply of held bitcoins is high, and risk of loss is very small, coinjoin fees can be expected to also be small. The JoinMarket wallet is a [[Deterministic wallet|hierarchical deterministic wallet]] which allows users to easily avoid [[address reuse]].<br />
<br />
Recent versions also allow sending and receiving [[PayJoin]]s<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/release-notes/release-notes-0.5.2.md#payjoin-feature-aka-pay-to-endpointp2ep</ref> which are a special kind of coinjoin where the two involved parties pay each other. This [[CoinJoin]] type has different (probably better) privacy properties.<br />
<br />
As market makers can earn coinjoin fees, it is possible for long-term holders of bitcoin to use JoinMarket as an investment vehicle to generate an income from their held bitcoins.<br />
<br />
The project is coded in Python and was first released on bitcoin's mainnet in 2015.<br />
<br />
Some data on volumes can be found here: http://bitcoinkpis.com/privacy<br />
<br />
=== Scripts ===<br />
<br />
The JoinMarket project has several application scripts which are used for different purposes.<br />
<br />
==== Yield generator ====<br />
<br />
Being a market maker allows holders of bitcoin to collect fees. With this, the Yield Generator script is used to earn an income from long-term held bitcoin. The investment is very low risk as the software only signs [[transaction]]s that are valid and pay operators the correct amount in coinjoin fees. Although the coins must be held on an online [[hot wallet]]. The investment has no commitment as bitcoins can be withdrawn at any time. It also improves the privacy of the held bitcoins as well as privacy and fungibility in the entire ecosystem, which makes bitcoin as a currency more useful and thus increases its value.<br />
<br />
==== Joinmarket-Qt ====<br />
<br />
[[File:JMQwalletcoinsloadedregtest.png|400px|thumb|right|Screenshot of the JoinMarket-Qt GUI]]<br />
<br />
Joinmarket-Qt is a GUI application which allows users to create wallets and send coinjoins<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/JOINMARKET-QT-GUIDE.md</ref>. It is essentially a simple GUI bitcoin wallet with sendpayment and tumbler scripts wrapped inside.<br />
<br />
==== Send payment ====<br />
<br />
The send payment script is used to create a single [[CoinJoin]] [[transaction]] that pays bitcoins somewhere. It acts as a market taker. <!-- As well as ... --><br />
<br />
==== Tumbler ====<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the JoinMarket project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''"Generate New Deposit Address"'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts. The script is different from the ''send payment'' script because it takes much longer to run (needing to wait for many [[confirmation]]s as well as having random waits) but has much stronger privacy properties.<br />
<br />
==== Orderbook watcher ====<br />
<br />
The orderbook watcher script is used to display and view all the coinjoin offers along with their prices.<br />
<br />
=== Mixdepths ===<br />
<br />
To avoid a later transaction recombining a [[change]] output with a coinjoin output, JoinMarket's wallets have the concept of a mixdepth. UTXOs from one mixdepth are never used as inputs along with coins from others, so mixdepths are like seperate identities which users can use to stop coins from different sources being mixed. Coins only move between them via coinjoins. The [[Deterministic wallet]] discourages users from doing [[address reuse]]. The wallet allows individual private keys and UTXOs to be imported, which can be used with reused addresses to have coinjoins created from them which would confuse any analysis based on the [[common-input-ownership heuristic]].<br />
<br />
=== Probable examples of JoinMarket [[CoinJoin]]s ===<br />
<br />
It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a JoinMarket transaction but are made by a single person.<br />
<br />
* <code>55eac9d4a4159d4ba355122c6c18f85293c19ae358306a3773ec3a5d053e2f1b</code><br />
* <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code><br />
* <code>722bb2662cb2ef9b4a2693e52ba82c44cea1042349f1aa6e71e28a3947aa4144</code><br />
* <code>3b97544488cac0271a80b20822597342648d19ed02ac25041bd8d35e624d8e6b</code><br />
* <code>7104bae698587b3e75563b7ea7a9aada41d9c787788bc2bf26dd201fd7eca8a2</code> - A probable [[PayJoin]] transaction<ref>https://mastodon.social/@waxwing/101387762796750634</ref>. Payjoins are indistinguishable from regular bitcoin transactions, but this one was published online by its creator.<br />
<br />
<br />
== External links ==<br />
<br />
* https://github.com/JoinMarket-Org/joinmarket-clientserver<br />
* <code>#joinmarket</code> IRC channel on the Freenode network. [https://webchat.freenode.net/?channels=%23joinmarket Web interface].<br />
* http://www.reddit.com/r/joinmarket<br />
* https://bitcointalk.org/index.php?topic=919116.0<br />
* https://twitter.com/joinmarket/<br />
* https://imgur.com/C6w0Pgf - infographic<br />
* https://github.com/AdamISZ/JMPrivacyAnalysis<br />
<br />
== See also ==<br />
<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Privacy]]<br />
[[Category:Open Source]]<br />
[[Category:Software]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68641Privacy2021-04-29T16:15:38Z<p>Belcher: /* Avoiding forced address reuse */ Add instructions for how to spend forced address reuse coins to miner fees</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' or '''incentivized [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use the payments as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]]. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
The correct behaviour by wallets is to not spend coins that have landed on an already-used empty addresses.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Another option is to spend the coins individual directly to miner fees. Here are instructions for how to do this with Electrum or Bitcoin Core: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
Main article: [[Confidential transactions]]<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Hash_per_second&diff=68610Hash per second2021-04-18T00:14:32Z<p>Belcher: /* Bitcoin network hash rate */ Add link to sipa's hashrate website</p>
<hr />
<div>'''Hash per second''' is an SI derived unit representing the number of [[mining|double SHA-256 computations]] performed in one second, referred to as '''hash rate'''. It is usually symbolized as '''h/s''' (with an appropriate SI prefix).<br />
<br />
== Use in hardware specifications ==<br />
The hash rate is the primary measure of a [[Mining_hardware_comparison|Bitcoin miner]]'s performance. In 2014, a miner's performance was generally measured in Ghash/s, or billions of hashes per second.<br />
<br />
The hash/s unit is also part of a common measure of a Bitcoin miner's electric efficiency in the term [[wikipedia:Watt|watts]]/Ghash/s, denoted as W/Ghash/s. As 1 watt is equal to 1 joule/s, this measure can also be expressed as J/Ghash, or joules per 1 billion hashes.<br />
<br />
== Bitcoin network hash rate ==<br />
The hash/s is also used in calculations of the Bitcoin network's overall hash rate. Because each miner or [[Pooled mining|mining pool]] only relays a solved block to the network, the overall hash rate of the network is calculated based on the time between blocks. While not an accurate measure of network hash rate at any given instance in time, measurements over longer periods can be considered indicative and similar calculations are used in Bitcoin's [[Difficulty|difficulty]] adjustment.<br />
<br />
In January 2015, the network hash rate was around 300 Phash/s, or 300 quadrillion hashes per second.<ref>https://blockchain.info/charts/hash-rate</ref> In April 2021 it was about 170000 Phash/s<ref>http://bitcoin.sipa.be/</ref><br />
<br />
== References ==<br />
<references /></div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68609Privacy2021-04-17T16:58:51Z<p>Belcher: /* Fee bumping */ Add point about being able to replace both addresses in an RBF</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' or '''incentivized [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use the payments as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]]. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
The correct behaviour by wallets is to not spend coins that have landed on an already-used empty addresses.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
Main article: [[Confidential transactions]]<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Address_reuse&diff=68603Address reuse2021-04-11T22:41:05Z<p>Belcher: /* Worked Example 4 */ Clarify</p>
<hr />
<div>'''Address reuse''' refers to the use of the same [[address]] for multiple [[transactions]]. It is an unintended practice, abusing the privacy and security of the participants of the transactions as well as future holders of their value. It also only functions by accident, not by design, so cannot be depended on to work reliably.<br />
<br />
The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also when sending money to people always ask them for a brand new bitcoin address.<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object. A better name would be something like "bitcoin invoice".<br />
<br />
All good wallets today use [[Deterministic wallet]]s and have a user interface which make it easy and safe to have many wallet [[address]]es. Previously (before around 2013) this was not the case as creating new addresses could invalidate backups leading to loss of funds.<br />
<br />
== Problems ==<br />
=== Privacy ===<br />
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.<br />
In some cases, these risks are serious enough that they are likely in violation of reasonable consumer protection laws.<br />
<br />
When addresses are re-used, they allow others to much more easily and reliably determine that the address being reused is yours. Every time the re-used address's private key signs a fresh transaction, whoever receives it can use the histories of that address to discover information about you, and everyone who is interested in discovering the identity of the address's owner has one more target they can try to contact to discover who you are.<br />
<br />
The relationship graph in a re-used address is powerfully-linked in that '''all''' of the inputs to that address are necessarily joined (via the spending authority of your private key) to all of its outputs.<br />
<br />
There has been significant research into the area of what researchers are calling 'identity collapse', which is what happens when more than one Bitcoin address is strongly-linked via the Bitcoin transaction graph to another. Re-using addresses makes their job trivial. There are publically-known databases that exist, right now, that have not only collapsed millions of Bitcoin addresses, but used publically-available information to '''link''' those collapsed identities to individuals, and these databases are being actively maintained.<br />
<br />
While you may be okay with some random European researcher bound by his ethics board to conceal your identity from the public at-large, it is very possible that people who accept money from you may not be aware of your decision: thus, via your privacy-decreasing action, people further on the address signing chain could thus be putting '''you''' at risk if they spend their bitcoin on something that catches the attention of law enforcement.<br />
<br />
Additionally, in the event that you knowingly make this choice (which you are doing, now that you've read this,) the transaction histories that you are responsible for linking in the event you are a retailer of some sort could put the privacy of your customers at risk because now your well-known singular address(es) which can be strongly linked to your corporate identity can be assumed to be economic activity interacting with your corporate identity.<br />
<br />
See also: [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ Innovations that Enhance Bitcoin Anonymity]<br />
<br />
==== Worked Example 1 - Savings Revealed ====<br />
* You save in bitcoin, using a [[Paper Wallet | single-address paper wallet]].<br />
* All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
* You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
* The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
* He mentions it to someone in a cafe or bar.<br />
* Word gets around. A burglar raids your home. Kidnappers capture your children and know exactly how much to demand in ransom.<br />
<br />
==== Worked Example 2 - Exchange Front Running ====<br />
* You have an account on a bitcoin [[exchange]], you want to deposit some bitcoins to sell.<br />
* You send bitcoins to the same exchange deposit address you have used in the past.<br />
* Because of the address reuse, its easy to see on the blockchain that some bitcoins are being sent to an exchange.<br />
* The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
* You sell the bitcoins for a less attractive price than you otherwise would have.<br />
* This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
==== Worked Example 3 ====<br />
* You use a single Bitcoin address for all your earning and spending. Anyone you trade with can see a complete history of your finances.<br />
* Your landlord can see your salary, when he raises the rent he knows exactly how much to ask for.<br />
* Your shopkeeper can see your spending. Gossip gets around of how much you spend on pornography and how little on church donations.<br />
* Your employer can see your spending. When you pay labour union dues or donate to wikileaks or another non-profit, your boss knows who not to trust.<br />
<br />
=== Censorship resistance ===<br />
<br />
A reused address is much more easily linked with a certain entity. Because of this, it is easy for people to build up a blacklist of bitcoin addresses to which they will not allow transfers to. Avoiding address reuse makes this much harder.<br />
<br />
==== Worked Example 4 ====<br />
* You want to [[Receiving donations with bitcoin|accept donations in bitcoin]], so you publish a single reused bitcoin address on your website.<br />
* Some people want to donate to you by buying bitcoins from an exchange and have the coins sent immediately to your donation address.<br />
* Unlucky for you, the exchange wants to block donations to you, so it does not allow people to send coins to your address.<br />
* The way to solve this is to avoid address reuse by displaying a brand new address to each visitor. That visitor can tell the exchange to send coins to that address. Because the address is new and unused the exchange will have no idea that it belongs to you, and so will be unable to block the transfer.<br />
<br />
=== Security ===<br />
Bitcoin does not, at a low level, have any concept of addresses, only individual coins.<br />
Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins.<br />
Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins.<br />
Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.<br />
While the known situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.<br />
<br />
In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions.<br />
Upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO).<br />
This will cause the attacker's transactions to relay across the rest of the nodes ''faster'' than the legitimate one, increasing success of a double spend.<br />
<br />
==== Known attacks ====<br />
<br />
* Same K in multiple signatures, see; [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html Recovering Bitcoin private keys using weak signatures from the blockchain].<br />
* [https://eprint.iacr.org/2014/140.pdf Timing sidechannel]<br />
<br />
=== Accidental loss ===<br />
In Bitcoin abstraction, an address is an invoice for a specific payment.<br />
Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it.<br />
Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised.<br />
In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient.<br />
<br />
=== Confusion ===<br />
Users who see addresses reused may incorrectly be led to believe they function similarly to wallets or bank accounts.<br />
Often this is manifested in people talking about nonsense like "[[Address#Address_balances|address balance]]", "wallet address", "[[From_address|from address]]", and similar [[Address#Misconceptions|misconceptions]] that don't actually exist in Bitcoin.<br />
<br />
=== High Fees ===<br />
A single invoice payment using P2PKH can be redeemed and spent with a predictable fee because the transaction should have a predictable size. Software that determines payment and available funds based on "address balance" can cause loss through high fees. If you are paid to an address in many small increments, you will pay a much higher transaction fee when redeeming those payments. It is much more useful for a client to display transaction outputs spendable than address balances for this reason.<br />
<br />
== Notable offenders ==<br />
Some notable Bitcoin software and services encourage or require address reuse:<br />
* Many bitcoin mining pools (especially [[Eligius]])<br />
* [[Paper wallet]] which use a single bitcoin private key/address pair<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Address_reuse&diff=68601Address reuse2021-04-10T22:51:04Z<p>Belcher: /* Problems */ Add section on censorship resistance</p>
<hr />
<div>'''Address reuse''' refers to the use of the same [[address]] for multiple [[transactions]]. It is an unintended practice, abusing the privacy and security of the participants of the transactions as well as future holders of their value. It also only functions by accident, not by design, so cannot be depended on to work reliably.<br />
<br />
The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also when sending money to people always ask them for a brand new bitcoin address.<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object. A better name would be something like "bitcoin invoice".<br />
<br />
All good wallets today use [[Deterministic wallet]]s and have a user interface which make it easy and safe to have many wallet [[address]]es. Previously (before around 2013) this was not the case as creating new addresses could invalidate backups leading to loss of funds.<br />
<br />
== Problems ==<br />
=== Privacy ===<br />
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.<br />
In some cases, these risks are serious enough that they are likely in violation of reasonable consumer protection laws.<br />
<br />
When addresses are re-used, they allow others to much more easily and reliably determine that the address being reused is yours. Every time the re-used address's private key signs a fresh transaction, whoever receives it can use the histories of that address to discover information about you, and everyone who is interested in discovering the identity of the address's owner has one more target they can try to contact to discover who you are.<br />
<br />
The relationship graph in a re-used address is powerfully-linked in that '''all''' of the inputs to that address are necessarily joined (via the spending authority of your private key) to all of its outputs.<br />
<br />
There has been significant research into the area of what researchers are calling 'identity collapse', which is what happens when more than one Bitcoin address is strongly-linked via the Bitcoin transaction graph to another. Re-using addresses makes their job trivial. There are publically-known databases that exist, right now, that have not only collapsed millions of Bitcoin addresses, but used publically-available information to '''link''' those collapsed identities to individuals, and these databases are being actively maintained.<br />
<br />
While you may be okay with some random European researcher bound by his ethics board to conceal your identity from the public at-large, it is very possible that people who accept money from you may not be aware of your decision: thus, via your privacy-decreasing action, people further on the address signing chain could thus be putting '''you''' at risk if they spend their bitcoin on something that catches the attention of law enforcement.<br />
<br />
Additionally, in the event that you knowingly make this choice (which you are doing, now that you've read this,) the transaction histories that you are responsible for linking in the event you are a retailer of some sort could put the privacy of your customers at risk because now your well-known singular address(es) which can be strongly linked to your corporate identity can be assumed to be economic activity interacting with your corporate identity.<br />
<br />
See also: [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ Innovations that Enhance Bitcoin Anonymity]<br />
<br />
==== Worked Example 1 - Savings Revealed ====<br />
* You save in bitcoin, using a [[Paper Wallet | single-address paper wallet]].<br />
* All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
* You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
* The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
* He mentions it to someone in a cafe or bar.<br />
* Word gets around. A burglar raids your home. Kidnappers capture your children and know exactly how much to demand in ransom.<br />
<br />
==== Worked Example 2 - Exchange Front Running ====<br />
* You have an account on a bitcoin [[exchange]], you want to deposit some bitcoins to sell.<br />
* You send bitcoins to the same exchange deposit address you have used in the past.<br />
* Because of the address reuse, its easy to see on the blockchain that some bitcoins are being sent to an exchange.<br />
* The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
* You sell the bitcoins for a less attractive price than you otherwise would have.<br />
* This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
==== Worked Example 3 ====<br />
* You use a single Bitcoin address for all your earning and spending. Anyone you trade with can see a complete history of your finances.<br />
* Your landlord can see your salary, when he raises the rent he knows exactly how much to ask for.<br />
* Your shopkeeper can see your spending. Gossip gets around of how much you spend on pornography and how little on church donations.<br />
* Your employer can see your spending. When you pay labour union dues or donate to wikileaks or another non-profit, your boss knows who not to trust.<br />
<br />
=== Censorship resistance ===<br />
<br />
A reused address is much more easily linked with a certain entity. Because of this, it is easy for people to build up a blacklist of bitcoin addresses to which they will not allow transfers to. Avoiding address reuse makes this much harder.<br />
<br />
==== Worked Example 4 ====<br />
* You want to [[Receiving donations with bitcoin|accept donations in bitcoin]], so you publish a single reused bitcoin address on your website.<br />
* Some people want to donate to you by buying bitcoins from an exchange and have the coins sent immediately to your donation address.<br />
* Unlucky for you, the exchange wants to block donations to you, so it does not allow people to send coins to you.<br />
* The way to solve this is to avoid address reuse by displaying a brand new address to each visitor. That visitor can tell the exchange to send coins to that address. Because the address is new and unused the exchange will have no idea that it belongs to you, and so will be unable to block the transfer.<br />
<br />
=== Security ===<br />
Bitcoin does not, at a low level, have any concept of addresses, only individual coins.<br />
Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins.<br />
Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins.<br />
Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.<br />
While the known situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.<br />
<br />
In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions.<br />
Upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO).<br />
This will cause the attacker's transactions to relay across the rest of the nodes ''faster'' than the legitimate one, increasing success of a double spend.<br />
<br />
==== Known attacks ====<br />
<br />
* Same K in multiple signatures, see; [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html Recovering Bitcoin private keys using weak signatures from the blockchain].<br />
* [https://eprint.iacr.org/2014/140.pdf Timing sidechannel]<br />
<br />
=== Accidental loss ===<br />
In Bitcoin abstraction, an address is an invoice for a specific payment.<br />
Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it.<br />
Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised.<br />
In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient.<br />
<br />
=== Confusion ===<br />
Users who see addresses reused may incorrectly be led to believe they function similarly to wallets or bank accounts.<br />
Often this is manifested in people talking about nonsense like "[[Address#Address_balances|address balance]]", "wallet address", "[[From_address|from address]]", and similar [[Address#Misconceptions|misconceptions]] that don't actually exist in Bitcoin.<br />
<br />
=== High Fees ===<br />
A single invoice payment using P2PKH can be redeemed and spent with a predictable fee because the transaction should have a predictable size. Software that determines payment and available funds based on "address balance" can cause loss through high fees. If you are paid to an address in many small increments, you will pay a much higher transaction fee when redeeming those payments. It is much more useful for a client to display transaction outputs spendable than address balances for this reason.<br />
<br />
== Notable offenders ==<br />
Some notable Bitcoin software and services encourage or require address reuse:<br />
* Many bitcoin mining pools (especially [[Eligius]])<br />
* [[Paper wallet]] which use a single bitcoin private key/address pair<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Timelock&diff=68588Timelock2021-04-01T00:21:54Z<p>Belcher: /* Far-future locks */ Add link to that guy who locked up 0.0003 btc until the year 2042</p>
<hr />
<div>A '''Timelock''' is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin [[Contracts|smart contracts]], including [[payment channels]] and [[Hashed Timelock Contracts|hashed timelock contracts]]. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make [[fee sniping]] less profitable, and for [[Techniques_to_reduce_transaction_fees#Pre-computed_fee_bumping|trustless precomputed fee bumping]].<br />
<br />
== Primitives ==<br />
<br />
=== nLockTime ===<br />
<br />
''Main article: [[nLockTime]]''<br />
<br />
In the original Bitcoin release, nodes would not relay nor mine transactions with nLockTime equal to or greater than the current block height (unless all inputs' sequence numbers were 0xffffffff), however they would accept blocks containing transactions with any value of nLockTime. In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-23cfe05393c8433e384d2c385f06ab93R406</ref> Then, starting from block 31001 (December of 2009), the nLockTime restrictions were activated as a rule that also applied to block acceptance.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-118fcbaaba162ba17933c7893247df3aR1222</ref> Later, in July of 2016, the time based locks were changed to operate on the [[median time past]] instead of the block's timestamp.<ref>https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki</ref><br />
<br />
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to <code>0</code>, meaning the transaction was valid in any block. Starting with [[Bitcoin Core]] 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized [[fee sniping]] less profitable<ref name="anti_fee_sniping"/>; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of early-2019.<br />
<br />
=== CheckLockTimeVerify ===<br />
<br />
In late 2015, the BIP65 soft fork<ref name="bip65"/> redefined the NOP2 opcode as the [[CheckLockTimeVerify]] (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CLTV is currently used in [[CLTV-style payment channels]].<br />
<br />
=== Relative locktime ===<br />
<br />
In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the [[nSequence]] field<ref name="bip68"/> that is a part of every transaction input, creating a "relative locktime"{{citation needed}}. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.<br />
<br />
=== CheckSequenceVerify ===<br />
<br />
Also part of the BIP68/112/113 soft fork was the [[CheckSequenceVerify]] opcode<ref name="bip112"/>, which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.<br />
<br />
CSV is used by [[Lightning Network]] transactions.<br />
<br />
== Far-future locks ==<br />
<br />
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.<br />
<br />
OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries.<br />
<br />
Occasionally coins have been accidentally locked up for a long time.<ref>https://github.com/OutCast3k/coinbin/issues/35#issuecomment-167440998</ref><br />
<br />
== See Also ==<br />
<br />
* [https://coinb.in/#newTimeLocked coinb.in's time-locked page] javascript page for creating time-locked bitcoin wallets.<br />
* [https://www.reddit.com/r/Bitcoin/comments/4p4klg/bitcoin_core_project_the_csv_soft_fork_has/d4i01he/ Reddit discussion of the possible uses OP_CHECKSEQUENCEVERIFY]<br />
<br />
== References ==<br />
<references><br />
<ref name="bip65">[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]<br>Peter Todd<br>Retrieved 2016-04-12</ref><br />
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers]<br>Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona<br>Retrieved 2016-04-12</ref><br />
<ref name="bip112">[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]<br>BtcDrak, Mark Friedenbach, Eric Lombrozo<br>Retrieved 2016-04-12</ref><br />
<ref name="anti_fee_sniping">[https://bitcoin.org/en/release/v0.11.0 Bitcoin Core 0.11.0 release notes]<br>Bitcoin.org<br>Retrieved 2016-11-06</ref><br />
</references><br />
<br />
[[Category:Technical]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Irreversible_Transactions&diff=68587Irreversible Transactions2021-03-31T19:07:56Z<p>Belcher: /* Bribing miners to reorg a confirmed transaction */ replaced deleted post link with archive.is</p>
<hr />
<div>When used correctly, Bitcoin's base layer transactions on the [[blockchain]] are irreversible and final. It's no exaggeration to say that the entirety of bitcoin's system of [[blockchain]], [[mining]], [[proof of work]], [[difficulty]] etc, exist to produce this history of transactions that is computationally impractical to modify.<br />
<br />
In the literature on electronic cash, this property was often refer to as "solving the double-spending problem". Double-spending is the result of successfully spending some money more than once. Bitcoin users protect themselves from double spending fraud by waiting for [[confirmation|confirmations]] when receiving payments on the blockchain, the transactions become more irreversible as the number of confirmations rises.<br />
<br />
Other electronic systems prevent double-spending by having a master authoritative source that follows business rules for authorizing each transaction. Bitcoin uses a decentralized system, where a [[Full node#Economic_strength|consensus]] among nodes following the same protocol and [[proof of work]] is substituted for a central authority. This means bitcoin has special properties not shared by centralized systems. For example if you keep the [[private key]] of a bitcoin secret and the transaction has enough confirmations, then nobody can take the bitcoin from you no matter for what reason, no matter how good the excuse, no matter what. Possession of bitcoin is not enforced by business rules and policy, but cryptography and game theory.<br />
<br />
Because bitcoin transactions can be final, merchants do not need to hassle customers for extra information like billing address, name, etc, so bitcoin can be used without registering a real name or excluding users based on age, nationality or residency. Finality in transactions means [[Contract|smart contracts]] can be created with a "code-is-law" ethos.<br />
<br />
==Attack vectors==<br />
<br />
===Race attack===<br />
<br />
Traders and merchants who accept a payment immediately on seeing "0/unconfirmed" are exposed to the transaction being reversed. An attempt at fraud could work that the fraudster sends a transaction paying the merchant directly to the merchant, and sends a conflicting transaction spending the coin to himself to the rest of the network. It is likely that the second conflicting transaction will be mined into a block and accepted by bitcoin nodes as genuine.<br />
<br />
Merchants can take precautions (e.g., disable incoming connections, only connect to well connected nodes) to lessen the risk of a race attack but the risk cannot be eliminated. Therefore, the cost/benefit of the risk needs to be considered when accepting payment on 0/unconfirmed when there is no recourse against the attacker.<br />
<br />
The [[research]] paper [http://eprint.iacr.org/2012/248.pdf Two Bitcoins at the Price of One] finds that the protocol allows a high degree of success by an attacker in performing race attacks. The method studied in the research paper depends on access to the merchant's Bitcoin node which is why that even prior to this paper, recommendations for merchants include disabling incoming connections and to choose specific outgoing connections<ref>[http://bitcointalk.org/index.php?topic=79090.msg881283#msg881283 BitcoinTalk Thread - Two Bitcoins at the Price of One]</ref>.<br />
<br />
===Finney attack===<br />
<br />
Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but some miner hash power is required and a specific sequence of events must occur. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.<br />
<br />
A Finney attack works as follows: Suppose the attacker is generating blocks occasionally. in each block he generates, he includes a transfer from address A to address B, both of which he controls. To cheat you, when he generates a block, he doesn't broadcast it. Instead, he opens your store web page and makes a payment to your address C with his address A. You may wait a few seconds for double-spends, not hear anything, and then transfer the goods. He broadcasts his block now, and his transaction will take precedence over yours.<br />
<br />
===Vector76 attack===<br />
<br />
Also referred to as a one-confirmation attack, is a combination of the race attack and the Finney attack such that a transaction that even has one confirmation can still be reversed. The same protective action for the race attack (no incoming connections, explicit outgoing connection to a well-connected node) significantly reduces the risk of this occurring.<br />
<br />
It is worth noting that a successful attack costs the attacker one block - they need to 'sacrifice' a block by not broadcasting it, and instead relaying it only to the attacked node.<br />
<br />
See on [http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 BitcoinTalk] or further [http://www.reddit.com/r/Bitcoin/comments/2e7bfa/vector76_double_spend_attack/cjwya6x example of an attack scenario].<br />
<br />
=== Blockchain reorganization attack===<br />
<br />
Also called alternative history attack. This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate and risk of significant expense in wasted electricity to the attacking miner.<br />
<br />
The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this then the attack fails, the attacker has wasted a significant amount of electricity and the payment to the merchant will not be reversed.<br />
<br />
===[[Majority attack]]===<br />
<br />
Also referred to as a 51% attack or >50% attack. If the attacker controls more than half of the network hashrate, the previously-mentioned Alternative history attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.<br />
<br />
No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could potentially make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. Bitcoin's security model relies on no single coalition of miners controlling more than half the mining power. A miner with more than 50% hash power is incentived to reduce their mining power and reframe from attacking in order for their mining equipment and bitcoin income to retain it's value.<br />
<br />
== How many confirmations are required ==<br />
<br />
The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. An online calculator can be found here: https://people.xiph.org/~greg/attack_success.html<br />
<br />
For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>. Because of the opportunity cost of this attack, it is only game-theory possible if the bitcoin amount traded is comparable to the block reward (but note that an attacking miner can attempt a brute force attack against several counterparties at once).<br />
<br />
If the bitcoin amount being transacted is so large that it is comparable to the block reward, then merchants should wait 100 confirmations for their incoming transactions to be irreversible.<br />
<br />
=== Bribing miners to reorg a confirmed [[transaction]] ===<br />
<br />
In the past after large bitcoin thefts, it has been suggested that the theft victim attempts to bribe miners into reversing the confirmed transaction. This does not work because the thief can easily outbid with their own bribe. The thief gets a head-start as the transaction would already have confirmations. Every block that gets mined adds a block reward amount of bitcoins more that the attacker could keep while still paying more than the victim, as is every percentage of hashpower that doesn't go along with it. Such a reorg attempt, if successful, would also cause massive disruption in the bitcoin network and open the reorganizing miners and victim to litigation.<br />
<br />
Examples:<br />
<br />
* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://archive.is/S2fBH<br />
<br />
* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144<br />
<br />
==Successful Double-Spends in Practice==<br />
<br />
* In November 2013 it was discovered that the GHash.io mining pool appeared to be engaging in repeated payment fraud against BetCoin Dice, a gambling site<ref>[https://bitcointalk.org/index.php?topic=327767.0 BitcoinTalk Thread - GHash.IO and double-spending against BetCoin Dice]</ref>. Dice sites use one transaction per bet and don’t wait for confirmations. GHash.io claimed they had investigated and found a rogue employee who had been doing the double spending, who was fired. However no evidence supporting this was provided and the incident left a permanent cloud hanging over the pool. Regardless, it didn’t seem to hurt their market share much: most miners probably never heard about the incident at all.<br />
<br />
==Consumer Protection==<br />
<br />
Although bitcoin's base layer blockchain transactions are irreversible, consumer protection can be implemented on a layer on top.<br />
<br />
For example [[Secure_Trading#Use_an_Escrow_Service|using an escrow agent]] is a powerful technique especially when combined with [[Multisignature|multisignature smart contracts]]. Also bitcoin sites such as online casinos rely on their long-standing reputation and some regulated brokers and exchanges simply rely on the legal system.<br />
<br />
See also: [[Myths#Bitcoin_has_no_built-in_chargeback_mechanism_and_this_is_bad]]<br />
<br />
==See Also==<br />
<br />
* [[Weaknesses]]<br />
* [[Bitcoin as a medium of exchange]]<br />
* [http://codinginmysleep.com/bitcoin-attacks-in-plain-english Bitcoin Attacks in Plain English] by David Perry<br />
* [https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 Thorough discussion of zero-confirm on-chain transactions in bitcoin] by Bram Cohen<br />
* [https://bitcoin.stackexchange.com/questions/87652/51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t/87655#87655 stackexchange discussion on exchanges bribing miners to reverse transactions]<br />
* [https://pooldetective.org/ MIT DCI’s pool detective app monitors various mining pools for odd behaviour like censorship, selfish mining or reorg attempts]<br />
<br />
<br />
[[de:Doppelausgaben]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Technical]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68576PayJoin adoption2021-03-25T16:10:04Z<p>Belcher: /* Non-profits */ typo</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{Planned}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{Planned}} || {{Planned}} || https://twitter.com/hodlhodl/status/1352266122389827584<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|-<br />
| Max Hillebrand's donation page || {{Yes}} || https://towardsliberty.com/btcpay/apps/27jLc1qpN8UXcQanHgeAsaEgLAio/pos ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68575PayJoin adoption2021-03-25T16:09:23Z<p>Belcher: /* Non-profits */ Add Max Hillebrand's donation page</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{Planned}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{Planned}} || {{Planned}} || https://twitter.com/hodlhodl/status/1352266122389827584<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
| -<br />
| Max Hillebrand's donation page || {{Yes}} || https://towardsliberty.com/btcpay/apps/27jLc1qpN8UXcQanHgeAsaEgLAio/pos ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Privacy&diff=68456Privacy2021-02-27T00:20:07Z<p>Belcher: /* Why privacy */ Mention censorship as a consequence of lost fungibility</p>
<hr />
<div>While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With proper understanding of the technology, bitcoin can indeed be used in a very private and anonymous way.<br />
<br />
As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.<br />
<br />
This article was written in February 2019. A good way to read the article is to [[#Examples and case studies|skip to the examples]] and then come back to read the core concepts.<br />
<br />
=== Summary ===<br />
<br />
To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:<br />
<br />
* Think about what you're hiding from, what is your threat model and what is your adversary. Note that [[transaction surveillance company|transaction surveillance companies]] exist which do large-scale surveillance of the bitcoin ecosystem.<br />
* Do not [[Address reuse|reuse addresses]]. Addresses should be shown to one entity to receive money, and never used again after the money is spent from them.<br />
* Try to reveal as little information as possible about yourself when transacting, for example avoid AML/KYC checks and be careful when giving your real life mail address.<br />
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.<br />
* Broadcast on-chain transactions over [[Tor]], if your wallet doesn't support it then copy-paste the transaction hex data into a web broadcasting form over Tor browser.<br />
* Use [[Lightning Network]] as much as possible.<br />
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].<br />
* Try to avoid creating change addresses, for example when funding a lightning channel spend an entire [[UTXO]] into it without any change (assuming the amount is not too large to be safe).<br />
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].<br />
<br />
See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.<br />
<br />
== Introduction ==<br />
<br />
Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.<br />
<br />
Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so create the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, amounts are known. Only the identity of each [[address]] is not known (see first image).<br />
<br />
The linkages between addresses made by transactions is often called the transaction graph. Alone, this information can't identify anyone because the addresses and transaction IDs are just random numbers. However, if ''any'' of the addresses in a transaction's past or future can be tied to an actual identity, it might be possible to work from that point and deduce who may own all of the other addresses. This identifying of an address might come from network analysis, surveillance, searching the web, or a variety of other methods. The encouraged practice of [[Address reuse|using a new address for every transaction]] is intended to make this attack more difficult.<br />
<br />
[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]<br />
<br />
=== Example - Adversary controls source and destination of coins ===<br />
<br />
The second image shows a simple example. An adversary runs both a money exchanger and a honeypot website meant to trap people. If someone uses their exchanger to buy bitcoins and then transacts the coins to the trap website, the block chain would show:<br />
<br />
[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]<br />
<br />
* Transaction of coins on address A to address B. Authorized by <signature of address A>.<br />
* Transaction of coins on address B to address C. Authorized by <signature of address B>.<br />
<br />
Say that the adversary knows that Mr. Doe's bank account sent the government currency which were used to buy the coins, which were then transferred to address B. The adversary also knows the trap website received coins on address C that were spent from address B. Together this is a '''very strong indication''' that address B is owned by Mr. Doe and that he sent money to the trap website. This assumption is not always correct because address B may have been an address held on behalf of Mr. Doe by a third party and the transaction to C may have been unrelated, or the two transactions may actually involve a smart contract (See [[Off-Chain Transactions]]) which effectively teleports the coins off-chain to a completely different address somewhere on the blockchain.<br />
<br />
=== Example - Non-anonymous Chinese newspaper buying ===<br />
<br />
In this example the adversary controls the destination and finds the source from metadata.<br />
<br />
# You live in China and want to buy a "real" online newspaper for Bitcoins.<br />
# You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get a modest sum as donations after a few months.<br />
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!<br />
# The government agent looks at the [[transaction]] used to purchase the newspaper on the [[block chain]], and searches the web every relevant address in it. He finds your address in your signature on the Bitcoin forum. You've left enough personal information in your posts to be identified, so you are now scheduled to be "reeducated".<br />
# A major reason this happened is because of [[address reuse]]. Your forum signature had a single bitcoin address that never changed, and so it was easy to find by searching the web.<br />
<br />
You need to protect yourself from both forward attacks (getting something that identifies you using coins that you got with methods that must remain secret, like the scammer example) and reverse attacks (getting something that must remain secret using coins that identify you, like the newspaper example).<br />
<br />
=== Example - A perfectly private donation ===<br />
<br />
On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.<br />
<br />
# The aim is to donate to some organization that accepts bitcoin.<br />
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].<br />
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.<br />
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.<br />
# Send the entire balance to a donation address of that organization.<br />
# Finally you destroy the computer hardware used.<br />
<br />
As your [[full node]] wallet runs entirely over [[Tor]], your IP address is very well hidden. [[Tor]] also hides the fact that you're using bitcoin at all. As the coins were obtained by [[mining]] they are entirely unlinked from any other information about you. Since the transaction is a donation, there are no goods or services being sent to you, so you don't have to reveal any delivery mail address. As the entire balance is sent, there is no [[change|change address]] going back that could later leak information. Since the hardware is destroyed there is no record remaining on any discarded hard drives that can later be found. The only way I can think of to attack this scheme is to be a [https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting global adversary] that can exploit the known weaknessness of Tor.<br />
<br />
=== Multiple interpretations of a blockchain transaction ===<br />
<br />
Bitcoin [[transaction]]s are made up of inputs and outputs, of which there can be one or more. Previously-created outputs can be used as inputs for later transactions. Such outputs are destroyed when spent and new unspent outputs are usually created to replace them.<br />
<br />
Consider this example transaction:<br />
<br />
1 btc ----> 1 btc <br />
3 btc 3 btc<br />
<br />
This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.<br />
<br />
If you were to look at this on the blockchain, what would you assume is the meaning of this transaction? (for example, we usually assume a bitcoin transaction is a payment but it doesn't have to be).<br />
<br />
There are ''at least nine''' possible<ref>Bitcoin Milan Meetup 46 - Talk by Adam Gibson https://www.youtube.com/watch?v=IKSSWUBqMCM&t=2448</ref> interpretations:<br />
<br />
# [https://en.wikipedia.org/wiki/Alice_and_Bob Alice] provides both inputs and pays 3 btc to [https://en.wikipedia.org/wiki/Alice_and_Bob Bob]. Alice owns the 1 btc output (i.e. it is a [[change]] output).<br />
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.<br />
# Alice provides 1 btc input and Bob provides 3 btc input, Alice gets 1 btc output and Bob gets 3 btc output. This is a kind of [[CoinJoin]] transaction.<br />
# Alice pays 2 btc to Bob. Alice provides 3 btc input, gets the 1 btc output; Bob provides 1 btc input and gets 3 btc. This would be a [[PayJoin]] transaction type.<br />
# Alice pays 4 btc to Bob (but using two outputs for some reason).<br />
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.<br />
# Alice pays Bob 3 btc and Carol 1 btc. This is a [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice pays 3, Bob pays 1; Carol gets 3 btc and David gets 1 btc. This is some kind of [[CoinJoin]]ed [[Techniques_to_reduce_transaction_fees#Change_avoidance|batched payment with no change address]].<br />
# Alice and Bob pay 4 btc to Carol (but using two outputs).<br />
<br />
Many interpretations are possible just from such a simple transaction. Therefore it's completely false to say that bitcoin [[transaction]]s are always perfectly traceable, the reality is much more complicated.<br />
<br />
Privacy-relevant adversaries who analyze the blockchain usually rely on ''heuristics'' (or ''idioms of use'') where certain assumptions are made about what is plausible. The analyst would then ignore or exclude some of these possibilities. But those are only assumptions which can be wrong. Someone who wants better privacy they can intentionally break those assumptions which will completely fool an analyst.<br />
<br />
Units of the bitcoin currency are not watermarked within a transaction (in other words they don't have little serial numbers). For example the 1 btc input in that transaction may end up in the 1 btc output or part of the 3 btc output, or a mixture of both. Transactions are many-to-many mappings, so in a very important sense it's impossible to answer the question of where the 1 btc ended up. This fungibility of bitcoin within one transaction is an important reason for the different possibility interpretations of the above transaction.<br />
<br />
=== Threat model ===<br />
<br />
When considering privacy you need to think about exactly who you're hiding from. You must examine how a hypothetical adversary could spy on you, what kind of information is most important to you and which technology you need to use to protect your privacy. The kind of behaviour needed to protect your privacy therefore depends on your threat model.<br />
<br />
Newcomers to privacy often think that they can simply download some software and all their privacy concerns will be solved. This is not so. Privacy requires a change in behaviour, however slight. For example, imagine if you had a perfectly private internet where who you're communicating with and what you say are completely private. You could still use this to communicate with a social media website to write your real name, upload a selfie and talk about what you're doing right now. Anybody on the internet could view that information so your privacy would be ruined even though you were using perfectly private technology.<br />
<br />
For details read the talk [https://www.slideshare.net/grugq/opsec-for-hackers Opsec for Hackers by grugq]. The talk is aimed mostly at political activists who need privacy from governments, but much the advice generally applies to all of us.<br />
<br />
Much of the time plausible deniability is not good enough because lots of spying methods only need to work on a statistical level (e.g. targeted advertising).<br />
<br />
=== Method of data fusion ===<br />
<br />
[[File:Privacy-data-fusion-intersection-diagram.png|200px|thumb|right|Data fusion diagram showing how two different privacy leaks can damage privacy far more in combination.]]<br />
<br />
Multiple privacy leaks when combined together can be far more damaging to privacy than any single leak. Imagine if a receiver of a [[transaction]] is trying to deanonymize the sender. Each privacy leak would eliminate many candidates for who the sender is, two different privacy leaks would eliminate ''different'' candidates leaving far fewer candidates remaining. See the diagram for a diagram of this.<br />
<br />
[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]<br />
<br />
This is why even leaks of a small amount of information should be avoided, as they can often completely ruin privacy when combined with other leaks. Going back to the example of the non-anonymous Chinese newspaper buyer, who was deanonymized because of a combination of visible transaction information and his forum signature donation address. There are many many transactions on the blockchain which on their own don't reveal anything about the transactor's identity or spending habits. There are many donation addresses placed in forum signatures which also don't reveal much about the owners identity or spending habits, because they are just random cryptographic information. But together the two privacy leaks resulted in a trip to the reeducation camp. The method of data fusion is very important when understanding privacy in bitcoin (and other situations).<br />
<br />
=== Why privacy ===<br />
<br />
Financial privacy is an essential element to [[Fungibility|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.<br />
<br />
Financial privacy is an essential criteria for the efficient operation of a free market: if you run a business, you cannot effectively set prices if your suppliers and customers can see all your transactions against your will. You cannot compete effectively if your competition is tracking your sales. Individually your informational leverage is lost in your private dealings if you don't have privacy over your accounts: if you pay your landlord in Bitcoin without enough privacy in place, your landlord will see when you've received a pay raise and can hit you up for more rent.<br />
<br />
Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you... they can tell exactly how much to try to scam you for.<br />
<br />
Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they're buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don't have privacy.<br />
<br />
Most importantly, financial privacy isn't incompatible with things like law enforcement or transparency. You can always keep records, be ordered (or volunteer) to provide them to whomever, have judges hold against your interest when you can't produce records (as is the case today). None of this requires _globally_ visible public records.<br />
<br />
Globally visible public records in finance are completely unheard-of. They are undesirable and arguably intolerable. The Bitcoin whitepaper made a promise of how we could get around the visibility of the ledger with pseudonymous addresses, but the ecosystem has broken that promise in a bunch of places and we ought to fix it. Bitcoin could have coded your name or IP address into every transaction. It didn't. The whitepaper even has a section on privacy. It's incorrect to say that Bitcoin isn't focused on privacy. Sufficient privacy is an essential prerequisite for a viable digital currency<ref>https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908</ref>.<br />
<br />
== Blockchain attacks on privacy ==<br />
<br />
Bitcoin uses a [[block chain]]. Users can [[Full node|download and verify the blockchain]] to check that all the rules of bitcoin were followed throughout its history. For example, users can check that nobody printed infinite bitcoins and that every coin was only spent with a [[OP_CHECKSIG|valid signature]] created by its [[private key]]. This is what leads to [[Bitcoin as a medium of exchange|bitcoin's unique value proposition]] as a form of electronic cash which requires [[Principles of Bitcoin#Low_trust|only small amounts of trust]]. But the same blockchain structure leads to privacy problems because every [[transaction]] must be available for all to see, forever. This section discusses known methods an adversary may use for analyzing the public blockchain.<br />
<br />
Bitcoin uses a [[Coin analogy|UTXO model]]. [[Transaction]]s have inputs and outputs, they can have one or more of each. Previous outputs can be used as inputs for later transactions. An output which hasn't been spent yet is called an unspent transaction output (UTXO). UXTOs are often called [[Coin analogy|"coins"]]. UTXOs are associated with a bitcoin [[address]] and can be spent by creating a valid signature corresponding to the scriptPubKey of the address.<br />
<br />
[[Address|Addresses]] are cryptographic information, essentially random numbers. On their own they do not reveal much about the real owner of any bitcoins on them. Usually an adversary will try to link together multiple addresses which they believe belong to the same wallet. Such address collections are called "clusters", "closures" or "wallet clusters", and the activity of creating them is called "wallet clustering". Once the clusters are obtained the adversary can try to link them real-world identities of entities it wants to spy on. For example, it may find wallet cluster A belonging to Alice and another wallet cluster B belonging to Bob. If a bitcoin [[transaction]] is seen paying from cluster A to cluster B then the adversary knows that Alice has sent coins to Bob.<br />
<br />
It can be very difficult to fine-tune heuristics for wallet clustering that lead to obtaining actually correct information<ref>Neudecker, Till & Hartenstein, Hannes. (2018). Network Layer Aspects of Permissionless Blockchains. IEEE Communications Surveys & Tutorials. PP. 1-1. 10.1109/COMST.2018.2852480.</ref>.<br />
<br />
=== [[Common-input-ownership heuristic]] ===<br />
<br />
This is a heuristic or assumption which says that if a transaction has more than one input then all those inputs are owned by the same entity.<br />
<br />
For example, consider this transaction with inputs A, B and C; and outputs X and Y.<br />
<br />
A (1 btc) --> X (4 btc)<br />
B (2 btc) Y (2 btc)<br />
C (3 btc)<br />
<br />
This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.<br />
<br />
One of the purposes of [[CoinJoin]] is to break this heuristic. Nonetheless this heuristic is very commonly true and it is widely used by [[transaction surveillance company|transaction surveillance companies]] and other adversaries as of 2019. The heuristic is usually combined with [[address reuse]] reasoning, which along with the somewhat-centralized bitcoin economy as of 2018 is why this heuristic can be unreasonably effective<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. The heuristic's success also depends on the wallet behaviour: for example, if a wallet usually receives small amounts and sends large amounts then it will create many multi-input transactions.<br />
<br />
=== [[Change]] address detection ===<br />
<br />
Many bitcoin [[transaction]]s have [[Change|change outputs]]. It would be a serious privacy leak if the change address can be somehow found, as it would link the ownership of the (now spent) inputs with a new output. Change outputs can be very effective when combined with other privacy leaks like the [[common-input-ownership heuristic]] or [[address reuse]]. Change address detection allows the adversary to cluster together newly created address, which the [[common-input-ownership heuristic]] and [[address reuse]] allows past addresses to be clustered.<br />
<br />
Change addresses lead to a common usage pattern called the '''peeling chain'''. It is seen after a large transactions from exchanges, marketplaces, mining pools and salary payments. In a peeling chain, a single address begins with a relatively large amount of bitcoins. A smaller amount is then peeled off this larger amount, creating a transaction in which a small amount is transferred to one address, and the remainder is transferred to a one-time [[change]] address. This process is repeated - potentially for hundreds or thousands of hops - until the larger amount is pared down, at which point (in one usage) the amount remaining in the address might be aggregated with other such addresses to again yield a large amount in a single address, and the peeling process begins again<ref>Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. 2013. A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the 2013 conference on Internet measurement conference (IMC '13). ACM, New York, NY, USA, 127-140. DOI: https://doi.org/10.1145/2504730.2504747 https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf</ref>.<br />
<br />
Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:<br />
<br />
==== Address reuse ====<br />
<br />
If an output address has been [[Address reuse|reused]] it is very likely to be a payment output, not a change output. This is because change addresses are created automatically by wallet software but payment addresses are manually sent between humans. The [[address reuse]] would happen because the human user reused an address out of ignorance or apathy. This heuristic is probably the most accurate, as it is very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".<br />
<br />
Some very old software (from the 2010-2011 era which did not have [[Deterministic wallet]]s) did not use a new address change but sent the change back to the input address. This reveals the change address exactly.<br />
<br />
Avoiding [[address reuse]] is an obvious remedy. Another idea is that those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.<br />
<br />
Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.<br />
<br />
==== Wallet fingerprinting ====<br />
<br />
A careful analyst sometimes deduce which software created a certain [[transaction]], because the many different wallet softwares don't always create transactions in exactly the same way. Wallet fingerprinting can be used to detect change outputs because a change output is the one spent with the same wallet fingerprint.<br />
<br />
As an example, consider five typical transactions that consume one input each and produce two outputs. A, B, C, D, E refer to transactions. A1, A2, etc refer to output addresses of those transactions<br />
<br />
--> C1<br />
A1 --> B2 --> C2<br />
--> B2 --> D1<br />
--> D2 --> E1<br />
--> E2<br />
<br />
<br />
<br />
If wallet fingerprinting finds that transactions A, B, D and E are created by the same wallet software, and the other transactions are created by other software, then the change addresses become obvious. The same transactions with non-matching addresses replaced by X is shown. The peel chain is visible, it's clear that B2, D2, E1 are change addresses which belong to the same wallet as A1.<br />
<br />
--> X<br />
A1 --> X --> X<br />
--> B2 --> X<br />
--> D2 --> E1<br />
--> X<br />
<br />
There are a number of ways to get evidence used for identifying wallet software:<br />
<br />
* Address formats. Wallets generally only use one address type. If a transaction has all inputs and one output of the same address type (e.g. p2pkh), with the remaining output of a different type (p2sh), then a reasonable assumption is that the same-address-format output (p2pkh) is change and the different-address-format output (p2sh) is the payment which belongs to someone else. <br />
<br />
* [[Script]] types. Each wallet generally uses only one [[script]]. For example, the sending wallet may be a [[P2SH]] 2-of-3 [[multisignature]] wallet, which makes a transaction to two outputs: one 2-of-3 multisignature address and the other 2-of-2 multisignature address. The different [[script]] is a strong indication that the output is payment and the other output is change. <br />
<br />
* [[BIP_0069|BIP69]] Lexicographical Indexing of Transaction Inputs and Outputs. This BIP describes a standard way for wallets to order their inputs and outputs for privacy. Right now the wallet ecosystem has a mixture of wallets which do and don't implement the standard, which helps with fingerprinting. Note that the common one-input-two-output [[transaction]] with random ordering will follow BIP69 just by chance 50% of the time.<br />
<br />
* Number of inputs and outputs. Different users often construct [[transaction]]s differently. For example, individuals often make [[transaction]] with just two outputs; a payment and change, while high-volume institutions like casinos or exchanges use [[Techniques_to_reduce_transaction_fees#Consolidation|consolidation]] and [[Techniques_to_reduce_transaction_fees#Payment_batching|batching]]<ref>Bitcoin Privacy: Theory and Practice - Jonas Nick (Blockstream) - Zürich, March 2016 https://www.youtube.com/watch?v=HScK4pkDNds</ref><ref>Nick, Jonas David. “Data-Driven De-Anonymization in Bitcoin.” (2015).</ref>. An output that is later use to create a batching transaction was probably not the change. This heuristic is also called the "consumer heuristic".<br />
<br />
* Transaction fields. Values in the [[transaction]] format which may vary depending on the wallet software: [[nLockTime]] is a field in transactions set by some wallets to make [[fee sniping]] less profitable. A mixture of wallets in the ecosystem do and don't implement this feature. nLockTime can also be used as in certain privacy protocols like [[CoinSwap]]. [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|nSequence]] is another example. Also the version number.<br />
<br />
* Low-R value signatures. The DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte. As of July 2018<ref>https://github.com/bitcoin/bitcoin/pull/13666</ref>[[Bitcoin Core]] only generates signatures with a low-R value that don't require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). As of 2019 no other wallet does this, so a high-R signature is evidence that [[Bitcoin Core]] is not being used<ref>https://bitcoinops.org/en/newsletters/2018/08/14/</ref>.<br />
<br />
* Uncompressed and compressed public keys. Older wallet software uses uncompressed public keys<ref>https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key</ref>. A mixture of compressed and uncompressed keys can be used for fingerprinting.<br />
<br />
* Miner fees. Various wallet softwares may respond to block space pressure in different ways which could lead to different kinds of miner fees being paid. This might also be a way of fingerprinting wallets.<br />
<br />
* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.<br />
<br />
If multiple users are using the same wallet software, then wallet fingerprinting cannot detect the change address. It is also possible that a single user owns two different wallets which use different software (for example a hot wallet and cold wallet) and then transactions between different softwares would not indicate a change of ownership. Wallet fingerprinting on its own is never decisive evidence, but as with all other privacy leaks it works best with data fusion when multiple privacy leaks are combined.<br />
<br />
==== Round numbers ====<br />
<br />
Many payment amounts are round numbers, for example 1 BTC or 0.1 BTC. The leftover change amount would then be a non-round number (e.g. 1.78213974 BTC). This potentially useful for finding the change address. The amount may be a round number in another currency. The amount 2.24159873 BTC isn't round in bitcoin but when converted to USD it may be close to $100.<br />
<br />
==== [[Fee bumping]] ====<br />
<br />
[[BIP 0125]] defines a mechanism for replacing an unconfirmed [[transaction]] with another transaction that pays a higher fee. In the context of the [[Miner_fees#The_market_for_block_space|market for block space]], a user may find their transaction isn't confirming fast enough so they opt to [[Fee bumping|"fee bump"]] or pay a higher miner fee. However generally the new higher miner fee will happen by reducing the change amount. So if an adversary is observing all unconfirmed transactions they could see both the earlier low-fee transaction and later high-fee transaction, and the output with the reduced amount would be the change output.<br />
<br />
This could be mitigated by some of the time reducing the amount of both outputs, or reducing only the payment amount (in a receiver-pays-for-fee model).<br />
<br />
==== Unnecessary input heuristic ====<br />
<br />
Also called the "optimal change heuristic". Consider this bitcoin transaction. It has two inputs worth 2 BTC and 3 BTC and two outputs worth 4 BTC and 1 BTC.<br />
<br />
2 btc --> 4 btc<br />
3 btc 1 btc<br />
<br />
Assuming one of the outputs is [[change]] and the other output is the payment. There are two interpretations: the payment output is either the 4 BTC output or the 1 BTC output. But if the 1 BTC output is the payment amount then the 3 BTC input is unnecessary, as the wallet could have spent only the 2 BTC input and paid lower [[miner fees]] for doing so. This is an indication that the real payment output is 4 BTC and that 1 BTC is the change output.<br />
<br />
This is an issue for transactions which have more than one input. One way to fix this leak is to add more inputs until the change output is higher than any input, for example:<br />
<br />
2 btc --> 4 btc<br />
3 btc 6 btc<br />
5 btc<br />
<br />
Now both interpretations imply that some inputs are unnecessary. Unfortunately this costs more in miner fees and can only be done if the wallet actually owns other UTXOs. <br />
<br />
Some wallets have a coin selection algorithm which violates this heuristic. An example might be because the wallets want to [[Techniques_to_reduce_transaction_fees#Consolidation|consolidate inputs]] in times of cheap miner fees. So this heuristic is not decisive evidence.<br />
<br />
==== Sending to a different script type ====<br />
<br />
Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.<br />
<br />
For example, for a transaction with 1 input spending a p2pkh coin and creating 2 outputs, one of p2pkh and one of p2sh, it is very likely that the p2pkh output is the change while the p2sh one is the payment.<br />
<br />
This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).<br />
If one of the output script types is known to be used by the wallet (because the same script type is spent by at least one of the inputs) while the other is not, the other one is likely to be the payment.<br />
<br />
This has the most effect on early adopters of new wallet technology, like p2sh or segwit.<br />
The more rare it is to pay to people using the same script type as you do, the more you leak the identity of your change output.<br />
This will improve over time as the new technology gains wider adoption.<br />
<br />
==== Wallet bugs ====<br />
<br />
Some wallet software handles change in a very un-private way. For example certain old wallets would always put the change output in last place in the transaction. An old version of [[Bitcoin Core]] would add input UTXOs to the transaction until the change amount was around 0.1 BTC, so an amount of slightly over 0.1 BTC would always be change.<br />
<br />
==== Equal-output [[CoinJoin]]====<br />
<br />
Equal-output-[[CoinJoin]] transactions trivially reveal the change address because it is the outputs which are not equal-valued. For example consider this equal-output-coinjoin:<br />
<br />
A (1btc)<br />
X (5btc) ---> B (1btc)<br />
Y (3btc) C (4btc)<br />
D (2btc)<br />
<br />
There is a very strong indication that output D is change belongs to the owner of input Y, while output C is change belonging to input X. However, [[CoinJoin]] breaks the [[common-input-ownership heuristic]] and effectively hides the ownership of payment outputs (A and B), so the tradeoffs are still heavily in favour of using coinjoin.<br />
<br />
==== Cluster growth ====<br />
<br />
Wallet clusters created by using the [[common-input-ownership heuristic]] usually grow (in number of addresses) slowly and incrementally<ref>Harrigan, Martin & Fretter, Christoph. (2016). The Unreasonable Effectiveness of Address Clustering.</ref>. Two large clusters merging is rare and may indicate that the heuristics are flawed. So another way to deduce the change address is to find which output causes the clusters to grow only slowly. The exact value for "how slowly" a cluster is allowed to grow is an open question.<br />
<br />
=== Transaction graph heuristic ===<br />
<br />
As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.<br />
<br />
This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].<br />
<br />
==== Taint analysis ====<br />
<br />
''Taint analysis'' is a technique sometimes used to study the flow of bitcoins and extract privacy-relevant information. If an address A is connected to privacy-relevant information (such as a real name) and it makes a transaction sending coins to address B, then address B is said to be ''tainted'' with coins from address A. In this way taint is spread by "touching" via transactions<ref>Meiklejohn, Sarah & Orlandi, Claudio. (2015). Privacy-Enhancing Overlays in Bitcoin. 127-141. 10.1007/978-3-662-48051-9_10. https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf</ref>. It is unclear how useful taint analysis is for spying, as it does not take into account transfer of ownership. For example an owner of tainted coins may donate some of them to some charity, the donated coins could be said to be tainted yet the charity does not care and could not give any information about the source of those coins. Taint analysis may only be useful for breaking schemes where someone tries to hide the origin of coins by sending dozens of fake transactions to themselves many times.<br />
<br />
=== Amount ===<br />
<br />
Blockchain [[transactions]] contain amount information of the transaction inputs and outputs, as well as an implicit amount of the [[Miner fees|miner fee]]. This is visible to all.<br />
<br />
Often the payment amount of a transaction is a round number, possibly when converted to another currency. An analysis of round numbers in bitcoin transactions has been used to measure the countries or regions where payment have happened<ref>Gervais A., Ritzdorf H., Lucic M., Lenders V., Capkun S. (2016) Quantifying Location Privacy Leakage from Transaction Prices. In: Askoxylakis I., Ioannidis S., Katsikas S., Meadows C. (eds) Computer Security – ESORICS 2016. ESORICS 2016. Lecture Notes in Computer Science, vol 9879. Springer, Cham https://eprint.iacr.org/2015/496</ref>.<br />
<br />
==== Input amounts revealing sender wealth ====<br />
<br />
A mismatch in the sizes of available [[Transaction#input|input]] vs what is required can result in a privacy leak of the total wealth of the sender. For example, when intending to send 1 bitcoins to somebody a user may only have an [[Transaction#input|input]] worth 10 bitcoins. They create a [[transaction]] with 1 bitcoin going to the recipient and 9 bitcoins going to a [[Change|change address]]. The recipient can look at the [[transaction]] on the blockchain and deduce that the sender owned at least 10 bitcoins.<br />
<br />
By analogy with paper money, if you hand over a 100 USD note to pay for a drink costing only 5 USD the bartender learns that your balance is at least 95 USD. It may well be higher of course, but it's at least not lower<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref>.<br />
<br />
==== Exact payment amounts (no change) ====<br />
<br />
Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.<br />
<br />
This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,<br />
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.<br />
<br />
Other possible reasons for sending exact amounts with no change is that the coin-selection algorithm was smart and lucky enough to find a suitable set of inputs for the intended payment amount that didn't require change (or required a change amount that is negligible enough to waive), or advanced users using manual coin selection to explicitly avoid change.<br />
<br />
=== Batching ===<br />
<br />
[[Techniques to reduce transaction fees#Payment_batching|Payment batching]] is a technique to reduce the [[Miner fees|miner fee]] of a payment. It works by batching up several payments into one [[block chain]] [[transaction]]. It is typically used by exchanges, casinos and other high-volume spenders.<br />
<br />
The privacy implication comes in that recipients can see the amount and address of recipients<ref>https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb</ref><br />
<br />
<blockquote><br />
When you receive your withdrawal from Kraken, you can look up your transaction on a block chain explorer and see the addresses of everyone else who received a payment in the same transaction. You don’t know who those recipients are, but you do know they received bitcoins from Kraken the same as you.<br />
<br />
That’s not good for privacy, but it’s also perhaps not the worst thing. If Kraken made each of those payments separately, they might still be connected together through the change outputs and perhaps also by certain other identifying characteristics that block chain analysis companies and private individuals use to fingerprint particular spenders.<br />
<br />
However, it is something to keep in mind if you’re considering batching payments where privacy might be especially important or already somewhat weak, such as making payroll in a small company where you don’t want each employee to learn the other employees’ salaries.<br />
</blockquote><br />
<br />
=== Unusual scripts ===<br />
<br />
Most but not all bitcoin [[Script|scripts]] are single-signature. Other scripts are possible with the most common being [[multisignature]]. A script which is particularly unusual can leak information simply by being so unique.<br />
<br />
2-of-3 multisig is by far the most common non-single-signature script as of 2019.<br />
<br />
=== Mystery shopper payment ===<br />
<br />
A [[Mystery shopper payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.<br />
<br />
=== Forced address reuse ===<br />
<br />
'''Forced [[address reuse]]''' or '''incentivized [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use the payments as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]]. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.<br />
<br />
This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.<br />
<br />
The correct behaviour by wallets is to not spend coins that have landed on an already-used empty addresses.<br />
<br />
=== Amount correlation ===<br />
<br />
Amounts correlation refers to searching the entire [[block chain]] for output amounts.<br />
<br />
For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.<br />
<br />
V --> [black box privacy tech] --> V - fee<br />
<br />
The privacy tech is used to mix V amount of bitcoins, and it returns V bitcoins minus fees back to the user. Amount correlation could be used to unmix this tech by searching the blockchain for transactions with an output amount close to V.<br />
<br />
A way to resist amount correlation is to split up the sending of bitcoins back to user into many transactions with output amounts (w0, w1, w2) which together add up to V minus fees.<br />
<br />
V --> [privacy tech] --> w0<br />
--> w1<br />
--> w2<br />
<br />
Another way of using amount correlation is to use it to find a starting point. For example, if Bob wants to spy on Alice. Say that Alice happens to mention in passing that she's going on holiday costing $5000 with her boyfriend, Bob can search all transactions on the blockchain in the right time period and find transactions with output amounts close to $5000. Even if multiple matches are found it still gives Bob a good idea of which bitcoin addresses belong to Alice.<br />
<br />
=== Timing correlation ===<br />
<br />
Timing correlation refers to using the time information of transactions on the blockchain. Similar to amount correlation, if an adversary somehow finds out the time that an interesting transaction happened they can search the blockchain in that time period to narrow down their candidates.<br />
<br />
This can be beaten by uniform-randomly choosing a time between now and an appropriate time_period in which to broadcast the bitcoin transaction. This forces an adversary to search much more of the existing transactions; they have to equally consider the entire anonymity set between now and time_period.<br />
<br />
== Non-blockchain attacks on privacy ==<br />
<br />
=== Traffic analysis ===<br />
<br />
Bitcoin [[Full node|nodes]] communicate with each other via a [[Network|peer-to-peer network]] to transmit [[transaction]]s and [[block]]s. [[Network#Standard_relaying|Nodes relay]] these packets to all their connections, which has good privacy properties because a connected node doesn't know whether the transmitted data originated from its peer or whether the peer was merely relaying it.<br />
<br />
An adversary able to snoop on your internet connection (such as your government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.<br />
<br />
If the adversary sees a [[transaction]] or [[block]] coming out of your node which did not previously enter, then it can know with near-certainty that the [[transaction]] was made by you or the [[block]] was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.<br />
<br />
A certain kind of [[Weaknesses#Sybil_attack|sybil attack]] can be used to discover the source of a [[transaction]] or [[block]] without the adversary entirely controlling the victims internet connection. It works by the adversary creating many of their own fake nodes on different IP addresses which aggressively announce themselves in an effort to attract more nodes to connect to them, they also try to connect to as many other listening nodes as they can. This high connectivity help the adversary to locate the source newly-broadcasted transactions and blocks by tracking them as they propagate through the [[network]].<ref>https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/</ref><ref>Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. 2014. Deanonymisation of Clients in Bitcoin P2P Network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (CCS '14). ACM, New York, NY, USA, 15-29. DOI: 10.1145/2660267.2660379 https://arxiv.org/abs/1405.7418</ref><ref>Koshy, Philip & Koshy, Diana & McDaniel, Patrick. (2014). An Analysis of Anonymity in Bitcoin Using P2P Network Traffic. 8437. 469-485. 10.1007/978-3-662-45472-5_30. http://ifca.ai/fc14/papers/fc14_submission_71.pdf</ref><ref>https://github.com/bitcoin/bitcoin/issues/3828</ref>. Some wallets periodically rebroadcast their unconfirmed transactions so that they are more likely to propagate widely through the network and be [[Confirmation|mined]].<br />
<br />
Some wallets are not [[full node]]s but are lightweight nodes which function in a different way. They generally have far worse privacy properties, but how badly depends on the details of each wallet. Some [[Lightweight node|lightweight wallets]] can be connected only to your own [[full node]], and if that is done then their privacy with respect to traffic analysis will be improved to the level of a full node.<br />
<br />
=== Custodial Wallets ===<br />
<br />
Some bitcoin wallets are just front-ends that connects to a back-end server run by some company. This kind of wallet has no privacy at all, the operating company can see all the user's addresses and all their transactions, most of the time they'll see the user's IP address too. Users should not use web wallets.<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Wallet history retrieval from third-party ===<br />
<br />
All bitcoin wallets must somehow obtain information about their balance and history, which may leak information about which [[address]]es and [[transaction]]s belong to them.<br />
<br />
==== Blockchain explorer websites ====<br />
<br />
[[Block chain browser|Blockchain explorer websites]] are commonly used. Some users even search for their [[transaction]] on those websites and refresh it until it reaches 3 [[confirmation]]s. This is very bad for privacy as the website can easily link the user's IP address to their bitcoin transaction (unless [[tor]] is used), and the queries to their website reveal that the [[transaction]] or [[address]] is of interest to somebody who has certain behavioural patterns.<br />
<br />
To get information about your [[transaction]]s it is much better to use your wallet software, not some website.<br />
<br />
==== BIP 37 ====<br />
<br />
Many [[Lightweight node|lightweight wallets]] use the [[BIP_0037|BIP37]] standard, which has serious design flaws leading to privacy leaks. Any wallet that uses [[BIP_0037|BIP37]] provides no privacy at all and is equivalent to sending all the wallets addresses to a random server. That server can easily spy on the wallet. Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.<br />
<br />
Main article: [[BIP37 privacy problems]]<br />
<br />
==== Public Electrum servers ====<br />
<br />
[[Electrum]] is a popular software wallet which works by connecting to special purpose servers. These servers receive hashes of the bitcoin addresses in the wallet and reply with [[transaction]] information. The Electrum wallet is fast and low-resource but by default it connects to these servers which can easily spy on the user. Some other software aside from [[Electrum]] uses the public Electrum servers. As of 2019 it is a faster and better alternative for [[Lightweight node|lightweight wallets]] than BIP37.<br />
<br />
Servers only learn the hashes of addresses rather than addresses themselves, in practice they only know the actual address and associated transactions if it's been used on the blockchain at least once.<br />
<br />
It is not very difficult to [[Electrum#Server_software|run your own Electrum server]] and point your wallet to use only it. This restores [[Electrum]] to have the same privacy and security properties as a [[full node]] where nobody else can see which addresses or transactions the wallet is interested in. Then [[Electrum]] becomes a [[full node]] wallet.<br />
<br />
=== Communication eavesdropping ===<br />
<br />
A simple but effective privacy leak. Alice gives Bob one of her [[address]]es to receive a payment, but the communication has been eavesdropped by Eve who saw the [[address]] and now knows it belongs to Alice. The solution is to encrypt addresses where appropriate or use another way of somehow hiding them from an adversary as per the threat model.<br />
<br />
Sometimes the eavesdropping can be very trivial, for example some forum users publish a bitcoin donation address on their website, forum signature, profile, twitter page, etc where it can be picked up by search engines. In the example of the non-anonymous Chinese newspaper buyer from the introduction, his address being publicly visible on his forum signature was a crucial part of his deanonymization. The solution here is to show each potential donator a new address, for example [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|by setting up a web server to hand out unique addresses to each visitor]].<br />
<br />
=== Revealing data when transacting bitcoin ===<br />
<br />
Sometimes users may voluntarily reveal data about themselves, or be required to by the entity they interact with. For example many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
When buying goods online with bitcoin a delivery mail address is needed. This links the bitcoin transaction with the delivery address. The same applies to the user's IP address (unless privacy technology like [[Tor]] is used).<br />
<br />
=== Digital forensics ===<br />
<br />
Wallet software usually stores information it needs to operate on the disk of the computer it runs on. If an adversary has access to that disk it can extract bitcoin [[address]]es and [[transactions]] which are known to be linked with the owner of that disk. The same disk might contain other personal information (such as a scan of an ID card). Digital forensics is one reason why all good wallet software encrypts wallet files, although that can be beaten if a weak encryption password is used.<br />
<br />
For example if you have a bitcoin wallet installed on your PC and give the computer to a repair shop to fix, then the repair shop operator could find the wallet file and records of all your transactions. Other examples might be if an old hard disk is thrown away. Other software installed on the same computer (such as malware) can also read from disk or RAM to spy on the bitcoin transactions made by the user.<br />
<br />
For privacy don't leave data on your computer available to others. Exactly how depends on your threat model. Encryption and physical protection are options, as is using special operating systems like [https://tails.boum.org/ Tails OS] which does not read or write from the hard drive but only uses RAM, and then deletes all data on shutdown.<br />
<br />
== Methods for improving privacy (non-blockchain) ==<br />
<br />
=== Obtaining bitcoins anonymously ===<br />
<br />
If the adversary has not linked your bitcoin address with your identity then privacy is much easier. Blockchain spying methods like the [[common-input-ownership heuristic]], detecting [[change]] addresses and amount correlation are not very effective on their own if there is no starting point to link back to.<br />
<br />
Many exchanges require users to undergo Anti-Money Laundering and Know-Your-Customer (AML/KYC) checks, which requires users to reveal all kinds of invasive personal information such as their real name, residence, occupation and income. All this information is then linked with the bitcoin [[address]]es and [[transaction]]s that are later used.<br />
<br />
Avoiding the privacy invasion of AML/KYC is probably the single most important thing an individual can do to improve their privacy. It works far better than any actual technology like [[CoinJoin]]. Indeed all the cryptography and privacy tricks are irrelevant if all users only ever transact between AML/KYC institutions<ref>https://twitter.com/waxwing__/status/983258474040774657</ref>.<br />
<br />
==== Cash trades ====<br />
<br />
Physical cash is an anonymous medium of exchange, so using it is a way to obtain bitcoin anonymously where no one except trading partners exchange identifying data.<br />
<br />
This section won't list websites to find such meetups because the information can go out of date, but try searching the web with "buy bitcoin for cash <your location>". Note that some services still require ID so that is worth checking. Some services require ID only for the trader placing the advert. As of late-2018 there is at least one [[Bisq|decentralized exchange open source project]] in development which aims to facilitate this kind of trading without a needing a centralized third party at all but instead using a peer-to-peer network.<br />
<br />
'''Cash-in-person''' trades are an old and popular method. Two traders arrange to meet up somewhere and the buyer hands over cash while the seller makes a bitcoin transaction to the buyer. This is similar to other internet phenomena like Craigslist which organize meetups for exchange. [[Secure Trading#Use_an_Escrow_Service|Escrow can be used]] to improve safety or to avoid the need to wait for [[confirmation]]s at the meetup.<br />
<br />
'''Cash-by-mail''' works by having the buyer send physical cash through the mail. [[Secure Trading#Use_an_Escrow_Service|Escrow is always used]] to prevent scamming. The buyer of bitcoins can be very anonymous but the seller must reveal a mail address to the buyer. Cash-by-mail can work over long distances but does depend on the postal service infrastructure. Users should check with their local postal service if there are any guidelines around sending cash-by-mail. Often the cash can also be insured.<br />
<br />
'''Cash deposit''' is a method where the buyer deposits cash directly into the seller's bank account. Again [[Secure Trading#Use_an_Escrow_Service|escrow is used]], and again the buyer of bitcoins can be near-anonymous but the seller must sign up with a bank or financial institution and share with them rather invasive details about one's identity and financial history. This method relies on the personal banking infrastructure so works over long distances.<br />
<br />
'''Cash dead drop''' is a rarely used method. It is similar to a cash-in-person trade but the traders never meet up. The buyer chooses a location to hide the cash in a public location, next the buyer sends a message to the seller telling them the location, finally the seller picks up the cash from the hidden location. [[Secure Trading#Use_an_Escrow_Service|Escrow is a requirement]] to avoid scamming. This method is very anonymous for the buyer as the seller won't even learn their physical appearance, for the seller it is slightly less anonymous as the buyer can stalk the location to watch the seller collect the cash.<br />
<br />
==== Cash substitute ====<br />
<br />
Cash substitutes like gift cards, mobile phone credits or prepaid debit cards can often be bought from regular stores with cash and then traded online for bitcoin.<br />
<br />
==== Employment ====<br />
<br />
Bitcoins accepted as payment for work done can be anonymous if the employer does not request much personal information. This may work well in a freelancing or contracting setting. Although if your adversary is your own employer then obviously this is not good privacy.<br />
<br />
==== Mining ====<br />
<br />
Mining is the most anonymous way to obtain bitcoin. This applies to solo-mining as [[Pooled mining|mining pools]] generally know the hasher's IP address. Depending on the size of operation mining may use a lot of electrical power which may attract suspicion. Also the [[ASIC|specialized mining hardware]] may be difficult to get hold of anonymously (although they wouldn't be linked to the resulting mined bitcoins).<br />
<br />
==== Stealing ====<br />
<br />
In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref><br />
<br />
There is at least one situation where this happened. In May 2015 a hacker known as Phineas Fisher<ref>https://motherboard.vice.com/en_us/article/3k9zzk/hacking-team-hacker-phineas-fisher-has-gotten-away-with-it</ref> hacked a spyware company that was selling surveillance products to dictators<ref>https://motherboard.vice.com/en_us/article/nzeg5x/here-are-all-the-sketchy-government-agencies-buying-hacking-teams-spy-tech</ref>. The hacker used bitcoin stolen from other people to anonymously rent infrastructure for later attacks.<br />
<br />
=== Spending bitcoins anonymously ===<br />
<br />
If you give up your delivery address (which you'll have to if you're buying physical goods online) then that will be a data leak. Obviously this is unavoidable in many cases.<br />
<br />
=== Wallet history synchronization ===<br />
<br />
Bitcoin wallets must somehow obtain information about their balance and history. As of late-2018 the most practical and private existing solutions are to use a [[full node]] wallet (which is maximally private) and [[client-side block filtering]] (which is very good).<br />
<br />
One issue with these technologies is that they always costs more resources (time, bandwidth, storage, etc) than non-private solutions like web wallets and centralized [[Electrum]] servers. There are measurements indicating that very few people actually use [[BIP_0037|BIP37]] because of how slow it is<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016062.html</ref>, so even [[client-side block filtering]] may not be used very much.<br />
<br />
==== Full node ====<br />
<br />
[[Full node]]s download the entire blockchain which contains every on-chain [[transaction]] that has ever happened in bitcoin. So an adversary watching the user's internet connection [[Full node#Privacy|will not be able to learn]] which transactions or addresses the user is interested in. This is the best solution to wallet history synchronization with privacy, but unfortunately it costs a significant amount in time and bandwidth.<br />
<br />
==== Private information retrieval ====<br />
<br />
In cryptography, a private information retrieval (PIR) protocol is a protocol that allows a user to retrieve an item from a server in possession of a database without revealing which item is retrieved. This has been proposed as a way to private synchronize wallet history but as PIR is so resource-intensive, users who don't mind spending bandwidth and time could just run a [[full node]] instead.<br />
<br />
==== Client-side block filtering ====<br />
<br />
[[Client-side block filtering]] works by having filters created that contains all the [[address]]es for every [[transaction]] in a [[block]]. The filters can test whether an element is in the set; false positives are possible but not false negatives. A lightweight wallet would download all the filters for every block in the blockchain and check for matches with its own addresses. [[Block]]s which contain matches would be downloaded in full from the [[Network|peer-to-peer network]], and those blocks would be used to obtain the wallet's history and current balance.<br />
<br />
==== Address query via onion routing ====<br />
<br />
Wallet histories can be obtained from centralized servers (such as [[Electrum]] servers) but using a new Tor circuit for each address. A closely-related idea is to connect together [[Electrum]] servers in an onion-routing network<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009510.html</ref>. When creating such a scheme, care should be taken to avoid timing correlation linking the addresses together, otherwise the server could use the fact that the addresses were requested close to each other in time.<br />
<br />
=== Countermeasures to traffic analysis ===<br />
<br />
[[Bitcoin Core]] and its forks have countermeasures against [[Weaknesses#Sybil_attack|sybil attack]] and eclipse attacks. Eclipse attacks are sybil attacks where the adversary attempts to control all the peers of its target and block or control access to the rest of the network<ref>https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack</ref>. Such attacks have been extensively studied in a 2015 paper [https://eprint.iacr.org/2015/263.pdf Eclipse Attacks on Bitcoin’s Peer-to-Peer Network] which has led to new code written for [[Bitcoin Core]] for mitigation.<ref>https://github.com/bitcoin/bitcoin/pull/8282</ref><ref>https://github.com/bitcoin/bitcoin/pull/5941</ref><ref>https://github.com/bitcoin/bitcoin/pull/9037</ref><ref>https://github.com/bitcoin/bitcoin/pull/8594</ref><ref>https://github.com/bitcoin/bitcoin/pull/12626</ref><br />
<br />
[[Bitcoin Core]] and its forks use an algorithm known as trickling when relaying unconfirmed transactions, with the aim of making it as difficult as possible for sybil attackers to find the source IP address of a [[transaction]]. For each peer, the node keeps a list of transactions that it is going to [[Network#Messages|inv]] to it. It sends [[Network#Messages|inv's]] for transactions periodically with a random delay between each [[Network#Messages|inv]]. Transactions are selected to go into the [[Network#Messages|inv]] message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to [[Network#Messages|inv]]. The algorithm creates the possibility that a peered node may hear about an unconfirmed transaction from the creator's neighbours rather than the creator node itself<ref>https://bitcoin.stackexchange.com/questions/83018/transaction-relay-and-trickling-in-bitcoin</ref><ref>https://github.com/bitcoin/bitcoin/issues/13298</ref><ref>https://github.com/bitcoin/bitcoin/pull/7125</ref><ref>https://github.com/bitcoin/bitcoin/pull/7840</ref>. However adversaries can still sometimes obtain privacy-relevant information.<br />
<br />
Encrypting messages between peers as in [https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki BIP 151] would make it harder for a passive attacker such as an ISP or Wifi provider to see the exact messages sent and received by a bitcoin node.<br />
<br />
==== Tor and tor broadcasting ====<br />
<br />
If a connection-controlling adversary is a concern, then bitcoin can be run entirely over [[tor]]. [[Tor]] is encrypted and hides endpoints, so an ISP or Wifi providers won't even know you're using bitcoin. The other connected bitcoin nodes won't be able to see your IP address as [[tor]] hides it. [[Bitcoin Core]] and its forks have features to make setting up and using [[tor]] easier. Some [[Lightweight node|lightweight wallets]] also run entirely over [[tor]].<br />
<br />
Running entirely over [[tor]] has the downside that synchronizing the node requires downloading the entire blockchain over tor, which would be very slow. Downloading [[block]]s over Tor only helps in the situation where you want to hide the fact that bitcoin is even being used from the internet service provider<ref>https://bitcointalk.org/index.php?topic=7.msg264#msg264</ref>. It is possible to download [[blocks]] and unconfirmed [[transaction]]s over clearnet but broadcast your own [[transaction]]s over [[tor]], allowing a fast clearnet connection to be used while still providing privacy when broadcasting.<br />
<br />
[[Bitcoin Core]] being configured with the option <code>walletbroadcast=0</code> will stop [[transaction]]s belonging to the user from being broadcast and rebroadcast, allowing them to be broadcast instead via [[tor]] or another privacy-preserving method<ref>https://github.com/bitcoin/bitcoin/pull/5951</ref>.<br />
<br />
==== Dandelion ====<br />
<br />
Dandelion is another technology for private transaction broadcasting. The main idea is that transaction propagation proceeds in two phases: first the "stem" phase, and then "fluff" phase. During the stem phase, each node relays the transaction to a ''single'' peer. After a random number of hops along the stem, the transaction enters the fluff phase, which behaves just like ordinary transaction flooding/diffusion. Even when an attacker can identify the location of the fluff phase, it is much more difficult to identify the source of the stem.<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014571.html</ref><ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html</ref><ref>https://bitcoinmagazine.com/articles/anatomy-anonymity-how-dandelion-could-make-bitcoin-more-private/</ref><ref>https://www.youtube.com/watch?v=XORDEX-RrAI&t=7h34m35s</ref><br />
<br />
==== Interactive peer broadcasting ====<br />
<br />
Some privacy technologies like [[CoinJoin]] and [[CoinSwap]] require interactivity between many bitcoin entities. They can also be used to broadcast transactions with more privacy, because peers in the privacy protocols can send each other unconfirmed transactions using the already-existing protocol they use to interact with each other. <br />
<br />
For example, in [[JoinMarket]] market takers can send [[transaction]]s to market makers who will broadcast them and so improve the taker's privacy. This can be a more convenient for the taker than setting up [[Tor]] for use with [[#Tor_and_tor_broadcasting|tor broadcasting]].<br />
<br />
==== Receiving bitcoin data over satellite ====<br />
<br />
At least one bitcoin company offers a satellite bitcoin service<ref>https://blockstream.com/satellite/</ref>. This is a free service where satellites broadcast the bitcoin blockchain to nearly anywhere in the world. If users set up a dish antenna pointing at a satellite in space, then they can receive bitcoin blocks needed to run a [[full node]]. As the satellite setups are receive-only nobody can detect that the user is even running bitcoin, and certainly not which [[address]]es or [[transaction]]s belong to them.<br />
<br />
As of 2019 the company offers a paid-for API which allows broadcasting any data to anywhere in the world via satellite, which seems to be how they make their money. But it appears the base service of broadcasting the blockchain will always be free.<br />
<br />
Main article: https://blockstream.com/satellite/<br />
<br />
== Methods for improving privacy (blockchain) ==<br />
<br />
This section describes different techniques for improving the privacy of [[transaction]]s related to the permanent record of transactions on the blockchain. Some techniques are trivial and are included in all good bitcoin wallets. Others have been implemented in some open source projects or services, which may use more than one technique at a time. Other techniques have yet to be been implemented. Many of these techniques focus on breaking different heuristics and assumptions about the blockchain, so they work best when combined together.<br />
<br />
=== Avoiding [[address reuse]] ===<br />
<br />
[[Address]]es being used more than once is very damaging to privacy because that links together more blockchain [[transaction]]s with proof that they were created by the same entity. The most private and secure way to use bitcoin is to send a brand new address to each person who pays you. After the received coins have been spent the address should never be used again. Also, a brand new bitcoin address should be demanded when sending bitcoin. All good bitcoin wallets have a user interface which discourages [[address reuse]].<br />
<br />
It has been argued that the phrase "bitcoin address" was a bad name for this object because it implies it can be reused like an email address. A better name would be something like "bitcoin invoice".<br />
<br />
Bitcoin isn't anonymous but pseudonymous, and the pseudonyms are bitcoin addresses. Avoiding [[address reuse]] is like throwing away a pseudonym after its been used.<br />
<br />
[[Bitcoin Core]] 0.17 includes an update to improve the privacy situation with [[address reuse]]<ref>https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.17.0.md#partial-spend-avoidance</ref>. When an address is paid multiple times the coins from those separate payments can be spent separately which hurts privacy due to linking otherwise separate addresses. A -avoidpartialspends flag has been added (default=false), if enabled the wallet will always spend existing UTXO to the same address together even if it results in higher fees. If someone were to send coins to an address after it was used, those coins will still be included in future coin selections.<br />
<br />
==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====<br />
<br />
The easiest way to avoid the privacy loss from [[#Forced_address_reuse|forced address reuse]] to not spend coins that have landed on an already-used and empty addresses. Usually the payments are of a very low value so no relevant money is lost by simply not spending the coins.<br />
<br />
Dust-b-gone is an old project<ref>https://github.com/petertodd/dust-b-gone</ref> which aimed to safely spend forced-address-reuse payments. It signs all the UTXOs together with other people's and spends them to miner fees. The [[transaction]]s use rare [[OP_CHECKSIG]] sighash flags so they can be easily eliminated from the adversary's analysis, but at least the forced address reuse payments don't lead to further privacy loss.<br />
<br />
=== Coin control ===<br />
<br />
Coin control is a feature of some bitcoin wallets that allow the user to choose which [[Coin analogy|coins]] are to be spent as inputs in an outgoing [[transaction]]. Coin control is aimed to avoid as much as possible [[transaction]]s where privacy leaks are caused by amounts, change addresses, the transaction graph and the [[common-input-ownership heuristic]]<ref>https://medium.com/@octskyward/merge-avoidance-7f95a386692f</ref><ref>https://medium.com/@nopara73/coin-control-is-must-learn-if-you-care-about-your-privacy-in-bitcoin-33b9a5f224a2</ref>.<br />
<br />
An example for avoiding a transaction graph privacy leak with coin control: A user is paid bitcoin for their employment, but also sometimes buys bitcoin with cash. The user wants to donate some money to a charitable cause they feel passionately about, but doesn't want their employer to know. The charity also has a publicly-visible donation address which can been found by web search engines. If the user paid to the charity without coin control, his wallet may use [[Coin analogy|coins]] that came from the employer, which would allow the employer to figure out which charity the user donated to. By using coin control, the user can make sure that only [[Coin analogy|coins]] that were obtained anonymously with cash were sent to the charity. This avoids the employer ever knowing that the user financially supports this charity.<br />
<br />
=== Multiple transactions ===<br />
<br />
Paying someone with more than one on-chain [[transaction]] can greatly reduce the power of amount-based privacy attacks such as amount correlation and round numbers. For example, if the user wants to pay 5 BTC to somebody and they don't want the 5 BTC value to be easily searched for, then they can send two transactions for the value of 2 BTC and 3 BTC which together add up to 5 BTC.<br />
<br />
Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.<br />
<br />
=== Change avoidance ===<br />
<br />
Change avoidance is where transaction inputs and outputs are carefully chosen to not require a change output at all. Not having a change output is excellent for privacy, as it breaks change detection heuristics.<br />
<br />
Change avoidance is practical for high-volume bitcoin services, which typically have a large number of inputs available to spend and a large number of required outputs for each of their customers that they're sending money to. This kind of change avoidance also lowers [[miner fees]] because the transactions uses less block space overall.<br />
<br />
Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]<br />
<br />
Another way to avoid creating a change output is in cases where the exact amount isn't important and an entire UTXO or group of UTXOs can be fully-spent. An example is when opening a [[Lightning Network]] [[payment channel]]. Another example would be when sweeping funds into a [[cold storage]] wallet where the exact amount may not matter.<br />
<br />
=== Multiple change outputs ===<br />
<br />
If [[#Change_avoidance|change avoidance]] is not an option then creating more than one change output can improve privacy. This also breaks change detection heuristics which usually assume there is only a single change output. As this method uses more block space than usual, change avoidance is preferable.<br />
<br />
=== Script privacy improvements ===<br />
<br />
The [[Script|script]] of each bitcoin output leaks privacy-relevant information. For example as of late-2018 around 70% of bitcoin addresses are single-signature and 30% are [[multisignature]]<ref>https://p2sh.info/</ref>. Much research has gone into improving the privacy of scripts by finding ways to make several different script kinds look the same. As well as improving privacy, these ideas also improve the scalability of the system by reducing storage and bandwidth requirements.<br />
<br />
'''ECDSA-2P''' is a cryptographic scheme which allows the creation of a 2-of-2 [[multisignature]] scheme but which results in a regular single-sig [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature when included on the blockchain<ref>Scaling Bitcoin conference 2018 Tokyo. Conner Fromknecht (Lightning Labs)<br />
Instantiating [Scriptless] 2P-ECDSA: Fungible 2-of-2 MultiSigs for Today's Bitcoin. https://www.youtube.com/watch?v=3mJURLD2XS8&t=3623 https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/</ref>. It doesn't need any consensus changes because bitcoin already uses [[Elliptic Curve Digital Signature Algorithm|ECDSA]].<br />
<br />
'''[[Schnorr]]''' is a digital signature scheme which has many benefits over the status-quo [[Elliptic Curve Digital Signature Algorithm|ECDSA]]<ref>https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744</ref><ref>https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</ref>. One side effect is that any N-of-N<ref>https://blockstream.com/2018/01/23/musig-key-aggregation-schnorr-signatures/</ref> and M-of-N [[multisignature]] can be easily made to look like a single-sig when included on the blockchain. Adding [[Schnorr]] to bitcoin requires a [[Softfork]] consensus change. As of 2019 a design for the signature scheme has been proposed<ref>https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</ref>. The required [[softfork]] consensus change is still in the design stage as of early-2019.<br />
<br />
'''[[Scriptless scripts]]''' are a set of cryptographic protocols which provide a way of replicating the logic of [[script]] without actually having the script conditions visible, which increases privacy and scalability by removing information from the blockchain<ref>https://bitcoinmagazine.com/articles/scriptless-scripts-how-bitcoin-can-support-smart-contracts-without-smart-contracts/</ref><ref>https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf</ref><ref>https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html</ref>. This is generally aimed at protocols involving [[Hash Time Locked Contracts]] such as [[Lightning Network]] and [[CoinSwap]].<br />
<br />
With scriptless scripts, nearly the only thing visible is the public keys and signatures. More than that, in multi-party settings, there will be a single public key and a single signature for all the actors. Everything looks the same-- [[Lightning Network|lightning]] [[payment channels]] would look the same as single-sig payments, escrows, [[atomic swap]]s, or sidechain federation pegs. Pretty much anything you think about that people are doing on bitcoin in 2019, can be made to look essentially the same<ref>http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
'''MAST''' is short for Merkelized Abstract Syntax Tree, which is a scheme for hiding unexecuted branches of a [[script]] contract. It improves privacy and scalability by removing information from the blockchain<ref>https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f</ref><ref>https://bitcoinmagazine.com/articles/the-next-step-to-improve-bitcoin-s-flexibility-scalability-and-privacy-is-called-mast-1476388597/</ref>.<br />
<br />
'''Taproot''' is a way to combine Schnorr signatures with MAST<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html</ref>. The Schnorr signature can be used to spend the coin, but also a MAST tree can be revealed only when the user wants to use it. The schnorr signature can be any N-of-N or use any scriptless script contract. The consequence of taproot is a much larger anonymity set for interesting smart contracts, as any contract such as [[Lightning Network]], [[CoinSwap]], [[multisignature]], etc would appear indistinguishable from regular single-signature on-chain transaction.<br />
<br />
The taproot scheme is so useful because it is almost always the case that interesting scripts have a logical top level branch which allows satisfaction of the contract with nothing other than a signature by all parties. Other branches would only be used where some participant is failing to cooperate.<br />
<br />
'''Graftroot''' is a smart contract scheme similar to taproot. It allows users to include other possible [[script]]s for spending the coin but with less resources used even than taproot. The tradeoff is that interactivity is required between the participants<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html</ref><ref>https://www.reddit.com/r/Bitcoin/comments/7vcyip/graftroot_private_and_efficient_surrogate_scripts/</ref><ref>https://bitcoinmagazine.com/articles/graftroot-how-delegating-signatures-allows-near-infinite-spending-variations/</ref>.<br />
<br />
'''[[nLockTime]]''' is a field in the serialized [[transaction]] format. It can be used in certain situations to create a more private [[timelock]] which avoids using [[script]] opcodes.<br />
<br />
=== ECDH addresses ===<br />
<br />
[[ECDH address]]es can be used to improve privacy by helping avoid [[address reuse]]. For example, a user can publish a [[ECDH address]] as a [[Receiving donations with bitcoin|donation address]] which is usable by people who want to donate. An adversary can see the ECDH donation address but won't be able to easily find any [[transaction]]s spending to and from it.<br />
<br />
However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[Mystery_shopper_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.<br />
<br />
ECDH addresses have [[ECDH address|some practicality issues]] and are very closely equivalent to [[Receiving_donations_with_bitcoin#Improving_privacy_by_avoiding_address_re-use|running a http website which hands out bitcoin addresses to anybody who wants to donate]] except without an added step of interactivity. It is therefore unclear whether ECDH are useful outside the use-case of non-interactive donations or a self-contained application which sends money to one destination without any interactivity.<br />
<br />
=== Centralized mixers ===<br />
<br />
This is an old method for breaking the [[#Transaction graph|transaction graph]]. Also called "tumblers" or "washers". A user would send bitcoins to a [[mixing service]] and the service would send different bitcoins back to the user, minus a fee. In theory an adversary observing the blockchain would be unable to link the incoming and outgoing [[transaction]]s.<br />
<br />
There are several downsides to this. The mixer it must be trusted to keep secret the linkage between the incoming and outgoing transactions. Also the mixer must be trusted not to steal coins. This risk of stealing creates reputation effects; older and more established mixers will have a better reputation and will be able to charge fees far above the marginal cost of mixing coins. Also as there is no way to sell reputation, the ecosystem of mixers will be filled with occasional exit scams.<br />
<br />
There is a better alternative to mixers which has essentially the same privacy and custody risks. A user could deposit and then withdraw coins from any regular bitcoin website that has a hot wallet. As long as the bitcoin service doesn't require any other information from the user, it has the same privacy and custody aspects as a centralized mixer and is also much cheaper. Examples of suitable bitcoin services are bitcoin casinos, bitcoin poker websites, tipping websites, altcoin exchanges or online marketplaces<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref>.<br />
<br />
The problem of the service having full knowledge of the transactions could be remedied by cascading several services together. A user who wants to avoid tracking by passive observers of the blockchain could first send coins to a bitcoin casino, from them withdraw and send directly to an altcoin exchange, and so on until the user is happy with the privacy gained.<br />
<br />
Main article: [[Mixing service]]<br />
<br />
=== CoinJoin ===<br />
<br />
[[CoinJoin]] is a special kind of bitcoin transaction where multiple people or entities cooperate to create a single transaction involving all their inputs. It has the effect of breaking the [[common-input-ownership heuristic]] and it makes use of the [[Coin_analogy#Fungibility|inherent fungibility of bitcoin within transactions]]. The [[CoinJoin]] technique has been possible since the very start of bitcoin and cannot be blocked except in the ways that any other bitcoin [[transaction]]s can be blocked. Just by looking at a transaction it is not possible to tell for sure whether it is a coinjoin. CoinJoins are non-custodial as they can be done without any party involved in a coinjoin being able to steal anybody else's bitcoins<ref>https://www.reddit.com/r/joinmarket/comments/3c7hnm/joinmarket_is_smart_contracts/</ref>.<br />
<br />
==== Equal-output CoinJoin ====<br />
<br />
Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.<br />
<br />
2 btc --> 3 btc<br />
3 btc 2 btc<br />
<br />
This transaction breaks the [[common-input-ownership heuristic]], because its inputs are not all owned by the same person but it is still easy to tell where the bitcoins of each input ended up. By looking at the amounts (and assuming that the two entities do not pay each other) it is obvious that the 2 BTC input ends up in the 2 BTC output, and the same for the 3 BTC. To really improve privacy you need [[CoinJoin]] transaction that have a more than one equal-sized output:<br />
<br />
2 btc --> 2 btc<br />
3 btc 2 btc<br />
1 btc<br />
<br />
In this [[transaction]] the two outputs of value 2 BTC cannot be linked to the inputs. They could have come from either input. This is the crux of how [[CoinJoin]] can be used to improve privacy, not so much breaking the transaction graph rather fusing it together. Note that the 1 BTC output has not gained much privacy, as it is easy to link it with the 3 BTC input. The privacy gain of these CoinJoins is compounded when the they are repeated several times.<br />
<br />
As of late-2018 [[CoinJoin]] is the only decentralized bitcoin privacy method that has been deployed. Examples of (likely) [[CoinJoin]] transactions IDs on bitcoin's blockchain are <code>402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a</code> and <code>85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238</code>. Note that these coinjoins involve more than two people, so each individual user involved cannot know the true connection between inputs and outputs (unless they collude).<br />
<br />
==== PayJoin ====<br />
<br />
The type of [[CoinJoin]] discussed in the previous section can be easily identified as such by checking for the multiple outputs with the same value. It's important to note that such identification is always deniable, because somebody could make fake [[CoinJoin]]s that have the same structure as a coinjoin transaction but are made by a single person.<br />
<br />
PayJoin (also called pay-to-end-point or P2EP)<ref>https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/</ref><ref>https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6</ref><ref>https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e</ref> is a special type of [[CoinJoin]] between two parties where one party pays the other. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]]. Consider this transaction:<br />
<br />
2 btc --> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple transaction paying to somewhere with leftover change (ignore for now the question of which output is payment and which is [[change]]). Another way to interpret this transaction is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a coinjoin transaction that breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin transaction.<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[transaction surveillance company|transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
=== CoinSwap ===<br />
{{Main|CoinSwap}}<br />
'''CoinSwap''' is a non-custodial privacy technique for bitcoin based on the idea of [[atomic swap]]s<ref>https://joinmarket.me/blog/blog/coinswaps/</ref>. If Alice and Bob want to do a coinswap; then it can be understood as Alice exchanging her bitcoin for the same amount (minus fees) of Bob's bitcoins, but done with [[Contracts|bitcoin smart contracts]] to eliminate the possibility of cheating by either side.<br />
<br />
[[CoinSwap]]s break the transaction graph between the sent and received bitcoins. On the [[block chain]] it looks like two sets of completely disconnected transactions:<br />
<br />
Alice's Address ---> escrow address 1 ---> Bob's Address<br />
Bob's Address ---> escrow address 2 ---> Alice's Address<br />
<br />
Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].<br />
<br />
It is possible to have CoinSwaps that are completely indistinguishable from any other transaction on the blockchain. They could be said to allow bitcoins to teleport undetectably to anywhere else on the blockchain. Non-CoinSwap transactions would benefit because a large-scale analyst of the blockchain like a [[transaction surveillance company]] could never be sure that ordinary transactions are not actually [[CoinSwap]]s. They also do not require much block space compared to the amount of privacy they provide.<br />
<br />
CoinSwaps require a lot of interaction between the involved parties, which can make this kind of system tricky to design while avoiding denial-of-service attacks. They also have a liveness requirement and non-censorship requirement, meaning that the entities taking part must always be able to freely access the bitcoin network; If the internet was down for days or weeks then half-completed CoinSwaps could end with one side having their money stolen.<br />
<br />
As of May 2020, no CoinSwap implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>, but in June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref><br />
<br />
=== CoinJoinXT ===<br />
<br />
CoinJoinXT is non-custodial privacy technique which is closely related to [[CoinJoin]]<ref>https://joinmarket.me/blog/blog/coinjoinxt/</ref>. It allows for any number of entities to between them create a so-called ''proposed transaction graph'' (PTG) which is a list of connected transactions. In the PTG the bitcoins belonging to the entities are sent to and fro in all the transactions, but at the end of the PTG they are all returned to their rightful owners. The system is set up so that the process of the PTG being mined is atomic, so either the entire PTG is [[Confirmation|confirmed]] on the blockchain or none of it is, this means none of the participating entities can steal from each other.<br />
<br />
The ''proposed transaction graph'' has the freedom to be any list of transactions that obfuscate the transaction graph. For best results the PTG would perfectly mimic the natural transaction graph due to normal economic activity in bitcoin, and so an adversary would not know where the PTG started or ended, resulting in a massive privacy gain.<br />
<br />
Like [[CoinJoin]], CoinJoinXT is easy to make DOS-resistant and doesn't require a prohibitive number of interaction steps. Unlike [[CoinSwap]] there is no liveness or non-censorship requirement so funds are secure even if bitcoin is under temporary censorship. However CoinJoinXT uses a lot of block space compared the privacy gain. And CoinJoinXT requires a malleability fix so all the transactions in the PTG have to be [[Segregated Witness|segwit]]-only. As of 2019 only around 40% of transactions are segwit, so an observer of the blockchain could easily eliminate non-PTG transactions by checking whether they are legacy or segwit.<br />
<br />
=== TumbleBit ===<br />
<br />
[[TumbleBit]] is privacy technology which is non-custodial and where the coordinating server cannot tell the true linkage between input and output. This is achieved by a cryptographic construct where the server facilitates a private exchange of digital signatures. The protocol is very interesting to any privacy and bitcoin enthusiast.<br />
<br />
From the point of view of an observer of the blockchain, TumbleBit transactions appear as two transactions with many (800 in the author's example) outputs and all transaction outputs must be of the same amount.<br />
<br />
=== Off-chain transactions ===<br />
<br />
Off-chain transactions refer to any technology which allows bitcoin transactions on a layer above the blockchain. Bitcoin payments done off-chain are not broadcast to every node in the network and are not mined and stored forever on a public blockchain, this automatically improves privacy because much less information is visible to most adversaries. With [[Off-Chain Transactions]] there are no public addresses, no address clusters, no public transactions, no transaction amounts or any other privacy-relevant attacks that happen with on-chain transactions.<br />
<br />
Main article: [[Off-Chain Transactions]]<br />
<br />
'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].<br />
<br />
==== Blinded bearer certificates ====<br />
<br />
This is another way of doing [[Off-Chain Transactions]] which is based on blind signatures. The payments through such a system would be very very private. It has been known about since 1983. But the system is custodial so as the issuing server is a central point of failure which can steal all the money. However the concept may still be useful in certain situations where Lightning is not, for example blinded bearer certificates support payments where the receiver is offline.<br />
<br />
Main article: [[Blinded bearer certificates]]<br />
<br />
==== Sidechains ====<br />
<br />
[[Sidechain]]s are when another blockchain is created which uses bitcoins as its currency unit. Bitcoins can be moved from the main bitcoin blockchain onto the sidechain which allows them to transact following different consensus rules. Sidechains can have different and better privacy properties than the regular bitcoin blockchain.<br />
<br />
Main article: [[Sidechain]]<br />
<br />
=== Confidential transactions ===<br />
<br />
[[Confidential transactions]] (CT) is a cryptographic protocol which results in the amount value of a transaction being encrypted. The encryption is special because it is still possible to verify that no bitcoins can been created or destroyed within a [[transaction]] but without revealing the exact transaction amounts. Confidential transactions requires a [[softfork]] consensus change to be added to bitcoin, although they could be added to a [[sidechain]] too.<br />
<br />
Main article: [[Confidential transactions]]<br />
<br />
=== Discussion ===<br />
<br />
==== Privacy vs scalability ====<br />
<br />
Many of the previously-mentioned privacy technologies work by adding extra data to the bitcoin blockchain which is used to hide privacy-relevant information. This has the side-effect of degrading the scalability of bitcoin by adding more data which must be handled by system. This harms privacy because [[full node]]s become more resource-costly to run and they are the most private way for a user to learn their history and balance. Adding data to blocks also [[Full_node#Economic_strength|degrades the security of the system]], and there isn't much point in having a private bitcoin if the poor security leads to it being successfully attacked and destroyed. The resource cost of using more block space is shown to the user as a higher [[Miner fees|miner fee]]; so privacy technology which uses too much block space may not even be used much if users find the fees too expensive. During the [[Miner_fees#The_market_for_block_space|period of high block space demand]] in late-2017, low-value [[JoinMarket]] CoinJoin transactions mostly disappeared (as did most low-valued bitcoin transactions).<br />
<br />
[[Off-Chain Transactions]] are one way to avoid this trade-off between privacy and scalability. These kind of solutions improve privacy by entirely removing data from the blockchain, not by adding more decoy data. [[#Change avoidance|Change avoidance]] and [[#Script privacy improvements|Script privacy improvements]] also reduce costs to the system while improving privacy. [[CoinJoinXT]], equal-output [[CoinJoin]], [[TumbleBit]] use a lot of block space relative to the privacy gain. [[PayJoin]] does not use much extra block space over making an ordinary transaction; relative to the gain of breaking the [[common-input-ownership heuristic]] it is very space-efficent. [[CoinSwap]] uses very little block space relative to privacy, as it can be understood as an [[Off-Chain Transactions|off-chain transaction]] system which makes a single transaction and then comes back on-chain. [[Confidential transactions]] requires a lot of block space along with associated bandwidth and CPU costs, but its privacy gain is substantial, so the debate on that topic could go either way.<br />
<br />
In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.<br />
<br />
==== Steganography ====<br />
<br />
Steganography is used in cryptography to mean the act of hiding the fact that something is being hidden. For example the content of an encrypted message cant be read by an eavesdropper but it still shows that something is being hidden. Steganographic encryption of a message can be done by embedding an encrypted message into an audio file or image which hides the message in the noise.<br />
<br />
An equal-output [[CoinJoin]] hides the source and destination of a certain coin, but the structure of the transactions reveals that something is being hidden. So even though coinjoin breaks the [[common-input-ownership heuristic]], the fact that equal-output coinjoins can be detected (even if the detection is imperfect) allows them to be excluded from by the adversary's analysis. Also the distinguishability of the coinjoins may attract suspicion and prompt more investigation.<br />
<br />
The idea of steganography is a good thing to aim for<ref>https://joinmarket.me/blog/blog/the-steganographic-principle/</ref>. It greatly increases the privacy because the transactions made by such technology cannot be distinguished from regular transactions. Also it improves the privacy of users who don't even use the technology, as their transactions can always be confused with actual private transactions. [[Scriptless scripts]] are a great example of a steganographic privacy technology where the privacy-relevant information is hidden in the random numbers of the digital signatures. [[PayJoin]], [[CoinSwap]] and [[CoinJoinXT]] are good steganographic privacy technologies because they can be made indistinguishable from regular bitcoin transactions. Equal-output coinjoins and [[TumbleBit]] are not steganographic. Also it is usually easy to see when a centralized [[Mixing service]] is being used with [[common-input-ownership heuristic]] analysis, but depositing and then withdrawing from a high-volume bitcoin website like a casino or altcoin exchange is better because its possible that the user simply wanted to gamble.<br />
<br />
== Lightning Network ==<br />
<br />
[[Lightning Network]] is an [[Off-Chain Transactions|off-chain transaction]] technology based on [[payment channels]]. It has nearly the same security model as bitcoin on-chain transactions. It is not an overstatement to say that Lightning Network is a revolution for bitcoin. See the previous section on [[#Off-chain transactions]].<br />
<br />
As well as greatly improving privacy, [[Lightning Network]] transactions are also much faster (usually instant) and cheaper than on-chain transactions. Lightning nodes create two-way [[payment channels]] between them, and lightning transactions are routed from one node to another. The source and destination node don't need to have a payment channel directly between them as transactions can be routed over many intermediate nodes.<br />
<br />
As [[Lightning Network]] transactions happen off-chain, they are not broadcast to every node in the network and are not stored forever in a publicly-visible blockchain. Adversaries cannot look at a public permanent record of all transactions because there isn't one. Instead adversaries would possibly have to run intermediate nodes and possibly extract information that way. On-chain privacy attacks like the [[common-input-ownership heuristic]], [[address reuse]], change address detection, input amounts revealing sender wealth or mystery shopper payments fundamentally don't work because there are no [[address]]es or transaction inputs/outputs that work in the same way.<br />
<br />
However [[Lightning Network]] may introduce other privacy problems, mostly due to how the network is made up of nodes having [[Payment channel|connections]] between them<ref>https://www.reddit.com/r/Bitcoin/comments/7t1q5x/deanonymization_risks_on_lightning_network/</ref>. The parts of this network which can be intermediate routing nodes are usually public, and this network information could be overlaid with information about routed packets such as their amount. Lightning nodes also reveal their IP addresses unless run over Tor, and the payment channels are made up of on-chain transactions which could be analyzed using regular blockchain analysis techniques. Payment channels look like 2-of-2 [[multisignature]] on the blockchain. Bilaterial closing transactions look like the 2-of-2 outputs have been spent, but unilateral close transactions have a complicated [[Hash Time Locked Contracts|HTLC]] [[script]]s that is visible on the blockchain.<br />
<br />
As of 2019 Lightning is in beta and development continues; the development community is still studying all its privacy properties. Certainly its privacy is better than the privacy of on-chain [[transaction]]s.<br />
<br />
=== Onion routing ===<br />
<br />
The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md<br />
</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/</ref> to improve privacy from the intermediate routing notes. The protocol is aimed to prevent intermediate nodes along a payment route learning which other nodes, besides their predecessor or successor, are part of the packet's route; it also aims to hide the length of the route and the node's position within it.<br />
<br />
==== Onion routing overlaid with network topology ====<br />
<br />
Lightning Network's onion routing is usually compared with [[Tor]] onion routing. However, Tor's network is fully-connected; every node on Tor is directly connected (or has the potential to directly connect) with every other node, meaning that an onion-routed packet can be relayed from and to potentially any other node. This is not so in the Lightning Network, where [[payment channels]] do not fully-connect the entire network, and where the network topology is publicly known for routing nodes. Data fusion of the network topology and the small amount of information from onion-routed packets may still be enough to uncover information in certain cirumstances<ref>https://www.reddit.com/r/Bitcoin/comments/7rrjp3/is_onion_routing_appropriate_for_lightning_network/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/8hwzbh/chainalysis_on_the_ln/</ref>. For example, if a Lightning node wallet has only a single [[payment channel]] connection going to one intermediate node, then any payments sent to and from the node wallet will have to pass through the intermediate node, which would be able to obtain a lot of information about the wallet node's payments regardless of the onion-routing used.<br />
<br />
A mitigation to this topology problem may be that the entire topology of the Lightning Network is not known. Only nodes which intend to route transactions need to be publicly announced. It is possible for "private channels" to exist which are [[payment channels]] that exist, but whose existence is not published.<br />
<br />
This doesn't mean the onion routing used by [[Lightning Network]] is useless, far from it, but the privacy is not as strong as with [[Tor]].<br />
<br />
==== Rendez-vous routing ====<br />
<br />
Onion routing from the sender still requires that the destination Lightning node is known to the sender (along with all associated information like channel UTXO). This would mean that a user cannot receive Lightning payments without revealing one or more UTXOs associated with their [[payment channel]]s. A solution is rendez-vous routing<ref>https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx</ref><ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001498.html</ref>, also called Hidden Destinations<ref>https://bitcoinops.org/en/newsletters/2018/11/20/</ref>, which allow Lightning payments to be sent from a source node to destination node without either the source or destination needing to reveal their nodes and associated information.<br />
<br />
A good analogy is that source onion routing is like a [[Tor]] connection going via a Tor exit node to its destination, and rendez-vous onion routing is like a Tor connection going to a Tor hidden service.<br />
<br />
=== Atomic Multipath Payments ===<br />
<br />
Atomic Multipath Payments (AMP) is a protocol in Lightning which allows a single payment to be routed over multiple lightning network transactions<ref>https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html</ref>. For example if a user has five channels each with balance 2 btc, they can send a single payment of 7 btc using the AMP protocol over multiple lightning network paths. In terms of privacy, AMP would result in intermediate nodes not observing the full payment amount of 7 btc but only the partial payment amounts of 2 btc or 1 btc (or any other combination). This is positive for privacy as routed payments would no longer leak the exact payment amount, but only a lower bound.<br />
<br />
=== Common hashlock value ===<br />
<br />
For non-AMP payments, the payment hash is the same for all nodes along the route of a payment. This could allow multiple nodes if they co-operate to know that they routed the same payment based on this common hash value. Although this could also be done using the timestamp of each routed payment.<br />
<br />
[[Scriptless scripts]] used as a replacement to explicit [[Hash Time Locked Contracts|hash time locked contracts]] can be used to solve the common hashlock problem. It is possible to add a different random tweak value to the committed random value at each step, as a result there can be a multi-hop path through payment channels in which individual participants in the path wouldn't be able to tell that they're in the same path unless they're directly connected because of this re-blinding<ref>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.<br />
<br />
A 2017 paper called Concurrency and Privacy with Payment-Channel Networks<ref>Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, and Srivatsan Ravi. 2017. Concurrency and Privacy with Payment-Channel Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS '17). ACM, New York, NY, USA, 455-471. DOI: https://doi.org/10.1145/3133956.3134096 https://eprint.iacr.org/2017/820.pdf</ref><ref>https://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/concurrency-and-privacy-with-payment-channel-networks/</ref> writes about a scheme using zero-knowledge proofs which would allow each hash value in the payment route to be different. The scheme is much more expensive in terms of computation, but it may still be practical.<br />
<br />
=== Custodial wallets ===<br />
<br />
Lightning-enabled wallets can be of the custodial type, where the wallet is just a front-end that connects to a back-end server run by some company. This is the same situation for web wallets in the on-chain bitcoin ecosystem.<br />
<br />
This kind of setup would result in all the user's [[Lightning Network]] transactions being visible to that company and so they would have no privacy, in the same way that using a web wallet has no privacy for the on-chain bitcoin space. As of 2019 Zap Wallet and Lightning Peach work on this model. Peach wallet actually has checkboxes in its GUI saying "I agree to the privacy policy" and looking through the privacy policy reveals the wallet tracks all kinds of privacy-relevant stuff. Needless to say a privacy-conscious user shouldn't use these kind of lightning wallets but use non-custodial lightning wallets instead<ref>See first 20 minutes of this: https://www.youtube.com/watch?v=H1yPkPXLDVc</ref>.<br />
<br />
Lightning-enabled wallets still need to interface with the underlying bitcoin network, which can leak privacy-relevant information if done incorrectly. For example, if the wallet obtains blockchain transaction information from a centralized server then that server can spy on all the channel opening and closing transaction. Privacy-aware lightweight wallets usually make use of [[Client-side block filtering]] which is a very good fit for [[Lightning Network]]-enabled wallets.<br />
<br />
=== Private script types ===<br />
<br />
Advances in script type privacy like [[Schnorr]], scriptless scripts, taproot and ECDSA-2P benefit [[Lightning Network]] privacy by making its [[payment channel]] blockchain transactions appear indistinguishable from regular single-signature blockchain transactions.<br />
<br />
=== Probing payments to reveal channel states ===<br />
<br />
The balance state of each channel is hidden from the public and is only known to the two entities making up the [[payment channel]]. This provides a lot of privacy, as amounts and changes of the amounts are not visible to all. A possible way to defeat this privacy is for an active adversary to send probing payments until the balance is obtained. Such attack has been proved possible, as described in a paper from the beginning of 2019<ref>Jordi Herrera-Joancomartí, Guillermo Navarro-Arribas, Alejandro Ranchal-Pedrosa, Cristina Pérez-Solà, Joaquin Garcia-Alfaro (2019), "On the Difficulty of Hiding the Balance of Lightning Network Channels" IACR Cryptology ePrint Archive: https://eprint.iacr.org/2019/328</ref>, due to the level of detail that lightning implementations provide about routing errors. Although it would seem that such attack would need to pay the routing fees for the probing payments, the attacker may provide a fake invoice, so even when the payment passes through all the route, the last node will send back an error message and will not be able to execute the payment. So the cost for such attack is reduced to the fees needed to open and close the channels used for the attack.<br />
<br />
Such an attack can be used for disclosing the balances of a single or a selected group of nodes of the network and even on a large scale to obtain the balance of each channel in the network. In case the adversary repeats this procedure for every [[payment channel]] in the entire [[Lightning Network]] and continues probing very frequently, then by watching the change in channel states, they could observe payment being routed around the network. A possible way to remedy this attack would be for routing nodes to randomly (for example 1-out-of-20 times) return a routing error even if the channel balance state is actually adequate. This likely would not degrade the user experience of [[Lightning Network]] much, but would impose a serious cost on the attacker.<br />
<br />
== Existing privacy solutions ==<br />
<br />
This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.<br />
<br />
Privacy cannot be easily separated from any other aspect of bitcoin. It is unusual to have entirely separate solutions only for privacy, the dream is that one day all bitcoin wallets will include privacy tech already built in. But as of late-2018 many privacy implementations are separate applications.<br />
<br />
=== Lightning Network ===<br />
<br />
There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.<br />
<br />
The network itself can be used on bitcoin mainnet and several merchants and other projects accept it. It is still not usable by the general public. It is expected that one day every bitcoin wallet will be able to send and receive lightning network transactions and so the massive privacy benefits will be included in how regular users use bitcoin all the time.<br />
<br />
[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].<br />
<br />
Some LN wallets such as Zap Wallet and Lightning Peach are actually custodial, they are backed by a centralized server which can spy on everything the user does, so they should be avoided.<br />
<br />
=== Handmade CoinJoin ===<br />
<br />
[[CoinJoin]] transactions can be hand-made without a special wallet just using [[Raw Transactions]]. This can be very flexible as the coinjoins can take any number of forms. It might be practical in between bitcoin merchants, several of whom might decide to coinjoin together some of their transactions so that the [[common-input-ownership heuristic]] would imply they are all the same wallet cluster.<br />
<br />
=== JoinMarket ===<br />
<br />
[[JoinMarket]] is an implementation of [[CoinJoin]] where the required liquidity is paid for in a market. In JoinMarket terminology there are ''liquidity taker'' users who can create a coinjoin for whatever amount they want at any time, they also pay a small coinjoin fee. ''Liquidity makers'' are online 24 hours a day and are ready to create a coinjoin at any time for any amount they can, in return they earn coinjoin fees from liquidity takers. Because of this market for coinjoins, JoinMarket users can create coinjoins at any time and for any amount (up to a limit based on available liquidity).<br />
<br />
Other people are always available for coinjoining because they earn fees, and coinjoins can be of any amount and happen at any time. [[JoinMarket]] can also be a small source of income for operators of liquidity maker bots, who earn coinjoin fees by allowing other people to create coinjoins with their bitcoins.<br />
<br />
Privacy is greatly improved by repeating coinjoins many times, for this reason the [[JoinMarket]] project includes the tumbler script where coinjoins are automatically created at random times and for random amounts. Bitcoins can be deposited into the JoinMarket [[Deterministic wallet|HD wallet]] and the tumbler script will send them via many coinjoins to three or more destination [[address]]es. This feature of using more than one destination address is required to beat amount correlation. For example a user who wants to deposit coins into an exchange would make use of the ''Generate New Deposit Address'' button to obtain more than one destination [[address]], the exchange may then combine those coins with deposits from other customers which should resist any tracking based on amounts.<br />
<br />
JoinMarket can interface with a [[Bitcoin Core]] full node in order to privately obtain the history of its own wallet. There is also an option to use [[Electrum]] server, but users are discouraged from using it. There are plans to replace the Electrum interface with one that uses [[Client-side block filtering]].<br />
<br />
The software is an open source project with a community based around it. Unfortunately JoinMarket can be difficult to install for people not used to Linux or the command line interface. It is hoped one day there may be work done to make this easier, but as all development is done by volunteers there can be no roadmap for this.<br />
<br />
Main article: [[JoinMarket]]<br />
<br />
=== Wasabi Wallet ===<br />
<br />
'''Wasabi Wallet''' is an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.<br />
<br />
The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.<br />
<br />
Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and 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.<br />
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 rules of Bitcoin.<br />
<br />
In addition to this, it has advanced cutting-edges features like:<br />
* Opt-in [[PayJoin]]<br />
* Dust attack protections<br />
* Custom change address<br />
* Anti wallet fingerprinting<br />
<br />
Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it. <br />
<br />
Main article: [[Wasabi Wallet]]<br />
<br />
=== Samourai Wallet ===<br />
<br />
Samourai Wallet is a smartphone wallet which implements some privacy features. Stowaway is an implementation of [[PayJoin]]. Stonewall is a scheme which creates transactions that look like [[CoinJoin]]s but actually involve only one person; these fake coinjoins are intended to create false positives in algorithms used by a hypothetical [[transaction surveillance company]]. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.<br />
<br />
By default, Samourai Wallet obtains information about the user's history and balance by querying their own server. This server knows all the user's addresses and transactions, and can spy on them. Therefore using the default configuration of Samourai Wallet is only useful in a threat model where the adversary can analyze the blockchain but cannot access this server. In June 2019 with the release and open sourcing of the Samourai Wallet server, Dojo, users may now host their own server privately and direct their Samourai Wallet to connect to it.<br />
<br />
=== Liquid sidechain ===<br />
<br />
As of 2018 the Liquid [[sidechain]] implements Confidential Transaction (CT) which allows bitcoins to be transferred on that sidechain while keeping the transaction amounts hidden. The product is developed by the Blockstream company and is aimed at exchanges and traders. It allows fast transfer of bitcoin in a very private way.<br />
<br />
As Liquid is a federated sidechain, users generally need to pass AML checks and give up their personal data in order to use it. Its security model is quite close to having bitcoins on an exchange, because if enough of the functionaries get hacked then all the bitcoins on the sidechain could be stolen. However within that security model you get excellent privacy, and the [[sidechain]] itself is marketed towards traders and hedgers who certainly want to keep their trading activities private to stop other traders front-running them.<br />
<br />
== Examples and case studies ==<br />
<br />
Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.<br />
<br />
=== Bad privacy example - Exchange front running ===<br />
# You are a trader and have an account on a bitcoin [[exchange]].<br />
# You want to deposit some bitcoins to sell.<br />
# You send bitcoins to the same exchange deposit address you have used in the past.<br />
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.<br />
# The exchange requires 3 [[confirmation]]s before crediting your account, but in that time the price has already moved against you as other traders become aware of your deposit transaction.<br />
# You sell the bitcoins for a less attractive price than you otherwise would have.<br />
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with [[address reuse]] ===<br />
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].<br />
# All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.<br />
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
# He mentions it to someone in a cafe or bar.<br />
# Word gets around. A burglar raids your home and holds you hostage until $1 million in bitcoin is handed over<ref>https://github.com/jlopp/physical-bitcoin-attacks</ref>.<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Bad privacy example - Savings revealed with data collection ===<br />
<br />
# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].<br />
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.<br />
# Regardless of any blockchain privacy technology you use, the exchange still knows all your trades and can find exactly how much bitcoin you hold at any time.<br />
<br />
=== Example - Evading sanctions ===<br />
# You live in a country that is under international trade sanctions from other countries.<br />
# Because of this you cannot buy the online newspaper you want.<br />
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.<br />
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.<br />
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.<br />
<br />
=== Example - Transacting with your online poker buddies without revealing your real name ===<br />
# You play online poker with some people (for real money).<br />
# You win big. Lots of money goes to you and your buddies are annoyed.<br />
# The stakes are in bitcoin which you receive. You sell the coins for cash or via an [[exchange]], or use them to directly buy goods and services.<br />
# Your irritated poker buddies can't find your real name.<br />
<br />
This example has a very mild threat model where the adversary can't access the exchange's AML/KYC records (if you didn't trade with cash), and they are not your ISP so cannot easily link your bitcoin addresses with your IP address (in the case that you used a [[lightweight node]] instead of a [[full node]]).<br />
<br />
=== Example - Donation without your employer knowing ===<br />
# You earn money in bitcoin, your employer has sent you bitcoins as salary.<br />
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.<br />
# Deposit 0.3 BTC into a bitcoin casino, altcoin exchange or another bitcoin service website that allows anonymous bitcoin deposit and withdrawals from the general public.<br />
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.<br />
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).<br />
<br />
If your employer casually analyses the blockchain they will think you are a gambler instead of a supporter of group X. The bitcoin casino doesn't care who you donate to. The employer also can't correlate the amounts, because they see you deposit 0.3 BTC but only 0.1 BTC is sent to the group. Privacy comes from mixing your coins with the coins of everybody else who uses that casino in the time period that your coins were deposited.<br />
<br />
=== Example - Donation without anyone knowing ===<br />
# You want to support X charity or political group without anyone knowing.<br />
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].<br />
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.<br />
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].<br />
<br />
Instead of direct cash trading, the user could have also bought a cash substitute like a gift card and traded it online for bitcoin that wasn't link to their identity.<br />
<br />
The [[full node]] is required in this threat model, because otherwise your ISP or another adversary could likely spy on [[lightweight node]] communications and discover the user's bitcoin addresses. Broadcasting the transaction over Tor is required to stop your ISP or a [[transaction surveillance company]] from learning that your IP address broadcast the transaction.<br />
<br />
=== Example - Receiving donations privately ===<br />
# You have a [[Address_reuse|single]] donation address for your group or project, anybody can see all donations and their amounts by putting your donation address into a blockchain explorer.<br />
# You want to spend the donations without anyone on the internet knowing.<br />
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].<br />
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.<br />
# Withdraw the money straight into another similar bitcoin service website.<br />
# Take care to use different transactions in order to stop the amounts being correlated.<br />
# Make sure to wait a little while to stop the timings being used to link together transactions<br />
# Repeat this for many different bitcoin websites<ref>https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement</ref> before finally sending the coins back to your own wallet.<br />
<br />
Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.<br />
<br />
Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet<br />
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc<br />
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc<br />
-> 1addrD 0.7btc -> 1addrJ 0.25btc<br />
-> 1addrK 0.25btc<br />
<br />
As before the [[full node]] wallet allows your wallet to learn its own history privately, while Tor broadcasting hides your IP address used when sending a [[transaction]]. Using many different amounts stops [[#Amount correlation|amount correlation]] from providing clues that can ruin your privacy. Using multiple bitcoin websites means a single website which co-operates with the adversary won't be enough to completely ruin your privacy. There is custodial risk as each website has the power to steal your money, but in this example the bitcoin amount is relatively low so the risk is acceptable.<br />
<br />
=== Example - Storing savings privately ===<br />
# You want to [[Bitcoin as an investment|store value in bitcoin]] without anybody else knowing what you do with that value, or even that you own bitcoin.<br />
# Buy the coins in some way and have them sent to your [[JoinMarket]] wallet which you've configured to use your own [[full node]], all of which run entirely over [[Tor]].<br />
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.<br />
# Have the coins sent to another wallet which will be used for [[Storing bitcoins|storing the bitcoins]] long term. The wallet should be backed by a [[full node]] such as [[Electrum]] pointed to your own [[Electrum#Server_software|Electrum server]].<br />
<br />
Note that bitcoin privacy technology like [[JoinMarket]] can hide private-relevant information from your [[transactions]] but it cant add privacy in other places; for example if you buy the bitcoins in a non-anonymous way such as using an AML/KYC exchange then that exchange will know that your real-life identity bought bitcoins at that time.<br />
<br />
Using [[JoinMarket]] is non-custodial unlike the previous method which sends bitcoin through many bitcoin service websites, so it is useful where the custody risk is unacceptably high (such as where you're anonymizing all your hard-earned savings). All the wallets are backed by [[full node]]s in this example to stop a third-party service being able to link together your addresses or link them with your IP address. The full node is run entirely over [[Tor]] to stop your internet service provider or any network-level adversary from seeing that you run a bitcoin node.<br />
<br />
=== Example - Stopping incoming payments from different sources from being linked together ===<br />
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].<br />
# You have a job as a nurse, you also moonlight as a stripper for extra income. Both jobs pay in bitcoin and you don't want them to be linked together.<br />
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.<br />
# You run the JoinMarket tumbler script which will combine both balances without linking them together.<br />
<br />
Another way to do this (but with custodial risk) is to deposit the nurse income into a bitcoin service website (like a casino) and then deposit the stripper income but to a different deposit address. After you withdraw both with be combined with all the other deposits of other users of the casino. Probably the best way to do this is to receive one or both of the income streams over [[Lightning Network]].<br />
<br />
=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===<br />
# You have won 10 BTC at a bitcoin casino, you want withdraw them to a bitcoin exchange to sell without either party knowing (maybe because online gambling is blocked in your jurisdiction).<br />
# Install [[JoinMarket]] and point it at your own [[full node]].<br />
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.<br />
# Run the JoinMarket tumbler script to mix the coins and have them sent to three different deposit address of the exchange with amounts (for example) 1btc + 2btc + 7btc.<br />
# Then neither the online casino nor the exchange can use amount correlation to figure out the source or destination. The coinjoin transactions stop them using the [[common-input-ownership heuristic]], and the other JoinMarket features stop [[address reuse]] and analysis of the transaction graph<ref>https://www.reddit.com/r/joinmarket/comments/7614ea/how_to_properly_spend_tumbled_coins/</ref>.<br />
<br />
=== Bad privacy example - Using a blockchain explorer ===<br />
# You receive a payment of bitcoin at one of your [[address]]es.<br />
# You copy and paste the address into a [[Block chain browser|blockchain explorer website]] and press ''Refresh'' until the incoming transaction reaches 3 [[confirmation]]s.<br />
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.<br />
# This is best avoided by using your own bitcoin wallet (backed by a [[full node]]) to tell you when payments have arrived and how many [[confirmation]]s they have, without any other entity knowing.<br />
<br />
This privacy break can be almost entirely fixed by navigating to the blockchain explorer website over [[Tor]]. It still reveals that ''somebody'' is interested in that [[address|bitcoin address]] but doesn't reveal their IP address, and does not reveal any other bitcoin addresses controlled by the same user.<br />
<br />
=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===<br />
# You own 1.456225 BTC for which some privacy-relevant information has been leaked (maybe you bought it from a AML/KYC exchange) and want to send it to another address while breaking the link between the two.<br />
# You trade the bitcoins for an altcoin which implements some blockchain privacy technology, a so-called "privacy coin", then you trade the altcoin back to bitcoin after making a few altcoin transactions.<br />
# You send the bitcoins back to your wallet in one transaction.<br />
# Because the transaction amount is very close to the initial 1.456225 BTC, its not very hard for an adversary to search the entire blockchain and link the two similar-amount transaction going into and out of the altcoin exchange you used.<br />
<br />
Lesson: Transactions have amounts visible to all which must be treated with care for privacy.<br />
<br />
=== Example - Privacy altcoin mixing ===<br />
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.<br />
# When trading back into bitcoin you deposit the privacy altcoin into an exchange to sell, you use several transactions so that the exchange and any observer of the blockchain cannot easily use amounts to link together the before and after addresses.<br />
<br />
This method may still fail because privacy altcoins have fewer transactions than bitcoin by a factor of a few hundred, so the anonymity set may be lower. Also there are custodial risks with using exchanges so this method may not be appropriate for large amounts of coin. As privacy altcoins are usually much less scalable than bitcoin, their [[full node]] wallets may be more resources-costly to run than bitcoin's. Privacy altcoins are likely to have a more volatile price than bitcoin which increases the risk of losing part of the money due to price movements.<br />
<br />
=== Example - Daily commerce with Lightning Network ===<br />
# You have some bitcoin and want to spend it on regular goods and services. (Coffee, phone credit, VPN, hosting, hotel and apartment rentals, flights, food, drinks, clothes, etc etc) and you want to be as private as possible.<br />
# You download and install a [[Lightning Network]] wallet and use that for all purchases.<br />
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.<br />
<br />
=== Bad privacy example - Sending to a static donation address without precautions ===<br />
# You own bitcoin and keep it in a custodial wallet.<br />
# You want to donate to charity or political group X.<br />
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.<br />
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).<br />
# They disagree with your views and then they close your account.<br />
<br />
Lesson: Using a custodial wallet is bad for privacy because the custodian can see everything you do. [[Address reuse]] is harmful to privacy (but common with donation addresses).<br />
<br />
=== Bad privacy example - Receiving donations spied on with [[Mystery_shopper_payments|mystery shopper payments]] ===<br />
# You want to accept bitcoin donations but don't want to reveal the total donated amount.<br />
# You set up a web server to give out unique addresses for each visitor.<br />
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.<br />
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].<br />
# The adversary now has a good idea of your total donation income.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].<br />
<br />
=== Real life example - Bitcoin-stealing malware using static addresses ===<br />
# You are a creator of stealware (malware that steals money from its victim).<br />
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.<br />
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.<br />
<br />
This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk.org/index.php?topic=1916199.0</ref> and Electrum stealware<ref>https://www.reddit.com/r/Bitcoin/comments/anycg2/electrum_targeted_phishing_malware_warning/</ref><ref>https://twitter.com/GossiTheDog/status/1078308649158664194</ref><br />
<br />
=== Bad privacy example - Bitcoin-stealing malware spied on with [[mystery shopper payments]] ===<br />
# You are an infosec researcher studying bitcoin-stealing malware.<br />
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.<br />
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.<br />
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[Mystery shopper payments|mystery shopper payment]].<br />
# The malware author sends all their received stolen coins to an exchange in one [[transaction]], including your payment.<br />
# You can now look on the blockchain and use the [[common-input-ownership heuristic]] to get an idea of total amount of bitcoins stolen by the malware.<br />
# Also you can now contact the exchange who will tell you the real life identity of the malware author, who can now be put in jail.<br />
<br />
Lesson: [[Mystery_shopper_payments|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].<br />
<br />
=== Example - Single-use lightweight wallet over Tor ===<br />
# You want to anonymously buy something or donate to something online.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].<br />
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.<br />
# You spend the entire balance of bitcoins buying or donating to the thing you want.<br />
# After you're done you delete the wallet and never use it again.<br />
<br />
Your [[Electrum]] wallet used a third-party server which can see all your bitcoin addresses and transaction. As you've connected to it over [[Tor]], the server does not learn your real IP address. As you only use a single bitcoin [[address]] once and never again, the server isn't able to cluster together any other addresses. As you spent the entire balance there is no [[Change|change address]] which can leak information. This setup actually results in strong privacy even though a third-party server is used.<br />
<br />
=== Bad privacy example - Lightweight wallet over Tor used multiple times ===<br />
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.<br />
<br />
# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.<br />
# You install [[Electrum]] wallet and configure it to use [[Tor]].<br />
# You pay for the novelty hat and have it sent to your mail address.<br />
# You pay for the VPN to improve your web browsing privacy.<br />
# As the Electrum wallet queries a third-party Electrum server, that server can link together the two transactions and knows which address is the [[Change|change address]].<br />
# Therefore the server can easily see that the same person who bought the hat also paid for the VPN. As the hat purchase required revealing your mail address, your mail address can now be linked with the VPN account. So much for anonymous web browsing!<br />
<br />
Lesson: The third-party Electrum server was able to link together your two [[transaction]]s. Avoid this by [[Electrum#Server_software|running your own Electrum server]] which is backed by your own [[full node]].<br />
<br />
Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)<br />
<br />
=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===<br />
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].<br />
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see the amount and volume of donations to the Tails OS project: https://www.walletexplorer.com/wallet/04d3d17f766c4e53?from_address=1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 The amounts look realistic so we're probably on the right lines.<br />
<br />
=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===<br />
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.<br />
# Its internal database was leaked in March 2014, from which it was possible to build up a near-complete picture of the deposits and withdrawals of its wallets.<br />
# [[Address reuse]] was also a big factor. The [[common-input-ownership heuristic]] was less of a factor because that heuristic was broken by mtgox's import private key feature.<br />
# Analysis information was also cross-checked by searching the web for all forum posts where a customer writes something like: ''Help! I made a deposit to MtGox of amount 0.12345 BTC. As I write my transaction has 20 [[confirmation]]s but the deposit hasn't appeared in the exchange.'' The forum posts include a date and time. These posts include enough information to search for the corresponding blockchain [[transaction]].<br />
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.<br />
<br />
Full talk: [https://www.youtube.com/watch?v=l70iRcSxqzo Breaking Bitcoin 2017 conference. Kim Nilsson - Cracking MtGox] [https://breaking-bitcoin.com/slides/CrackingMtGox.pdf Slides].<br />
<br />
=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===<br />
# Go to a website which accepts bitcoin donations like ThePirateBay.<br />
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.<br />
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM<br />
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.<br />
# A possible explanation of what's actually happening is ThePirateBay accepts donations straight into its account at a bitcoin [[exchange]], which would result that analysis based on the [[common-input-ownership heuristic]] gives highly exaggerated figures because it actually finds all deposits to that entire exchange. This has a danger for ThePirateBay that the custodial exchange could block or censor incoming donations.<br />
# Another possibility is that ThePirateBay is using [[CoinJoin]].<br />
<br />
=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===<br />
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.<br />
# It has a big named cluster called [https://www.walletexplorer.com/wallet/MtGoxAndOthers MtGoxAndOthers] which has 8.6 million transactions and 3.6 million addresses associated with it as of January 2019.<br />
# The old [[Mt. Gox]] exchange had a feature where users could import bitcoin private keys from their personal wallet straight into the website<ref>https://twitter.com/LaurentMT/status/1078638385256902656</ref>. There it would be merged with UTXOs from MtGox's own wallet.<br />
# It seems some [[CoinJoin]] transactions have also ended up in the cluster<ref>https://www.reddit.com/r/Bitcoin/comments/2ww4eb/how_does_wallet_explorer_know_which_wallets/</ref>.<br />
# For example the transaction <code>5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</code> which is probably a [[JoinMarket]] transaction belongs to the MtGoxAndOthers cluster<ref>https://www.walletexplorer.com/txid/5ac0210febf7ce07a737bae8c32f84c1c54d131c21a16ca6b02b6f1edcad15c3</ref>.<br />
# Another example is the transaction <code>52757ed33a235ce8e48aeaabab7f6dd9cd3445c3642630123103b154ee59f3f5</code> which is a coinjoin created by the old SharedCoin centralized service<ref>https://www.coinjoinsudoku.com/</ref>, it is also in the MtGoxAndOthers cluster according to walletexplorer.<br />
<br />
=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===<br />
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk.org/index.php?topic=139581.0 bitcointalk forums called "I taint rich!"] which aimed to demonstrate coinjoin and how the [[common-input-ownership heuristic]] is not always correct.<br />
# The thread invited forum readers to create [[CoinJoin]]s by hand with Greg Maxwell's vanity [[address]], which he hopes would be a strong demonstration of the flaws of the [[common-input-ownership heuristic]].<br />
# Many years later, a bitcoin [[transaction]] worth 40000 BTC was broadcasted and mined which caused some [https://www.reddit.com/r/Bitcoin/comments/6tvwr5/someone_moved_40000_btc_is_it_from_silkroad/ speculation on bitcoin forums]. The handmade coinjoins caused some to come to the wrong conclusion that Greg Maxwell was the owner of the 40000 BTC.<br />
# A quote from the analyst:<br />
<blockquote><br />
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''<br />
<br />
''If you follow the 40k from that transaction (click the outputs), you get to the transaction you linked to. It's a short series of transactions.''<br />
<br />
''Basically, someone who owns that address was able to unlock coins from that address, as well as another address that held the 40,000, in the same transaction. So they must have owned both (at least 4 years ago anyway).''<br />
</blockquote><br />
<br />
Lesson: The [[common-input-ownership heuristic]] isn't always right.<br />
<br />
=== Real life example - The QuadrigaCX exchange wallet analysis ===<br />
<br />
# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.<br />
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.<br />
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.<br />
# Using www.walletexplorer.com the analyst was able to find a big wallet cluster containing all those addresses, it is likely this is the QuadrigaCX hot wallet. The hot wallet made many transactions, often involve [[Address reuse|reused addresses]] and didn't use [[CoinJoin]]; so it's likely that this analysis is correct.<br />
# The walletexplorer cluster called MtGoxAndOthers mislead the analyst into believing the QuadrigaCX had something to do with MtGox, when in reality that cluster arises because of [[CoinJoin]].<br />
# The analyst was unable to find a single cluster with a significant amount of bitcoins which could be the [[cold storage]] wallet. However cold storage wallets are likely to create few transactions and never reuse addresses; so its possible such a cluster would never appear on walletexplorer.com which uses the [[common-input-ownership heuristic]]. However its also possible that the exchange is insolvent and so there is no [[cold storage]] wallet.<br />
<br />
Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/<br />
<br />
Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/<br />
<br />
=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===<br />
<br />
# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.<br />
# In the United States online gambling is illegal (although state government often operates their own lotteries, and meatspace gambling like in Vegas is legal). Coinbase.com enforces this policy by warning and ultimately banning their customers who use online bitcoin casinos.<br />
# Some of Bustabit's customers were being warned and banned by Coinbase.com.<br />
# Bustabit implemented [[Techniques_to_reduce_transaction_fees#Change_avoidance|change avoidance]]<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015606.html</ref> so many of their withdrawal transactions did not have a change output.<br />
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.<br />
# No more Bustabit customers were ever warned or banned<br />
# It seems the combination of both methods broke the [[common-input-ownership heuristic]] and reduced the privacy-relevant information leaked by change outputs, enough that Coinbase.com's [[transaction surveillance company]] partner was unable to identify Bustabit's wallet addresses anymore.<br />
<br />
=== Real life example - Rare multisignature scripts ===<br />
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.<br />
# This includes their m-of-n values, the most common by far are 2-of-3 multisig<ref>https://p2sh.info/dashboard/db/p2sh-repartition-by-type?orgId=1</ref>.<br />
# Some very unusual scripts such as 12-of-14 multisignature has been used a handful of times on the blockchain. These are easily visible as someone's wallet who received some money and then spent it.<br />
# The bitcoin vault of the Xapo company used a 3-of-5 multisignature scheme. At one point when they moved it which resulted in 90% of the coins held on 3-of-5 multisig addresses moving on the blockchain. This revealed the amount of bitcoin in Xapo's wallet<ref>https://www.youtube.com/watch?v=Tiyvrh53Yp8</ref>.<br />
# In 2016 the exchange Bitfinex was hacked and part of its wallet was stolen. Bitfinex used 2-of-3 multisignature addresses to store its coins. As the thief moved the hacked coins to regular non-multisignature addresses, the movement of 120,000 bitcoins out of 2-of-3 multisig was visible on the blockchain, and it revealed the size of the theft<ref>https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/</ref>.<br />
<br />
=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===<br />
<br />
# A user posted on the bitcoin reddit forum<ref>https://web.archive.org/web/20170309231819/https://www.reddit.com/r/Bitcoin/comments/4v28jl/how_have_fungiblity_problems_affected_you_in/</ref> about his experience with co-workers figuring out his salary because of [[address reuse]].<br />
# ''"As a freelance IT contractor, I had one incident where an on-site specialist found out my daily rate. Surely, he was a bit upset and complained to his manager about the lack of his own compensation. My agency fined me for 50% of the monthly rate. Needless to say, I now create a unique receive address for every invoice, and use another set of addresses for the daily personal-use expenditure."''<br />
<br />
Lesson: [[Address reuse]] is terrible for privacy.<br />
<br />
=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===<br />
<br />
# In May 2017 a reddit user posted a thread saying they kept 445 btc on blockchain.info's web wallet, and their coins were stolen<ref>https://www.reddit.com/r/Bitcoin/comments/69duq9/50_bounty_for_anybody_recovering_445_btc_stolen/</ref>.<br />
# They offered a 50% bounty for any help or information leading to finding their bitcoins again<br />
# The stolen coins turned out to have been mixed through [[JoinMarket]]. It seems the hacker put the coins in a JoinMarket yield generator script and allowed them to be used for coinjoins a large number of times. A CoinJoin peeling chain can be seen.<br />
# All traces are lost from what anybody has been able to tell.<br />
<br />
For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.<br />
<br />
=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===<br />
<br />
# Online shopping has several potential privacy leaks. Examples are third-party tracking cookies (such as from sites Doubleclick, Google Analytics or Facebook), or data given intentionally to merchants such as name, delivery address or email address.<br />
# Bitcoin's blockchain leaks a lot of privacy-relevant information.<br />
# Data fusion of these two categories of leaks can reveal a lot of information about people using Bitcoin for online shopping. This is the topic of a 2018 paper called When The Cookie Meets The Blockchain<ref>Goldfeder, S., Kalodner, H., Reisman, D., & Narayanan, A. (2018). When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies, Proceedings on Privacy Enhancing Technologies, 2018(4), 179-199. doi: https://doi.org/10.1515/popets-2018-0038</ref>.<br />
# For example, if a bitcoin user buys a novelty hat and has it shipped to their home and then later the same bitcoin wallet donates to Wikileaks, then the hat merchant and third-party trackers (who know the user's real name and mail address) can figure out that the same user donated to Wikileaks.<br />
<br />
This is example of the power of data fusion, where two or more privacy leaks which when combined reveal far more information than each individual leak.<br />
<br />
The privacy problems of third-party web tracking cookies have been known for nearly a decade but the situation has not improved much. Privacy can be regained in practice in this situation by 1) Using browser extensions such as uBlock Origin, Adblock Plus or Ghostery to block third-party tracking cookies, and/or 2) Using [[Off-Chain Transactions|off-chain transaction methods]] to make payments where much less privacy-relevant information is leaked. Most practically as of 2019 would be using [[Lightning Network]] for online shopping.<br />
<br />
=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===<br />
<br />
# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.<br />
# Someone on reddit easily unmixes many BitcoinFog mixes using [[#Amount_correlation|Amount correlation]]<ref>https://web.archive.org/web/20150607131623/http://www.reddit.com/r/DarkNetMarkets/comments/2rhaqc/deanonimyzing_bitcoinfog_and_other_tumblers/</ref><br />
<br />
=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===<br />
<br />
# A 2018 paper<ref>Juhász PL, Stéger J, Kondor D, Vattay G (2018) A Bayesian approach to identify Bitcoin users. PLOS ONE 13(12): e0207000. https://doi.org/10.1371/journal.pone.0207000</ref> uses blockchain analysis and the tracking of transaction broadcasts to deanonymize bitcoin users.<br />
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])<br />
# The researchers connect to every single listening bitcoin node, and attempt to track transactions as they broadcast. This gives them an idea of the originating IP address.<br />
# The paper identifies about 22,000 bitcoin users by linking their IP address and bitcoin [[address]]es. About 20,000 of these users come from one IP address which is probably a popular web wallet.<br />
# The paper collected data during late-2013, but the Bitcoin Core transaction relay algorithm has been changed significantly in the meantime to improve privacy. So the method used should work less well today.<br />
<br />
Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.<br />
<br />
=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===<br />
<br />
# A 2018 paper uses tracking techniques to study bitcoin ransomware<ref>D. Y. Huang et al., "Tracking Ransomware End-to-end," 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, 2018, pp. 618-631. doi: 10.1109/SP.2018.00047 https://www.youtube.com/watch?v=H5bPmzsVLF8</ref>.<br />
# Some ransomware uses static addresses (which implies [[address reuse]]) while other ransomware requires victims to connect to a http server that hands out new bitcoin addresses.<br />
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.<br />
# They also used [[Mystery_shopper_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.<br />
# The researchers use the [[common-input-ownership heuristic]] to find clusters of [[address]]es. They know that [[CoinJoin]] breaks this assumption and so search for detectable [[CoinJoin]] transactions within the clusters which would indicate a break. This was before the invention or implementation of [[PayJoin]] so it is assumed that all coinjoins can be detected.<br />
# The researchers try to match incoming payments to the ransomware clusters with spikes in Google searches for that ransomware, and uploads of the ransomware binary to malware-tracking websites. If there are spikes in google searches or binary uploads without a corresponding increase in incoming bitcoin payments, then that indicates that the researchers have missed some clusters belonging to the ransomware wallets. This is [[#Timing correlation|Timing correlation]] in use. The researchers conclude they are in fact missing most clusters for CryptoDefense, CryptoLocker, and CryptoWall, but probably have all the clusters for the other ransomware they study.<br />
# A [[transaction surveillance company]] called Chainalysis is used to find the ownership of certain addresses. It works particularly well for exchanges which share their data with Chainalysis. With this the destination of ransomware funds can be tracked. The largest known destination is the BTC-E, a now-shut-down Russian bitcoin exchange with lax controls that was widely known to be used by criminals. However the vast majority of funds is sent to Unknown destinations. One ransomware called CryptoXXX is ~95% sent to Unknown, WannaCry had 100% unknown. The researchers write BTC-E in the paper's abstract and conclusion because that's the biggest destination they could find, but in reality most of the ransomware money could not be tracked<br />
<br />
The paper is an excellent example of transaction tracking. The researchers take great care in their conclusions, as in blockchain analysis it is sometimes easy to trick yourself into thinking you know more than you do. It is worth reading by anyone interested in bitcoin privacy.<br />
<br />
Ransomware is a threat. Always keep good backups of your important data.<br />
<br />
==See also==<br />
<br />
* [[Common-input-ownership heuristic]]<br />
* [[Address reuse]]<br />
* [[CoinJoin]]<br />
* [[PayJoin]]<br />
* [[Transaction surveillance company]]<br />
* [[Client-side block filtering]]<br />
* [[Full node#Privacy]]<br />
* [[Lightning Network]]<br />
<br />
==References==<br />
<references /><br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=Storing_bitcoins&diff=68400Storing bitcoins2021-02-01T19:18:56Z<p>Belcher: /* Further reading */ reword</p>
<hr />
<div>''This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].''<br />
<br />
As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.<br />
<br />
'''tl;dr''' The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). Ideally the wallet should be backed by your own [[full node]].<br />
<br />
== Introduction ==<br />
<br />
Storage of bitcoin can be broken down in a few independent goals:<br />
<br />
* Protection against accidental loss<br />
* Verification that the bitcoins are genuine<br />
* Privacy and protection against spying<br />
* Protection against theft<br />
* Easy access for spending or moving bitcoins<br />
<br />
The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.<br />
<br />
[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]<br />
<br />
=== Protection from accidental loss ===<br />
<br />
In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups. <br />
<br />
The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage. <br />
<br />
Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.<br />
<br />
The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''metal seed phrase backup''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.<br />
<br />
=== Verification and privacy ===<br />
<br />
Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.<br />
<br />
If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they are genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].<br />
<br />
Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]<br />
<br />
So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.<br />
<br />
=== Protection from theft ===<br />
<br />
Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions. <br />
<br />
Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.<br />
<br />
[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]<br />
<br />
=== Easy access ===<br />
<br />
Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.<br />
<br />
=== Summary ===<br />
<br />
In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].<br />
<br />
== Types of wallets ==<br />
<br />
=== Hardware wallets ===<br />
<br />
''Main article: [[Hardware wallet]]''<br />
<br />
[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.<br />
<br />
A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.<br />
<br />
Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.<br />
<br />
=== Multisignature wallets ===<br />
<br />
''Main article: [[Multisignature]]''<br />
<br />
A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.<br />
<br />
These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.<br />
<br />
Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use. <br />
<br />
Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.<br />
<br />
=== Cold storage wallets ===<br />
<br />
''Main article: [[Cold storage]]''<br />
<br />
A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.<br />
<br />
This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.<br />
<br />
=== Hot wallets ===<br />
<br />
''Main article: [[Hot wallet]]''<br />
<br />
A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.<br />
<br />
A user might have a ''spending account'' hot wallet for day-to-day convenient spending with the majority of their funds on a ''savings account'' which is stored with much more security (cold storage / hardware wallet / multisignature).<br />
<br />
== Bad wallet ideas ==<br />
<br />
=== Custodial wallets ===<br />
<br />
Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.<br />
<br />
The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref><br />
<br />
==== "Isn't it just like keeping your money in a bank?" ====<br />
<br />
''The following is a quote of waxwing on reddit<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>:''<br />
<br />
:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:<br />
<br />
:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.<br />
<br />
:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.<br />
<br />
:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).<br />
<br />
:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.<br />
<br />
:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?<br />
<br />
:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<br />
<br />
=== Web wallets ===<br />
<br />
Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)<br />
<br />
Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].<br />
<br />
Main article: [[Browser-based wallet]]<br />
<br />
=== Paper wallets ===<br />
<br />
So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].<br />
<br />
Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.<br />
<br />
A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.<br />
<br />
Main article: [[Paper wallets]]<br />
<br />
=== Cloud storage ===<br />
<br />
This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor. Furthermore, there are a variety of ways in which 2FA can be compromised, in particular SMS-based 2FA, such as via a SIM-Swap.<br />
<br />
=== Removable media ===<br />
<br />
This refers to storing wallet files on removable media like SSD or hard drives.<br />
<br />
Refer to the warnings from these two links:<br />
<br />
* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/<br />
* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html<br />
<br />
Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.<br />
<br />
=== "Physical" Bitcoins === <br />
<br />
Physical Coins and other mechanism with a pre-manufactured key or seed are not a good way to store bitcoins because they keys are already potentially compromised by whoever created the key. You should not consider bitcoin yours if its stored on a key created by someone else. It only becomes yours when you transfer the bitcoin to a key that you own and exclusively control.<br />
<br />
== Other ideas ==<br />
<br />
=== Time-locked wallets ===<br />
<br />
An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.<br />
<br />
Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.<br />
<br />
=== Consulting ===<br />
<br />
If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.<br />
<br />
== The 5 dollar wrench attack ==<br />
<br />
[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]<br />
<br />
It's sometimes said that all this security is worthless because the $5 wrench attack can be used.<br />
<br />
There are multiple ways that can be utilized to beat this attack: by hiding, by defending yourself, by not letting others know your Bitcoin wealth or holdings, or by implementing security procedures which would prevent you from being able to surrender funds in such an attack, thereby reducing the appeal for an attacker to perform such an attack in the first place.<br />
<br />
Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.<br />
<br />
Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.<br />
<br />
Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.<br />
<br />
See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]<br />
<br />
See Also: [https://www.youtube.com/watch?v=H16Zus3GAVA Advice by a former police officer about physical security in bitcoin]<br />
<br />
== See also ==<br />
<br />
* [[Links to Storage Methods]]<br />
<br />
== Further reading ==<br />
<br />
* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]<br />
<br />
* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/<br />
<br />
* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d<br />
<br />
* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4<br />
<br />
* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac<br />
<br />
* This is why you shouldn’t use SMS for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.<br />
<br />
* [[Backup and Storage Methods]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Security]]<br />
[[Category:Wallets| ]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=User:Belcher&diff=68393User:Belcher2021-01-21T21:35:37Z<p>Belcher: /* PGP fingerprint */ PGP fingerprint on my website</p>
<hr />
<div>== PGP fingerprint ==<br />
<br />
My (belcher's) PGP fingerprint is <code>0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129</code>.<br />
<br />
It can also be found [https://www.reddit.com/r/publickeyexchange/comments/3ti8vp/ubelcher_s_public_key/ here], [https://twitter.com/chris_belcher_/status/559879313622061056 here], [https://github.com/chris-belcher here], [https://x0f.org/@belcher/105595837557120598 here] and [https://bitcoinprivacy.me/ here].<br />
<br />
== PGP key ==<br />
<br />
The key itself:<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: GnuPG v1<br />
<br />
mQINBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/<br />
Ft9w2A92f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW1<br />
9bZLmjAj7zkgektlYNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgam<br />
xUAadul7AETSsgqOEUDI0FKRFODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0Jzv<br />
kTnJGElBcA37rYaMmDi4DhG2MY4u63VE8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcK<br />
ywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7ZCqc9P6ENAk5a0JjHw0d0knA<br />
pboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSzWkvAns9oJV6uWdnz<br />
5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9PknusTchYm3B<br />
S2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht<br />
0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzk<br />
bTAnDsPiDokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQAB<br />
tB9DaHJpcyBCZWxjaGVyIDxmYWxzZUBlbWFpbC5jb20+iQI+BBMBAgAoBQJT5O+K<br />
AhsDBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8j<br />
D/9P9fSYSIVjltL9brAMfIu7wJn0H0lXTbcuCM2uQitJ3BNxI3c7aq5dEby27u5U<br />
d54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFAbtKcgtVIMFbeClzTTfWr4W7f<br />
E45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9AHCpBemd9TN60CoML<br />
MyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm8XIl0f8S<br />
fKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF<br />
LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UH<br />
rjD5I3hAwJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoB<br />
pq00R54JxUKlfRM7OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd<br />
5oi1RJuHtxHsj8+/XU15UItbjeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tu<br />
wq9d8EokUrtAyrPayznliy53UJfWDVzl925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJ<br />
Qy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2k4dhWYkBHAQTAQIABgUCVjFG<br />
AAAKCRCzrgnx6aMZetY1B/43RkqMxOviQqJCSeTMfR4T6f/uU4ARwtNMpC3vxLN6<br />
vOKtf5o96L6aDuODk2yYyK2b0eZPOXP4EzJ92kEDI5d6SP36boCLm/jau7+pUjtW<br />
pJ/6/AxBS86+DEgst8qH3t9Oyb8FcZ/RBU7m4K9XZ/DgMbIUMAPpkrKDIKbqCn4F<br />
O0/+MeSo4NdZdUIrjKttP+CIJbEkqN77L6EreyxBn+zZ6S5P2y0VPDGrZGLIChnL<br />
irOtTBcipMb95lC7JZTmw6kcbJjiqHDJO/66f+6MzEDa7RwdjA4DkJqzCcCFWagB<br />
whT+4aJYDwAgLHB9unqvyh1NgRBEw4JDOE4b2jcFJiIQiQIcBBABAgAGBQJWHuhh<br />
AAoJECR0Mg6jZ5WAIXIP/Aifw2bxqn1jRAEjxj2LmTBJDawopabJD6smg9I3V0L2<br />
iYBSFpUAVVpfrZJxvSLs+pdJFnyDEvyiKcwcQKAfBQv07SKCVhkQmoBWR1Y7Wiq9<br />
qCUC6gKl4kkQmnbFgEzdep33YqV7osYusU1TocbyOCtkCr0L9kJt58ejXsoqXjlA<br />
nt1HbWj4ELbSjLdAaoYzD059aKAQxtFoXNvFnQSbMGuvUuVY5HhTaxPIEkw5ql2r<br />
M+EMKaxmDfwN8CJs64dfSCZ8+c3TVtFqDf139c3eV3LVUpoSdyXa3Ie75wFnxiNK<br />
A9262Gc1E3OlCavyWjkV4ah+7aMcXNO2EoOAY9I+d5tC22lprtMrrdk3vC1OgozK<br />
JdURa+ewUQtnThrXoHtLejI0XV6bRpQCrTZDJa/J3RJAgqxSBgv1DLSPp0lXbrFU<br />
d+TCWh0VxZTzb8Wx3z2YaTDuzrc6ucn5PJUjsQ58vVf+vdvXUaDCj/cwcjocyYm/<br />
KNv8pL9cxXeWqLsIw/44SI9q+F8uTHUWnPTLCzM/ANYVR1FEuvRpp9HLGPOe1qXR<br />
X0eLYYeoqi9snfp4Fyr3hR5NOn5vTFHeL7BI0Flvz5mNxUJQfxrNuSIytw4uPVfy<br />
7LaxKkn1pIVgOLdt3OrIp2UmiGwinMAEQv8eUqZAeybMweRx9IQzxakPjwtJWcqK<br />
iQIcBBABCgAGBQJWRqXIAAoJEBuRhN+eEXcYvEcP/jGxdNC+kveX7T8Aanrr2P8s<br />
HHGFxbl2+nqTTk9MBCZ5gyiFuPwEoxRTKH3WMq0klvyMOVij2bZxsVwTdXcfGDoU<br />
+7RitGxh2AyhZlQHm31P0TSuZCa5+U415bDPKplPAlarCC+qyXRguhdE1ODU2cUF<br />
aLEKlGa6LkYn24TL1higqTTQhrsB/txYKAaqIhcE8KqckGDqVBTZlWCoqJYzLphz<br />
4CIwLu/V7KsL87pgLgZmEvbbvmScRGb5Na+94EFF91G9DZXKfhGcoShVLzNTFWj/<br />
HnjWZfkGYyK5BjoOqLCoL5E58dMuWg5sGjCfHK7FT1PF1eRg42z1nAmcpTl/Qsco<br />
sQu4cgsZY7uMNU8WVekVGpLLLfvRtXwwmG8oeh+x2SDw4O+EedjKIXb0aaElfAcp<br />
qAxljlZIMFWwfg4+O55nq6eaRwwoX911358s1oHkdOo007za2lK7pRp77CLLSVtV<br />
FBXUFDNvBB2oajgeijL0mXGjc4z14kfoZXxf46hNSTxn17xdvZD428koyM6qdjCP<br />
RJrEBXXJtei5o1MpCCamU69KOP75hdt+y6FtTIqO2hlu2n21qcLXlrovzp4ayNPA<br />
4eZH5AQYMHYIyVLplX42F5J8E1WAMN5Hlx+AEJ+Nwa/f+EOuw2A2P+zpYLtorL8c<br />
vPicLu+Jbue3qRtDwuKviQIcBBABCgAGBQJXZKggAAoJEIjSQRchdD07WToP/1mA<br />
Us3JNI5wpNOAJ2bpthSwYTA+hK84IvCIOSePtTZxfYPZjysuXKrMaf68f2GgfYlR<br />
TGabGoIKJdEuct/o1KQBDbpGB8V4eZYw/qOHnwpi9jvXy/pytVi0AKpn2je1MVsE<br />
cQYrgU7Z0auhpJfT5UK4Kk4XjV+a1iQHQS9FOzcRA5yGwLGMCg/F+CjBnItcBqv6<br />
+y/zA6TmZHQz80hHjVuW6bLqngc7I7btcWo7GI8/wrrQk0/XsSt8sO0BC3lvoJAg<br />
Un7LnwVJwQyWoLCShDPIYn47pVw9bAR8T6ac+AVm9Ar3VxjlxLhPg6h8u8O8EyZM<br />
07Q4F5b3heDQ71xomALBNQKjxreCNHAeq8scVVESIrUvccZYkWDIcES0UPyKhnAm<br />
lpExmR1AuTQhRhiTxQwZDRG01yj2kSCevJ5TslMo8VpqNlDjdd4qVbmOO5Z5pOpE<br />
nDeFbRLjPFa47OyGcw6aSgW1VocVNAJQ8Q6bdIAJhtXcbLqIZGGZ2wkwcJoQcdqA<br />
UxENxSTu1jntjtWrQpnPyMMlvp9/5WtJhSk6hTw5o7pQAthLPpPRjxxlY/265DhV<br />
tTC3I2JBEDF41pGoajTOyzsJ9v6p3M6tqDGeBmrdjla2bl9VR9n0vxZqij/DaPjO<br />
l9ersqoYTDpMHByeUvvKWDurbuptj8zs/AyvLQi/uQINBFPk74oBEADIXEAzbwRD<br />
Aty2vQKtCFhZl8wrMCELD4TKtQn797i6IBDg7JeJ9GtlXqQtG6XdZtMHWSkDrCAJ<br />
KE7Q3e/Dx8UbYKzpCmFVqAQfzJ9BSuhpXGAANg5Mscw5vsg1Lysoj+5E2YTptdNf<br />
buhqoIRcszJypiW59p3uGvjZL9PzM2Hmba+XpP/U+iPb+iuZWIrADEz7yp/F3wU0<br />
jhQqarbNkT2Znk+JIhfSpGAzTIK/FXf17H+eHHOi5MG+/gtvWe2mVH9swusfGwLO<br />
HIwoOBxfsCkab7LpgSw6/PD2tEJG4mkTiW2HxKGCNO01Md+SUEPpm3KZzurtt09a<br />
ko4S87mUNDqrz4p8Q2/zrZw4uVYuTthHb6YdnU9caFYLuCDASR8YmhejTHxf7OBQ<br />
p7b70mPjISF8vQhsVgLPYnl35xZUgGS0jfGqTAtRla4BsTe+BgDiHzO1HqXXw1M+<br />
SIC+k1ARovhlGcDHbZZ2xDwaURZ3IpkFZstR01wyY98aLkULDac28LI3qS2/mZNk<br />
TXYSqC+nNhy5QZA8gxX0pOVI+6bc0sOrxAjqCtsbyI02kQHGYJA4rPb8G5gClTaH<br />
C3YTjh8vx7oJEreuJ1xF2qm56DvmbLoqQ6qbydKIwRz+lUgfB0n3+q6K5Fp4L+1l<br />
aVg8jANaBvxkT+DrrPflYCC4xD4TB++ABQARAQABiQIlBBgBAgAPBQJT5O+KAhsM<br />
BQkSzAMAAAoJEO9zTqZ38xEppnAP/04jejeBWay3+YbHqFVCvL76G3x0VY0iIBI8<br />
G8PcTkRZupaLqaapIg5LoLGNTQ+dzFME8Je3PGj9bO4cZCD/G015DRPxvaUFJxkD<br />
D3eqbUhwdctR7nD9NqnphoOZJgIhkB21sfNh89bgkrtya9yO8XyOFMU4EQ4VVCRO<br />
LX0btxpWi3T7AvV7YNEcNcB7kKKcSlosGXAd4S7/mPrBzd6uiFRmUr0hsByWPiJl<br />
NBtqrcTKpReXn10E443GYvl50nHNWKyEhhAYjID1Y/VLKVe36Q7zY0SpkbY7F1cC<br />
XOO4nwLakAb6dsu0OjiFyyI38wBpf38kHsxdyVPmKh6sXjI2AoR1+rsubKexNR3z<br />
D8iXKnsAP4Fai6PI73iLyH14q+N/0+9LDFC4CNGnGd7tkkPy8Kww1cEdJt4QrYuL<br />
BK0cv/Djve+JekMPncno4vFfprlG6aZH6uLFswft2AowlDsWXIOmGbeivoJKQYSK<br />
vUoDTLW+pA0W0eGC4VqkBYwMpomNBA2C9lSY6jqFtmqa9QXU5Zx3oYDqPdY5R7d8<br />
Mld9uro/0mbGrriinzzt1gqyDvGNCr/sozvDJFypddxsF2C821UM/4SfME0fJhj/<br />
eazhggcTkkfFD0tXjI9xaRhO9vVek0gVVutJcB7IYdU1P5I7qiUWi9tYgLcDP3J6<br />
xozVpKhO<br />
=oUJc<br />
-----END PGP PUBLIC KEY BLOCK-----</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=User:Belcher&diff=68392User:Belcher2021-01-21T21:34:17Z<p>Belcher: /* PGP fingerprint */ Add mastadon fingerprint toot</p>
<hr />
<div>== PGP fingerprint ==<br />
<br />
My (belcher's) PGP fingerprint is <code>0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129</code>.<br />
<br />
It can also be found [https://www.reddit.com/r/publickeyexchange/comments/3ti8vp/ubelcher_s_public_key/ here], [https://twitter.com/chris_belcher_/status/559879313622061056 here], [https://github.com/chris-belcher here] and [https://x0f.org/@belcher/105595837557120598 here].<br />
<br />
== PGP key ==<br />
<br />
The key itself:<br />
<br />
-----BEGIN PGP PUBLIC KEY BLOCK-----<br />
Version: GnuPG v1<br />
<br />
mQINBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/<br />
Ft9w2A92f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW1<br />
9bZLmjAj7zkgektlYNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgam<br />
xUAadul7AETSsgqOEUDI0FKRFODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0Jzv<br />
kTnJGElBcA37rYaMmDi4DhG2MY4u63VE8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcK<br />
ywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7ZCqc9P6ENAk5a0JjHw0d0knA<br />
pboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSzWkvAns9oJV6uWdnz<br />
5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9PknusTchYm3B<br />
S2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht<br />
0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzk<br />
bTAnDsPiDokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQAB<br />
tB9DaHJpcyBCZWxjaGVyIDxmYWxzZUBlbWFpbC5jb20+iQI+BBMBAgAoBQJT5O+K<br />
AhsDBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8j<br />
D/9P9fSYSIVjltL9brAMfIu7wJn0H0lXTbcuCM2uQitJ3BNxI3c7aq5dEby27u5U<br />
d54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFAbtKcgtVIMFbeClzTTfWr4W7f<br />
E45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9AHCpBemd9TN60CoML<br />
MyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm8XIl0f8S<br />
fKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF<br />
LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UH<br />
rjD5I3hAwJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoB<br />
pq00R54JxUKlfRM7OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd<br />
5oi1RJuHtxHsj8+/XU15UItbjeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tu<br />
wq9d8EokUrtAyrPayznliy53UJfWDVzl925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJ<br />
Qy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2k4dhWYkBHAQTAQIABgUCVjFG<br />
AAAKCRCzrgnx6aMZetY1B/43RkqMxOviQqJCSeTMfR4T6f/uU4ARwtNMpC3vxLN6<br />
vOKtf5o96L6aDuODk2yYyK2b0eZPOXP4EzJ92kEDI5d6SP36boCLm/jau7+pUjtW<br />
pJ/6/AxBS86+DEgst8qH3t9Oyb8FcZ/RBU7m4K9XZ/DgMbIUMAPpkrKDIKbqCn4F<br />
O0/+MeSo4NdZdUIrjKttP+CIJbEkqN77L6EreyxBn+zZ6S5P2y0VPDGrZGLIChnL<br />
irOtTBcipMb95lC7JZTmw6kcbJjiqHDJO/66f+6MzEDa7RwdjA4DkJqzCcCFWagB<br />
whT+4aJYDwAgLHB9unqvyh1NgRBEw4JDOE4b2jcFJiIQiQIcBBABAgAGBQJWHuhh<br />
AAoJECR0Mg6jZ5WAIXIP/Aifw2bxqn1jRAEjxj2LmTBJDawopabJD6smg9I3V0L2<br />
iYBSFpUAVVpfrZJxvSLs+pdJFnyDEvyiKcwcQKAfBQv07SKCVhkQmoBWR1Y7Wiq9<br />
qCUC6gKl4kkQmnbFgEzdep33YqV7osYusU1TocbyOCtkCr0L9kJt58ejXsoqXjlA<br />
nt1HbWj4ELbSjLdAaoYzD059aKAQxtFoXNvFnQSbMGuvUuVY5HhTaxPIEkw5ql2r<br />
M+EMKaxmDfwN8CJs64dfSCZ8+c3TVtFqDf139c3eV3LVUpoSdyXa3Ie75wFnxiNK<br />
A9262Gc1E3OlCavyWjkV4ah+7aMcXNO2EoOAY9I+d5tC22lprtMrrdk3vC1OgozK<br />
JdURa+ewUQtnThrXoHtLejI0XV6bRpQCrTZDJa/J3RJAgqxSBgv1DLSPp0lXbrFU<br />
d+TCWh0VxZTzb8Wx3z2YaTDuzrc6ucn5PJUjsQ58vVf+vdvXUaDCj/cwcjocyYm/<br />
KNv8pL9cxXeWqLsIw/44SI9q+F8uTHUWnPTLCzM/ANYVR1FEuvRpp9HLGPOe1qXR<br />
X0eLYYeoqi9snfp4Fyr3hR5NOn5vTFHeL7BI0Flvz5mNxUJQfxrNuSIytw4uPVfy<br />
7LaxKkn1pIVgOLdt3OrIp2UmiGwinMAEQv8eUqZAeybMweRx9IQzxakPjwtJWcqK<br />
iQIcBBABCgAGBQJWRqXIAAoJEBuRhN+eEXcYvEcP/jGxdNC+kveX7T8Aanrr2P8s<br />
HHGFxbl2+nqTTk9MBCZ5gyiFuPwEoxRTKH3WMq0klvyMOVij2bZxsVwTdXcfGDoU<br />
+7RitGxh2AyhZlQHm31P0TSuZCa5+U415bDPKplPAlarCC+qyXRguhdE1ODU2cUF<br />
aLEKlGa6LkYn24TL1higqTTQhrsB/txYKAaqIhcE8KqckGDqVBTZlWCoqJYzLphz<br />
4CIwLu/V7KsL87pgLgZmEvbbvmScRGb5Na+94EFF91G9DZXKfhGcoShVLzNTFWj/<br />
HnjWZfkGYyK5BjoOqLCoL5E58dMuWg5sGjCfHK7FT1PF1eRg42z1nAmcpTl/Qsco<br />
sQu4cgsZY7uMNU8WVekVGpLLLfvRtXwwmG8oeh+x2SDw4O+EedjKIXb0aaElfAcp<br />
qAxljlZIMFWwfg4+O55nq6eaRwwoX911358s1oHkdOo007za2lK7pRp77CLLSVtV<br />
FBXUFDNvBB2oajgeijL0mXGjc4z14kfoZXxf46hNSTxn17xdvZD428koyM6qdjCP<br />
RJrEBXXJtei5o1MpCCamU69KOP75hdt+y6FtTIqO2hlu2n21qcLXlrovzp4ayNPA<br />
4eZH5AQYMHYIyVLplX42F5J8E1WAMN5Hlx+AEJ+Nwa/f+EOuw2A2P+zpYLtorL8c<br />
vPicLu+Jbue3qRtDwuKviQIcBBABCgAGBQJXZKggAAoJEIjSQRchdD07WToP/1mA<br />
Us3JNI5wpNOAJ2bpthSwYTA+hK84IvCIOSePtTZxfYPZjysuXKrMaf68f2GgfYlR<br />
TGabGoIKJdEuct/o1KQBDbpGB8V4eZYw/qOHnwpi9jvXy/pytVi0AKpn2je1MVsE<br />
cQYrgU7Z0auhpJfT5UK4Kk4XjV+a1iQHQS9FOzcRA5yGwLGMCg/F+CjBnItcBqv6<br />
+y/zA6TmZHQz80hHjVuW6bLqngc7I7btcWo7GI8/wrrQk0/XsSt8sO0BC3lvoJAg<br />
Un7LnwVJwQyWoLCShDPIYn47pVw9bAR8T6ac+AVm9Ar3VxjlxLhPg6h8u8O8EyZM<br />
07Q4F5b3heDQ71xomALBNQKjxreCNHAeq8scVVESIrUvccZYkWDIcES0UPyKhnAm<br />
lpExmR1AuTQhRhiTxQwZDRG01yj2kSCevJ5TslMo8VpqNlDjdd4qVbmOO5Z5pOpE<br />
nDeFbRLjPFa47OyGcw6aSgW1VocVNAJQ8Q6bdIAJhtXcbLqIZGGZ2wkwcJoQcdqA<br />
UxENxSTu1jntjtWrQpnPyMMlvp9/5WtJhSk6hTw5o7pQAthLPpPRjxxlY/265DhV<br />
tTC3I2JBEDF41pGoajTOyzsJ9v6p3M6tqDGeBmrdjla2bl9VR9n0vxZqij/DaPjO<br />
l9ersqoYTDpMHByeUvvKWDurbuptj8zs/AyvLQi/uQINBFPk74oBEADIXEAzbwRD<br />
Aty2vQKtCFhZl8wrMCELD4TKtQn797i6IBDg7JeJ9GtlXqQtG6XdZtMHWSkDrCAJ<br />
KE7Q3e/Dx8UbYKzpCmFVqAQfzJ9BSuhpXGAANg5Mscw5vsg1Lysoj+5E2YTptdNf<br />
buhqoIRcszJypiW59p3uGvjZL9PzM2Hmba+XpP/U+iPb+iuZWIrADEz7yp/F3wU0<br />
jhQqarbNkT2Znk+JIhfSpGAzTIK/FXf17H+eHHOi5MG+/gtvWe2mVH9swusfGwLO<br />
HIwoOBxfsCkab7LpgSw6/PD2tEJG4mkTiW2HxKGCNO01Md+SUEPpm3KZzurtt09a<br />
ko4S87mUNDqrz4p8Q2/zrZw4uVYuTthHb6YdnU9caFYLuCDASR8YmhejTHxf7OBQ<br />
p7b70mPjISF8vQhsVgLPYnl35xZUgGS0jfGqTAtRla4BsTe+BgDiHzO1HqXXw1M+<br />
SIC+k1ARovhlGcDHbZZ2xDwaURZ3IpkFZstR01wyY98aLkULDac28LI3qS2/mZNk<br />
TXYSqC+nNhy5QZA8gxX0pOVI+6bc0sOrxAjqCtsbyI02kQHGYJA4rPb8G5gClTaH<br />
C3YTjh8vx7oJEreuJ1xF2qm56DvmbLoqQ6qbydKIwRz+lUgfB0n3+q6K5Fp4L+1l<br />
aVg8jANaBvxkT+DrrPflYCC4xD4TB++ABQARAQABiQIlBBgBAgAPBQJT5O+KAhsM<br />
BQkSzAMAAAoJEO9zTqZ38xEppnAP/04jejeBWay3+YbHqFVCvL76G3x0VY0iIBI8<br />
G8PcTkRZupaLqaapIg5LoLGNTQ+dzFME8Je3PGj9bO4cZCD/G015DRPxvaUFJxkD<br />
D3eqbUhwdctR7nD9NqnphoOZJgIhkB21sfNh89bgkrtya9yO8XyOFMU4EQ4VVCRO<br />
LX0btxpWi3T7AvV7YNEcNcB7kKKcSlosGXAd4S7/mPrBzd6uiFRmUr0hsByWPiJl<br />
NBtqrcTKpReXn10E443GYvl50nHNWKyEhhAYjID1Y/VLKVe36Q7zY0SpkbY7F1cC<br />
XOO4nwLakAb6dsu0OjiFyyI38wBpf38kHsxdyVPmKh6sXjI2AoR1+rsubKexNR3z<br />
D8iXKnsAP4Fai6PI73iLyH14q+N/0+9LDFC4CNGnGd7tkkPy8Kww1cEdJt4QrYuL<br />
BK0cv/Djve+JekMPncno4vFfprlG6aZH6uLFswft2AowlDsWXIOmGbeivoJKQYSK<br />
vUoDTLW+pA0W0eGC4VqkBYwMpomNBA2C9lSY6jqFtmqa9QXU5Zx3oYDqPdY5R7d8<br />
Mld9uro/0mbGrriinzzt1gqyDvGNCr/sozvDJFypddxsF2C821UM/4SfME0fJhj/<br />
eazhggcTkkfFD0tXjI9xaRhO9vVek0gVVutJcB7IYdU1P5I7qiUWi9tYgLcDP3J6<br />
xozVpKhO<br />
=oUJc<br />
-----END PGP PUBLIC KEY BLOCK-----</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68391PayJoin adoption2021-01-21T14:59:49Z<p>Belcher: /* Exchanges */ Added hodlhodl since they said so on twitter</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{Planned}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{Planned}} || {{Planned}} || https://twitter.com/hodlhodl/status/1352266122389827584<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68390PayJoin adoption2021-01-21T14:58:56Z<p>Belcher: /* Software Wallets */ Electrum should be "planned" for receiving too</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{Planned}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68389PayJoin adoption2021-01-19T15:27:02Z<p>Belcher: /* Software Wallets */ Add Electrum's issue and change to planned</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{Planned}} || {{No}} || https://github.com/spesmilo/electrum/issues/6585<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68388PayJoin adoption2021-01-19T15:04:33Z<p>Belcher: Typo</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownership assumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Signing !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68386PayJoin adoption2021-01-16T13:15:44Z<p>Belcher: Not too sure about nurails for now</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Evaluating|??}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework".<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68385PayJoin adoption2021-01-16T13:14:48Z<p>Belcher: /* Payment processors */ Add nurails which seems to have payjoin</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|-<br />
| Nurails || {{Yes}} || https://nurails.com/ "Our infrastructure is open source and community driven using Payjoin security framework"<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68384PayJoin adoption2021-01-16T13:07:47Z<p>Belcher: /* Software Wallets */ Rename GreenAddress -> Blockstream Green</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| Blockstream Green || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin&diff=68383PayJoin2021-01-16T13:07:28Z<p>Belcher: /* External links */ Add blockstream blog link</p>
<hr />
<div>PayJoin (also called ''pay-to-end-point'' or ''P2EP'') is a special type of [[CoinJoin]] between two parties where one party pays the other. This [[CoinJoin|coinjoin]] type has different (probably better) privacy properties. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]].<br />
<br />
Consider this transaction:<br />
<br />
2 btc ---> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple [[transaction]] paying to somewhere with leftover [[change]]. Another interpretation is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a [[CoinJoin]] [[transaction]] which breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin [[transaction]].<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[Transaction surveillance company|Transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
<br />
=== Probable examples ===<br />
In general payjoins are indistinguishable from any regular bitcoin [[transaction]]s, but sometimes their creators publish them online and say they are actually payjoins.<br />
<br />
* <code>7104bae698587b3e75563b7ea7a9aada41d9c787788bc2bf26dd201fd7eca8a2</code><ref>https://mastodon.social/@waxwing/101387762796750634</ref>.<br />
<br />
== External links ==<br />
* https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/<br />
* https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6<br />
* https://samouraiwallet.com/stowaway - A smartphone wallet which implements payjoin.<br />
* https://joinmarket.me/blog/blog/payjoin/<br />
* https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e<br />
* https://wasabiwallet.io/ - PayJoin-enabled Bitcoin Desktop Wallet<br />
* https://www.blockstream.com/2020/04/16/en-bitcoin-privacy-improves-with-btcpay-servers-p2ep-implementation/<br />
<br />
== See also ==<br />
<br />
* [[CoinJoin]]<br />
* [[PayJoin adoption]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68382PayJoin adoption2021-01-16T13:07:05Z<p>Belcher: Add the kratom syndicate</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| The Kratom Syndicate || {{Yes}} || https://thekratomsyndicate.com/blog/buying-kratom-with-payjoin.html<br />
|}</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68381PayJoin adoption2021-01-16T12:47:09Z<p>Belcher: Add note about cost and benefit</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
Like any new feature, PayJoin requires a little bit of time to first set up. But if your business suffers from being spied on (for example you're a p2p exchange or bitcoin casino, and regulated exchanges keep banning your customers) then that cost is well worth it.<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68380PayJoin adoption2021-01-16T12:24:25Z<p>Belcher: /* Exchanges */ Clarify headings in table</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to exchange !! Receive from exchange !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{Yes}} || {{No}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68379PayJoin adoption2021-01-16T12:20:38Z<p>Belcher: /* Exchanges */ Add sideshift.ai</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|-<br />
| Sideshift.ai || {{No}} || {{Yes}} || For "To send" choose "Bitcoin PayJoin"<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68378PayJoin adoption2021-01-16T12:13:22Z<p>Belcher: Added sparrow wallet, HRF and waxwing's personal site</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic|common input ownershipassumption]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin, or who else transacted to them.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{No}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Sparrow Wallet || {{Yes}} || {{Evaluating|??}} || https://github.com/sparrowwallet/sparrow/releases/tag/0.9.7<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|}<br />
<br />
=== Non-profits ===<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! URL !! Notes<br />
|-<br />
| Human Rights Foundation || {{Yes}} || https://hrf.org/donate-bitcoin/payjoin/ ||<br />
|-<br />
| Waxwing's personal donation page || {{Yes}} || https://joinmarket.me/donations/ ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68376PayJoin adoption2021-01-16T01:06:39Z<p>Belcher: Added coldcard</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Evaluating|??}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Hardware Wallets ===<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Coldcard || {{Yes}} || {{No}} || Hardware can sign bip78 payjoins and also http://ckbunker.com/<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
==== BTCPay stores which accept PayJoin ====<br />
<br />
// TODO<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin&diff=68375PayJoin2021-01-16T01:04:18Z<p>Belcher: /* See also */ Linked payjoin adoption page</p>
<hr />
<div>PayJoin (also called ''pay-to-end-point'' or ''P2EP'') is a special type of [[CoinJoin]] between two parties where one party pays the other. This [[CoinJoin|coinjoin]] type has different (probably better) privacy properties. The [[transaction]] then doesn't have the distinctive multiple outputs with the same value, and so is not obviously visible as an equal-output [[CoinJoin]].<br />
<br />
Consider this transaction:<br />
<br />
2 btc ---> 3 btc<br />
5 btc 4 btc<br />
<br />
It could be interpreted as a simple [[transaction]] paying to somewhere with leftover [[change]]. Another interpretation is that the 2 BTC input is owned by a merchant and 5 BTC is owned by their customer, and that this transaction involves the customer paying 1 BTC to the merchant. There is no way to tell which of these two interpretations is correct. The result is a [[CoinJoin]] [[transaction]] which breaks the [[common-input-ownership heuristic]] and improves privacy, but is also undetectable and indistinguishable from any regular bitcoin [[transaction]].<br />
<br />
If PayJoin [[transaction]]s became even moderately used then it would make the [[common-input-ownership heuristic]] be completely flawed in practice. As they are undetectable we wouldn't even know whether they are being used today. As [[Transaction surveillance company|Transaction surveillance companies]] mostly depend on that heuristic, as of 2019 there is great excitement about the PayJoin idea<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html</ref>.<br />
<br />
<br />
=== Probable examples ===<br />
In general payjoins are indistinguishable from any regular bitcoin [[transaction]]s, but sometimes their creators publish them online and say they are actually payjoins.<br />
<br />
* <code>7104bae698587b3e75563b7ea7a9aada41d9c787788bc2bf26dd201fd7eca8a2</code><ref>https://mastodon.social/@waxwing/101387762796750634</ref>.<br />
<br />
== External links ==<br />
* https://blockstream.com/2018/08/08/improving-privacy-using-pay-to-endpoint/<br />
* https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6<br />
* https://samouraiwallet.com/stowaway - A smartphone wallet which implements payjoin.<br />
* https://joinmarket.me/blog/blog/payjoin/<br />
* https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e<br />
* https://wasabiwallet.io/ - PayJoin-enabled Bitcoin Desktop Wallet<br />
<br />
== See also ==<br />
<br />
* [[CoinJoin]]<br />
* [[PayJoin adoption]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Privacy]]</div>Belcherhttps://tests.bitcoin.it/w/index.php?title=PayJoin_adoption&diff=68374PayJoin adoption2021-01-16T00:11:27Z<p>Belcher: /* Exchanges */ Add localbitcoins</p>
<hr />
<div>[[PayJoin]] is a privacy improvement for bitcoin. In the case where a customer pays a merchant, they both together co-operate to create a single bitcoin transaction which mixes both their coins and masks the payment amount.<br />
<br />
[[Transaction surveillance company|Transaction surveillance companies]] heavily depend on the [[Common-input-ownership heuristic]] which is broken by PayJoin transactions. So if those transactions became even a little bit widespread they could massively decrease the reliability of blockchain surveillance. Merchants and customers who adopt PayJoin would find their privacy improved from anyone analyzing the blockchain, for example a surveillance company spy would find it much harder to figure out which addresses and transactions belonged to a particular merchant that was using PayJoin.<br />
<br />
PayJoin transactions are indistinguishable from regular bitcoin transactions by design, so it's very hard to get an accurate number for how common they are.<br />
<br />
The PayJoin protocol standard most likely to get adoption is [[BIP 0078]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| {{No}} ||<br />
|-<br />
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder<br />
|-<br />
| {{Planned}} || The developers said they plan to<br />
|-<br />
| {{Weak|Non-BIP78}} || Implements a form of PayJoin but not BIP78<br />
|-<br />
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.<br />
|-<br />
| {{Yes}} || Feature has been released<br />
|}<br />
<br />
=== Software Wallets ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Sending !! Receiving !! Notes<br />
|-<br />
| Wasabi Wallet || {{Yes}} || {{Evaluating|??}} || https://docs.wasabiwallet.io/using-wasabi/PayJoin.html<br />
|-<br />
| JoinMarket || {{Yes}} || {{Yes}} || https://old.reddit.com/r/Bitcoin/comments/idhrak/new_release_of_joinmarket_070_includes_bip78/<br />
|-<br />
| Bluewallet || {{Yes}} || {{Evaluating|??}} || https://old.reddit.com/r/Bitcoin/comments/j6qswf/bluewallet_releases_payjoin_bip78/<br />
|-<br />
| Samourai Wallet || {{Weak|Non-BIP78}} || {{Weak|Non-BIP78}} || https://samouraiwallet.com/stowaway<br />
|-<br />
| Bitcoin Core || {{No}} || {{No}} ||<br />
|-<br />
| Bitcoin Knots || {{No}} || {{No}} ||<br />
|-<br />
| Electrum || {{No}} || {{No}} ||<br />
|-<br />
| bcoin || {{No}} || {{No}} ||<br />
|-<br />
| Armory || {{No}} || {{No}} ||<br />
|-<br />
| GreenAddress || {{No}} || {{No}} ||<br />
|-<br />
| Breadwallet || {{No}} || {{No}} ||<br />
|-<br />
| Coinomi || {{No}} || {{No}} ||<br />
|-<br />
| BTC.com || {{No}} || {{No}} ||<br />
|-<br />
| Casa || {{No}} || {{No}} ||<br />
|-<br />
| Mycelium || {{No}} || {{No}} ||<br />
|-<br />
| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Bitcoin Wallet for Android] || {{No}} || {{No}} ||<br />
|-<br />
| Trust Wallet || {{No}} || {{No}} ||<br />
|-<br />
| Guarda Wallet || {{No}} || {{No}} ||<br />
|-<br />
|}<br />
<br />
=== Payment processors ===<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Receive !! Notes<br />
|-<br />
| [[BTCPay]] || {{Yes}} || First implementer of BIP78 payjoin for merchants.<br />
|}<br />
<br />
==== BTCPay stores which accept PayJoin ====<br />
<br />
// TODO<br />
<br />
=== Exchanges ===<br />
<br />
P2P exchanges make the most sense as early adoptors of PayJoin. All exchanges are welcome on this list of course.<br />
<br />
<!-- Exchanges in alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| [[AgoraDesk]] || {{No}} || {{No}} || <br />
|-<br />
| Bisq || {{No}} || {{No}} ||<br />
|-<br />
| Hodl Hodl || {{No}} || {{No}} ||<br />
|-<br />
| LocalBitcoins || {{No}} || {{No}} ||<br />
|-<br />
| LocalCoinSwap || {{No}} || {{No}} ||<br />
|-<br />
| LocalCryptos || {{No}} || {{No}} ||<br />
|-<br />
| Paxful.com || {{No}} || {{No}} ||<br />
|}<br />
<br />
=== Casinos ===<br />
<br />
Bitcoin casinos are very natural early-adopters of PayJoin. An early protocol specification for it, called bustapay, was created by the owner of a bitcoin casino.<br />
<br />
<!-- Alphabetical order please --><br />
{| class="wikitable sortable"<br />
|-<br />
! Name !! Send to !! Create/receive !! Notes<br />
|-<br />
| Bustabit || {{No}} || {{No}} || <br />
|-<br />
|}<br />
<br />
<br />
=== Stores ===<br />
<br />
// TODO</div>Belcher