Bitcoin Wiki - User contributions [en]

Talk:Comparison of cryptocurrencies

2020-06-03T23:04:02Z

JonathanCross: /* Anonymity */ Updating comment

The order / grouping of these coins are still TBD.

==suggestion not to include market cap==
market cap changes too often, no point in adding that data to the wiki. Can just link to coinmarketcap or whatever.
[[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 22:44, 7 April 2014 (UTC)

[[User:Ripper234|Ripper234]] proposes a grouping of Major, Minor and New by an arbitrary market cap limit. This can be done once the market caps of the alts are known.
* Using market cap will make Tonal Bitcoin a "Major" despite de facto minor usage. Therefore, I suggest finding a different method of categorizing. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 05:06, 4 March 2013 (GMT)

**I have removed all market cap values. Nevertheless, I have ordered the list in two groups: Top 10 by market cap (according to http://coinmarketcap.com/), and the rest ordered alphabetical. I think that this is the best compromise. The "new" category was so old as to be laughable, as every day there are new coins being created. I don't think that it is in our best interest to have a definitive list of all crytpocurrencies, as there are now hundreds, and soon thousands. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

*** I am going to re-remove the market-cap stuff soon, mostly because the values are meaningless and that there is no such thing as a currency market cap, and secondarily because the market cap value is so trivially manipulable. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:42, 7 June 2017 (UTC)

==Removed Tonal bitcoin==

I have removed [[Tonal Bitcoin]] (TBC) from the list because it is not an alternative currency, it has no market cap, it can not be traded, and it is not accepted for payments anywhere. As far as I can tell, tonal bitcoin is just a way of representing bitcoin amounts using the tonal number system. If this is true, it is part of bitcoin, and is thus not a separate currency. This should be discussed elsewhere in this wiki, not here [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

* It is an alternative currency, and one of the few legit ones. It shares a market cap with BTC, and can be traded just like any other currency. Sharing a blockchain, or at least values, with BTC is the ideal for altcoins, and necessary to protect against scammer abuses. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 11:49, 20 August 2014 (UTC)

**Could you please provide some supporting evidence? Such as a project web page, etc? I can't find any information to back up your claims. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 20:25, 20 August 2014 (UTC)

***I linked the [[Tonal Bitcoin]] article in the heading. You can also read a more user-friendly summary on the [https://bitcointalk.org/index.php?topic=218388.0 BitcoinTalk forum thread] for it. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 13:53, 21 August 2014 (UTC)

==Scamcoin removals==

There are quite a number of scamcoins listed on there. Ripple, for example, is pretty much a pure scamcoin. Dash is a scamcoin. Bytecoin is 100% a scamcoin which underwent silent, broken inflation thanks to a cryptonote flaw. It's important that a Bitcoin Wiki not promote coins that have a highly scam-filled history. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:49, 7 June 2017 (UTC)
** WARNING: User davidhedlund, we can either discuss the contents of this page in here, or I'm going to have to remove your edit rights. Please stop adding back in scamcoins on the comparison page. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:16, 21 September 2017 (UTC)

:Midnightmagic: I'm sorry, its not my intention to promote scamcoins. Can you please 1) Add comments in the article in the website fields for Bitcoin Cash and DASH why bitcoincash.org and dash.org respectively should not be visible? 2) motivate why you think these cryptocurrencies are scamcoins?:
* Dash: "Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system.
:: Yep. Pretty much. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* NEM: "NEM is a PoS coin." - https://en.wikipedia.org/wiki/Proof-of-stake#Criticism
:: PoS has nothing-at-stake. No point in listing scamcoins with PoS. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Ripple: ?
::Ripple is a massive scamcoin and has no basis whatsoever in reality. It jumped on Ryan Fugger's coattails, and ran off with what would eventually end up being a SEC-fined scamcoin which destroyed even its own P2P stand-in token mechanism. Its market "cap" is a joke because the centralized tokens can simply be issued by the centralized creator of the tokens. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 22:44, 2 October 2017 (UTC)

:: Hello. Thanks for posting in here. Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system. Ripple is a centralized non-currency scam which has been fined multiple times, and involved in significant lawsuits with the end effect being its current form is essentially purely a cash grab. NEM is a PoS coin. XEM is just the ticker for NEM isn't it? [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 11:00, 4 October 2017 (UTC)

:::Thank you for your response. Yes XEM is the ticker so I removed it from my list in this Talk page. I have a few questions left:
* Can you please have a look at https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=64059&oldid=63963 the websites must be commented because someone else will add them otherwise.
::::I'm fine with removing them over time. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Regarding BCH, please update the comment that I added in this revision: https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&oldid=64067
* Please motivate why Ripple should be banned.
:::: Ripple is a scamcoin. There's no point in driving traffic to a scamcoin. But it's not banned. It's just not a legitimate comparison to make with Bitcoin. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Remove Dash from the article or motivate why it should stay there.
:::: I agree. Probably Dash should be removed. Probably all the scamcoins should be removed. Literally the only reason they're still there is you keep editing this page. :-) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
::::: Can you please remove all scamcoins from the page then (you can add that I agree with you about this in the edit summary)? --[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 04:10, 8 March 2018 (UTC)
* Is it ok if I add a ==Blacklisted== section in the article and use the quotes that I updated to my list above?
:::: Probably not. Otherwise the list would stretch into the thousands. It'd be useless. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

==Bcash Symbol==

The Bitcoin Cash developers are extremely hostile to Bitcoin, and consist of e.g. deadalnix who is an unapologetic copyright thief. Their attempt to conflate "Bitcoin Cash" with "Bitcoin" includes a mistaken co-opting of another scamcoin's symbol, "BCC" which is already being traded on some exchanges as BCC. The way to disambiguate it from the prior scamcoin is to use BCH, which is the symbol both exchanges, and ticker sites use. They can call it what they want, but given the level of hostility, it really doesn't make sense to contribute to user confusion here. (Note the huge spike in the *scamcoin* BCC around August 1 for an example of this deliberate obfuscation.) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 00:55, 22 September 2017 (UTC)

== Anonymity ==

[[User:Midnightmagic|Midnightmagic]]: Can you motivate why you added [https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=63959&oldid=63941 changed] these cryptocurrencies from "High" to "Medium" anonymity (they are our best bet in terms of anonymity):
* Monero: ? (recently introduced "Ring Confidential Transactions" so it is regarded as anonymous by many)
* Zcash: ?
:: They are medium anonymity because zcash's anonymity set is very small; Monero's is larger but not impenetrable; besides, listening in on the network provides a great deal of information that a pure analysis of the blockchain itself does not. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 19:07, 4 October 2017 (UTC)
::: It's been a few years... Given that "Low", "Medium" and "High" are all relative, it seems like we should consider using the full range. Monero does not offer perfect privacy, but the anonymity set is the largest of the coins listed. "impenetrable" sounds like "perfect" anonymity (which is impossible in practice). If Zcash ever changed to force all transactions to be shielded, we might consider it as "High". Seeing that Monero now uses Dandelion++ (obfuscating originating server) and a fixed ring size (making all transactions look the same), I'd like to nominate it for the "High" position. Thoughts? – [[User:JonathanCross|JonathanCross]] ([[User talk:JonathanCross|talk]]) 22:15, 28 May 2020 (UTC)
:::: Okay, went ahead and implemented [https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&type=revision&diff=67651&oldid=67565 here] (it's a wiki afterall) – [[User:JonathanCross|JonathanCross]] ([[User talk:JonathanCross|talk]]) 23:03, 3 June 2020 (UTC)

== Conspicuously missing links ==

[[User:Oflameo|Oflameo]]: Conspicuously missing links look terrible from a wiki perspective. It would look better to add the links back for https://www.bitcoincash.org and https://www.dash.org/ and say what you need to say about them on the internal page. "It is a scamcoin" is not appropriate criteria when Big Media is saying just that about Bitcoin. That is why a whole article is necessary to prove the claim.
:: Big Media is not an authority on cryptocurrencies. That comparison is false. This is the Bitcoin wiki. We can elevate ourselves to a better standard than that. Conspicuously missing links are fine. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

::: [[User:Oflameo|Oflameo]]: You aren't making an effort to be any better then Big Media [[User talk:Midnightmagic|talk]]. What you are doing is going '''Scamcoin! REEE! CensorZap!'''. Please define an an explicit criteria for a scamcoin so we can properly flag samcoins. What you said on these talk pages so far aren't very convincing IMO. Your actions are evidently anti-productive. [[User:Oflameo|Oflameo]] ([[User talk:Oflameo|talk]]) 22:25, 10 January 2018 (UTC)

:::: Use the four-tildes at the end of your note to sign it. A scamcoin is one which has no sound technological advances nor engineering behind it; is a premined coin with a history based in illegal behaviour or law-evading behaviour; is one which incompetent people have built it or are enriching themselves at the expense of innocent victims to whom they are lying to try to get them to dump money into it; or one which makes technical claims about a coin which are not founded in reality; or one which pumps itself endlessly in seminars. Fraud is usually central to a scamcoin. This is the Bitcoin wiki. This is not put-your-favourite-scamcoin-in-here-for-SEO-purposes-wiki. Please stop marking up the Bitcoin wiki with links to coins which are based in scams or I'll simply delete this page to avoid this argument altogether. To be honest, I'm about 45% of the way to deleting this page in its entirety to begin with, since it seems to be attracting angry argumentative people who have bad attitudes and make stupid comparisons between me and whoever they have a beef with. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:26, 10 January 2018 (UTC)

Comparison of cryptocurrencies

2020-06-03T22:59:49Z

JonathanCross: Setting Monero to "High" privacy as much has changed and the scale (Low, Medium, High) is relative. See Talk page. Also added tail emission info and centered the "Medium" labels.

The cryptocurrency market is explosive which currently serves hundreds of currencies. Almost all of them are obvious scams—including many which purport to have a large market cap. This article aims to list only the most relevant cryptocurrencies in terms of novel technological advancements or strong engineering teams, or due to widespread awareness thereof. Direct, low-level scams should not be listed here.

{| class="wikitable sortable"
! style="width: 100px;" | Cryptocurrency
! Exchange symbol
! Launched
! Anonymity
! Max supply
! Algorithm
! Proof Type
! Notes
! Website
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Bitcoin]]
| BTC
| 2009-01-03
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First blockchain.
| [https://bitcoin.org/ bitcoin.org]
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Tonal Bitcoin]]
| TBC
| 2011-01-02
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First on-chain alternative.
| -
|-
! {{rh}} | [[File:Bitcoin_Cash.png|16px|link=]] BCash
| BCH
| 2017-08-01
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| BCash is an altcoin based on an old snapshot of Bitcoin's blockchain (2017 Aug 1) with replay protection and an increased block size limit of 8MB. An unusual emergency difficulty adjustment algorithm causes significant periods of hyperinflation. Significant miner centralization; often a very low hashrate. Major proponents deliberately attempt to confuse new users into thinking BCash is actually Bitcoin, especially by using the name "Bitcoin Cash". On 15 November 2018, an airdrop of BCash occurred between two rival factions now called BCash (BCH) and CraigCoin (BSV).
| [https://www.bitcoincash.org/ bitcoincash.org]
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] CraigCoin
| BSV
| 2018-11-15
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| On 15 November 2018, a hard fork chain split of BCash occurred between two rival factions called BCH and BSV. Mostly based around a cult following of the fraudster Craig Wright who claims to be Satoshi (hence SV = Satoshi's Vision).
| https://bitcoinsv.io/
|-
! {{rh}} | [[File:Namecoin.png|16px|link=]] Namecoin
| NMC
| 2011-04-18
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256 Merged
| PoW
| First cryptocurrency that implemented Satoshi's BitDNS idea. Essentially the first real altcoin. Still under active development. First merged-mined altcoin.
| [https://namecoin.info/ namecoin.info]
|-
! {{rh}} | [[File:Dash.png|16px|link=]] Dash
| DASH
| 2014-01-18
| {{no|Low}}
| style="text-align: right" | 22,000,000
| X11
| PoW/PoS
| Introduced the X11 algorithm, which is just a composite function of multiple hashing algorithms. Had a significant failure mode in the beginning which equated to a majority premine by a small number of Amazon EC2 customers. This means their Master Node algorithm has been in a failure mode from the beginning.
| [https://dash.org/ dash.org]
|-
! {{rh}} | [[File:Ethereum_Classic-32x32.png|16px|link=]] Ethereum Classic
| ETC
| 2015-08-07
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| Majority premine sale. Used to be known as just "Ethereum" and "ETH" until the Ethereum Foundation split off an altcoin using their trademark.
| [http://www.ethereumclassic.org/ ethereumclassic.org]
|-
! {{rh}} | [[File:Ethereum.png|16px|link=]] Ethereum
| ETH
| 2016-07-20
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| An altcoin of Ethereum Classic which split from ETC's blockchain in order to refund the Ethereum Foundation's members' money when the DAO was exploited. Regular hardforks to bail out larger losses by e.g. ETH foundation. Source of the ICO bubbles. Multiple client implementations which fail against each other in terms of consensus errors regularly. Requires multiple months of time to sync to eth blockchain. Contract-building tools interpret input incompatibly.
| [https://ethereum.org ethereum.org ]
|-
! {{rh}} | [[File:Litecoin.png|16px|link=]] Litecoin
| LTC
| 2011-10-07
| {{no|Low}}
| style="text-align: right" | ~84,000,000
| Scrypt
| PoW
| Originally meant to be a CPU-friendly "silver" to Bitcoin's "gold", the early SCRYPT parameters, it was discovered later, led directly to GPU, and then ASIC-mining almost from the start.
| [https://litecoin.org/ litecoin.org]
|-
! {{rh}} | [[File:Monero.png|16px|link=]] Monero
| XMR
| 2014-04-18
| {{yes|High}}
| Infinite (has tail emission of 0.6 XMR)
| [https://github.com/tevador/RandomX RandomX] (formerly [[CryptoNight]])
| PoW
| The most successful implementation derived from the [[CryptoNote]] codedrop. Uses [https://www.ledgerjournal.org/ojs/index.php/ledger/article/view/34 Ring CT] and its own implementation of [[Confidential transactions]], [[ECDH_address|Stealth Addresses]], [[BIP_0156|Dandelion]]++ to enhance user privacy.
| [https://getmonero.org/ getmonero.org]
|-
! {{rh}} | [[File:Zcash-16x16.png|16px|link=]] Zcash
| ZEC
| 2016-10-28
| style="background: lightyellow;text-align: center;" | Medium
| style="text-align: right" | ~21,000,000
| Equihash
| PoW
| First cryptocurrency that implemented the zerocash protocol. Large "Founder's Reward" which is paid out over the first few years of mining to people including Roger Ver.
| [https://z.cash/ z.cash]
|-
! {{rh}} | [[File:Zcoin-800x800.png|16px|link=]] Zcoin
| XZC
| 2016-09-28
| style="background: lightyellow;text-align: center;" | Medium
| style="text-align: right" | ~21,000,000
| Lyra2RE
| PoW
| First cryptocurrency that implemented the zerocoin protocol which also makes it the first useful Zero-knowledge proof based anonymous cryptocurrency. First that implements Merkle Tree Proof of Work (MTP).
| [https://zcoin.io/ zcoin.io]
|-}

[[Category:Alternative cryptocurrencies]]

User:JonathanCross

2020-05-28T22:20:12Z

JonathanCross: Adding PGP key fingerprint.

* https://JonathanCross.com
* https://github.com/jonathancross
* OpenPGP key fingerprint: <code>9386 A2FB 2DA9 D0D3 1FAF 0818 C0C0 7613 2FFA 7695</code>

Talk:Comparison of cryptocurrencies

2020-05-28T22:16:35Z

JonathanCross: /* Anonymity */ Add Monero as "High" privacy?

The order / grouping of these coins are still TBD.

==suggestion not to include market cap==
market cap changes too often, no point in adding that data to the wiki. Can just link to coinmarketcap or whatever.
[[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 22:44, 7 April 2014 (UTC)

[[User:Ripper234|Ripper234]] proposes a grouping of Major, Minor and New by an arbitrary market cap limit. This can be done once the market caps of the alts are known.
* Using market cap will make Tonal Bitcoin a "Major" despite de facto minor usage. Therefore, I suggest finding a different method of categorizing. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 05:06, 4 March 2013 (GMT)

**I have removed all market cap values. Nevertheless, I have ordered the list in two groups: Top 10 by market cap (according to http://coinmarketcap.com/), and the rest ordered alphabetical. I think that this is the best compromise. The "new" category was so old as to be laughable, as every day there are new coins being created. I don't think that it is in our best interest to have a definitive list of all crytpocurrencies, as there are now hundreds, and soon thousands. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

*** I am going to re-remove the market-cap stuff soon, mostly because the values are meaningless and that there is no such thing as a currency market cap, and secondarily because the market cap value is so trivially manipulable. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:42, 7 June 2017 (UTC)

==Removed Tonal bitcoin==

I have removed [[Tonal Bitcoin]] (TBC) from the list because it is not an alternative currency, it has no market cap, it can not be traded, and it is not accepted for payments anywhere. As far as I can tell, tonal bitcoin is just a way of representing bitcoin amounts using the tonal number system. If this is true, it is part of bitcoin, and is thus not a separate currency. This should be discussed elsewhere in this wiki, not here [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 09:49, 20 August 2014 (UTC)

* It is an alternative currency, and one of the few legit ones. It shares a market cap with BTC, and can be traded just like any other currency. Sharing a blockchain, or at least values, with BTC is the ideal for altcoins, and necessary to protect against scammer abuses. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 11:49, 20 August 2014 (UTC)

**Could you please provide some supporting evidence? Such as a project web page, etc? I can't find any information to back up your claims. [[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 20:25, 20 August 2014 (UTC)

***I linked the [[Tonal Bitcoin]] article in the heading. You can also read a more user-friendly summary on the [https://bitcointalk.org/index.php?topic=218388.0 BitcoinTalk forum thread] for it. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 13:53, 21 August 2014 (UTC)

==Scamcoin removals==

There are quite a number of scamcoins listed on there. Ripple, for example, is pretty much a pure scamcoin. Dash is a scamcoin. Bytecoin is 100% a scamcoin which underwent silent, broken inflation thanks to a cryptonote flaw. It's important that a Bitcoin Wiki not promote coins that have a highly scam-filled history. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 18:49, 7 June 2017 (UTC)
** WARNING: User davidhedlund, we can either discuss the contents of this page in here, or I'm going to have to remove your edit rights. Please stop adding back in scamcoins on the comparison page. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:16, 21 September 2017 (UTC)

:Midnightmagic: I'm sorry, its not my intention to promote scamcoins. Can you please 1) Add comments in the article in the website fields for Bitcoin Cash and DASH why bitcoincash.org and dash.org respectively should not be visible? 2) motivate why you think these cryptocurrencies are scamcoins?:
* Dash: "Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system.
:: Yep. Pretty much. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* NEM: "NEM is a PoS coin." - https://en.wikipedia.org/wiki/Proof-of-stake#Criticism
:: PoS has nothing-at-stake. No point in listing scamcoins with PoS. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Ripple: ?
::Ripple is a massive scamcoin and has no basis whatsoever in reality. It jumped on Ryan Fugger's coattails, and ran off with what would eventually end up being a SEC-fined scamcoin which destroyed even its own P2P stand-in token mechanism. Its market "cap" is a joke because the centralized tokens can simply be issued by the centralized creator of the tokens. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 22:44, 2 October 2017 (UTC)

:: Hello. Thanks for posting in here. Dash is a massive premine with masternodes that are likely dominated by said premine. The preminers thanks to Dash's built-in centralizing reward system are essentially guaranteed to maintain with less hashrate, their dominance due to the 45% forced reward system. Ripple is a centralized non-currency scam which has been fined multiple times, and involved in significant lawsuits with the end effect being its current form is essentially purely a cash grab. NEM is a PoS coin. XEM is just the ticker for NEM isn't it? [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 11:00, 4 October 2017 (UTC)

:::Thank you for your response. Yes XEM is the ticker so I removed it from my list in this Talk page. I have a few questions left:
* Can you please have a look at https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=64059&oldid=63963 the websites must be commented because someone else will add them otherwise.
::::I'm fine with removing them over time. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Regarding BCH, please update the comment that I added in this revision: https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&oldid=64067
* Please motivate why Ripple should be banned.
:::: Ripple is a scamcoin. There's no point in driving traffic to a scamcoin. But it's not banned. It's just not a legitimate comparison to make with Bitcoin. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
* Remove Dash from the article or motivate why it should stay there.
:::: I agree. Probably Dash should be removed. Probably all the scamcoins should be removed. Literally the only reason they're still there is you keep editing this page. :-) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
::::: Can you please remove all scamcoins from the page then (you can add that I agree with you about this in the edit summary)? --[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 04:10, 8 March 2018 (UTC)
* Is it ok if I add a ==Blacklisted== section in the article and use the quotes that I updated to my list above?
:::: Probably not. Otherwise the list would stretch into the thousands. It'd be useless. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

==Bcash Symbol==

The Bitcoin Cash developers are extremely hostile to Bitcoin, and consist of e.g. deadalnix who is an unapologetic copyright thief. Their attempt to conflate "Bitcoin Cash" with "Bitcoin" includes a mistaken co-opting of another scamcoin's symbol, "BCC" which is already being traded on some exchanges as BCC. The way to disambiguate it from the prior scamcoin is to use BCH, which is the symbol both exchanges, and ticker sites use. They can call it what they want, but given the level of hostility, it really doesn't make sense to contribute to user confusion here. (Note the huge spike in the *scamcoin* BCC around August 1 for an example of this deliberate obfuscation.) [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 00:55, 22 September 2017 (UTC)

== Anonymity ==

[[User:Midnightmagic|Midnightmagic]]: Can you motivate why you added [https://en.bitcoin.it/w/index.php?title=Comparison_of_cryptocurrencies&diff=63959&oldid=63941 changed] these cryptocurrencies from "High" to "Medium" anonymity (they are our best bet in terms of anonymity):
* Monero: ? (recently introduced "Ring Confidential Transactions" so it is regarded as anonymous by many)
* Zcash: ?
:: They are medium anonymity because zcash's anonymity set is very small; Monero's is larger but not impenetrable; besides, listening in on the network provides a great deal of information that a pure analysis of the blockchain itself does not. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)
--[[User:Davidhedlund|Davidhedlund]] ([[User talk:Davidhedlund|talk]]) 19:07, 4 October 2017 (UTC)
::: It's been a few years... Given that "Low", "Medium" and "High" are all relative, it seems like we should consider using the full range. Monero does not offer perfect privacy, but the anonymity set is the largest of the coins listed. "impenetrable" sounds like "perfect" anonymity (which is impossible in practice). If Zcash ever changed to force all transactions to be shielded, we might consider it as "High". Seeing that Monero now uses Dandelion++ (obfuscating originating server) and a fixed ring size (making all transactions look the same), I'd like to nominate it for the "High" position. Thoughts? – [[User:JonathanCross|JonathanCross]] ([[User talk:JonathanCross|talk]]) 22:15, 28 May 2020 (UTC)

== Conspicuously missing links ==

[[User:Oflameo|Oflameo]]: Conspicuously missing links look terrible from a wiki perspective. It would look better to add the links back for https://www.bitcoincash.org and https://www.dash.org/ and say what you need to say about them on the internal page. "It is a scamcoin" is not appropriate criteria when Big Media is saying just that about Bitcoin. That is why a whole article is necessary to prove the claim.
:: Big Media is not an authority on cryptocurrencies. That comparison is false. This is the Bitcoin wiki. We can elevate ourselves to a better standard than that. Conspicuously missing links are fine. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 01:50, 19 December 2017 (UTC)

::: [[User:Oflameo|Oflameo]]: You aren't making an effort to be any better then Big Media [[User talk:Midnightmagic|talk]]. What you are doing is going '''Scamcoin! REEE! CensorZap!'''. Please define an an explicit criteria for a scamcoin so we can properly flag samcoins. What you said on these talk pages so far aren't very convincing IMO. Your actions are evidently anti-productive. [[User:Oflameo|Oflameo]] ([[User talk:Oflameo|talk]]) 22:25, 10 January 2018 (UTC)

:::: Use the four-tildes at the end of your note to sign it. A scamcoin is one which has no sound technological advances nor engineering behind it; is a premined coin with a history based in illegal behaviour or law-evading behaviour; is one which incompetent people have built it or are enriching themselves at the expense of innocent victims to whom they are lying to try to get them to dump money into it; or one which makes technical claims about a coin which are not founded in reality; or one which pumps itself endlessly in seminars. Fraud is usually central to a scamcoin. This is the Bitcoin wiki. This is not put-your-favourite-scamcoin-in-here-for-SEO-purposes-wiki. Please stop marking up the Bitcoin wiki with links to coins which are based in scams or I'll simply delete this page to avoid this argument altogether. To be honest, I'm about 45% of the way to deleting this page in its entirety to begin with, since it seems to be attracting angry argumentative people who have bad attitudes and make stupid comparisons between me and whoever they have a beef with. [[User:Midnightmagic|Midnightmagic]] ([[User talk:Midnightmagic|talk]]) 23:26, 10 January 2018 (UTC)

Comparison of cryptocurrencies

2020-05-28T21:54:18Z

JonathanCross: Updating monero info. monero.org is a cybersquatter, actual site is getmonero.org

The cryptocurrency market is explosive which currently serves hundreds of currencies. Almost all of them are obvious scams—including many which purport to have a large market cap. This article aims to list only the most relevant cryptocurrencies in terms of novel technological advancements or strong engineering teams, or due to widespread awareness thereof. Direct, low-level scams should not be listed here.

{| class="wikitable sortable"
! style="width: 100px;" | Cryptocurrency
! Exchange symbol
! Launched
! Anonymity
! Max supply
! Algorithm
! Proof Type
! Notes
! Website
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Bitcoin]]
| BTC
| 2009-01-03
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First blockchain.
| [https://bitcoin.org/ bitcoin.org]
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] [[Tonal Bitcoin]]
| TBC
| 2011-01-02
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| First on-chain alternative.
| -
|-
! {{rh}} | [[File:Bitcoin_Cash.png|16px|link=]] BCash
| BCH
| 2017-08-01
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| BCash is an altcoin based on an old snapshot of Bitcoin's blockchain (2017 Aug 1) with replay protection and an increased block size limit of 8MB. An unusual emergency difficulty adjustment algorithm causes significant periods of hyperinflation. Significant miner centralization; often a very low hashrate. Major proponents deliberately attempt to confuse new users into thinking BCash is actually Bitcoin, especially by using the name "Bitcoin Cash". On 15 November 2018, an airdrop of BCash occurred between two rival factions now called BCash (BCH) and CraigCoin (BSV).
| [https://www.bitcoincash.org/ bitcoincash.org]
|-
! {{rh}} | [[File:Bitcoin.png|16px|link=]] CraigCoin
| BSV
| 2018-11-15
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256
| PoW
| On 15 November 2018, a hard fork chain split of BCash occurred between two rival factions called BCH and BSV. Mostly based around a cult following of the fraudster Craig Wright who claims to be Satoshi (hence SV = Satoshi's Vision).
| https://bitcoinsv.io/
|-
! {{rh}} | [[File:Namecoin.png|16px|link=]] Namecoin
| NMC
| 2011-04-18
| {{no|Low}}
| style="text-align: right" | ~21,000,000
| SHA256 Merged
| PoW
| First cryptocurrency that implemented Satoshi's BitDNS idea. Essentially the first real altcoin. Still under active development. First merged-mined altcoin.
| [https://namecoin.info/ namecoin.info]
|-
! {{rh}} | [[File:Dash.png|16px|link=]] Dash
| DASH
| 2014-01-18
| {{no|Low}}
| style="text-align: right" | 22,000,000
| X11
| PoW/PoS
| Introduced the X11 algorithm, which is just a composite function of multiple hashing algorithms. Had a significant failure mode in the beginning which equated to a majority premine by a small number of Amazon EC2 customers. This means their Master Node algorithm has been in a failure mode from the beginning.
| [https://dash.org/ dash.org]
|-
! {{rh}} | [[File:Ethereum_Classic-32x32.png|16px|link=]] Ethereum Classic
| ETC
| 2015-08-07
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| Majority premine sale. Used to be known as just "Ethereum" and "ETH" until the Ethereum Foundation split off an altcoin using their trademark.
| [http://www.ethereumclassic.org/ ethereumclassic.org]
|-
! {{rh}} | [[File:Ethereum.png|16px|link=]] Ethereum
| ETH
| 2016-07-20
| {{no|Low}}
| style="text-align: right" | Infinite
| Ethash
| PoW
| An altcoin of Ethereum Classic which split from ETC's blockchain in order to refund the Ethereum Foundation's members' money when the DAO was exploited. Regular hardforks to bail out larger losses by e.g. ETH foundation. Source of the ICO bubbles. Multiple client implementations which fail against each other in terms of consensus errors regularly. Requires multiple months of time to sync to eth blockchain. Contract-building tools interpret input incompatibly.
| [https://ethereum.org ethereum.org ]
|-
! {{rh}} | [[File:Litecoin.png|16px|link=]] Litecoin
| LTC
| 2011-10-07
| {{no|Low}}
| style="text-align: right" | ~84,000,000
| Scrypt
| PoW
| Originally meant to be a CPU-friendly "silver" to Bitcoin's "gold", the early SCRYPT parameters, it was discovered later, led directly to GPU, and then ASIC-mining almost from the start.
| [https://litecoin.org/ litecoin.org]
|-
! {{rh}} | [[File:Monero.png|16px|link=]] Monero
| XMR
| 2014-04-18
| style="background: lightyellow;" | Medium
| ?
| [https://github.com/tevador/RandomX RandomX] (formerly [[CryptoNight]])
| PoW
| The most successful implementation derived from the [[CryptoNote]] codedrop. Uses [https://www.ledgerjournal.org/ojs/index.php/ledger/article/view/34 Ring CT] and its own implementation of [[Confidential transactions]], [[ECDH_address|Stealth Addresses]], [[BIP_0156|Dandelion]]++ to enhance user privacy.
| [https://getmonero.org/ getmonero.org]
|-
! {{rh}} | [[File:Zcash-16x16.png|16px|link=]] Zcash
| ZEC
| 2016-10-28
| style="background: lightyellow;" | Medium
| style="text-align: right" | ~21,000,000
| Equihash
| PoW
| First cryptocurrency that implemented the zerocash protocol. Large "Founder's Reward" which is paid out over the first few years of mining to people including Roger Ver.
| [https://z.cash/ z.cash]
|-
! {{rh}} | [[File:Zcoin-800x800.png|16px|link=]] Zcoin
| XZC
| 2016-09-28
| style="background: lightyellow;" | Medium
| style="text-align: right" | ~21,000,000
| Lyra2RE
| PoW
| First cryptocurrency that implemented the zerocoin protocol which also makes it the first useful Zero-knowledge proof based anonymous cryptocurrency. First that implements Merkle Tree Proof of Work (MTP).
| [https://zcoin.io/ zcoin.io]
|-}

[[Category:Alternative cryptocurrencies]]

Zero Knowledge Contingent Payment

2020-04-08T11:17:08Z

JonathanCross: /* Hash locked transactions */ Its => It's

It's possible to make payments using Bitcoin which are released if and only if some knowledge is disclosed by the payee and to do this in a trustless manner where neither the payer or payee can cheat. This is accomplished using the combination of a hash-locked transaction and a bitcoin-external protocol to set things up so that the data revealed in the hashlock release is the data they need.

==Protocol outline==
===Hash locked transactions===

It's possible to author a payment in the existing Bitcoin system that requires the redeemer to provide a "secret" which hashes to a specified value. [https://blockexplorer.com/tx/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e The 0.01 output here with the SHA256 opcode] is an example of such a transaction. "To collect these funds your transaction must provide a value that hashes to this other value."

Used directly, like in the above example, this is insecure: Once you've published the spending transaction another node could just drop your transaction and use the password in a new transaction that pays him instead.

So— the advice is that you shouldn't use a password alone, you should require a signature and a password. But then what is the use of that?

There are a couple uses but I'll give an example here of one of the more impressive and far-out ones:

===Zero knowledge proof to binding===

Let H() be a complicated computer program. For some H(X)=Y you want to know some X that gives you a particular Y.

Say I happen to _know_ some X that answers your question... and I'd like to sell it to you. But we don't trust each other at all, and because we're computer geeks we have no friends who can act as trusted mediators. Can we make this exchange using Bitcoin with zero trust? The answer turns out to be yes.

Here are some examples of what H() could be:

* H() could be a password hashing algorithm and you're looking for the password that gives you a particular hash in order to crack it.
* Perhaps H() is a complicated program that decides if a piece of music is one you would find beautiful (i.e. Y is a true/false output)
* H() could be a program that verifies possession of a valid [http://en.wikipedia.org/wiki/Biometric_passport machine readable travel document] issued to a particular person. In this case, you would be able to define a payment to someone based on some arbitrary attributes about them, such as their name + date of birth, or perhaps by providing a photo of their face that's then matched against the travel document using the Eigenfaces algorithm. There would be no need to obtain a public key from them ahead of time meaning that, for example, you could send money to someone who was only just born and doesn't yet have a wallet.
* H() could be a program that interprets another program on some secret input and yields true if the input data manages to put the program into a corrupted state. This would allow security researchers to sell exploits to software developers so they can be fixed, but in an anonymous and low trust way.

A [https://en.wikipedia.org/wiki/Zero-knowledge_proof zero-knowledge proof] lets someone prove a mathematical fact to another person without teaching them anything about the fact itself. It has been proven that you can convert any computer program into a zero-knowledge proof (this is referred to mathematically as [http://en.wikipedia.org/wiki/IP_%28complexity%29#PSPACE_is_a_subset_of_IP PSPACE⊂IP] ). So, using a zero-knowledge proof I could prove to you that I know some X such that H(X)=Y ... which is helpful but it's not enough because you could pay me and I could not tell you the answer (or I could tell you and then you don't pay). Here is where the password locked transactions come in.

First I encrypt X with random key K, Ex=AES(X,K).
then I construct the program:

<pre>
Program(K,Ex,H()) => [Ex,Hk,Y] {
Hk=SHA256(K);
Y=H(UNAES(Ex,K));
return [Ex,Hk,Y];
}
</pre>

In English: The program takes the encrypted solution and the key to decrypt it, and outputs the encrypted solution, the hash of the decryption key, and the result of running the program on the solution.

I convert that program into a zero knowledge proof. Externally to Bitcoin I tell you Ex,Hk,Y and then prove that I executed the program faithfully.

You then form a Bitcoin payment which requires both my public key and password K. In order to redeem this transaction I must disclose K, the key you need to decrypt Ex and give you your solution. So neither of us can cheat, so no trust is required.

The [https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/ first ZKCP] was performed on the Bitcoin network in 2016, after waiting almost 5 years for sufficiently powerful general purpose ZKPs to become practically available.

==But what if they're just anti-social and don't redeem the txn?==

If you're concerned that they might rather leave the funds unspent rather than disclose their password, perhaps an effort to extort you, you could construct the payment so that it can alternatively be spent by a "refund transaction" which has a signature from both you and the other party.

You first create the ZKP payment transaction which requires (Password+Their_signature) OR (Their signature plus Your signature). You keep this transaction private. You then write a new transaction, the refund transaction, which spends the payment back to you but has an nlocktime set in the future (e.g. 1000 blocks from now). You sign it, and give it to the other party to sign. He is able to sign it without actually seeing the payment transaction (he only sees its hash). When he returns it, you then release the payment transaction. If he does not redeem the payment transaction before the locktime expires you transmit the refund and recover it yourself. Because of the locktime you are unable to steal the payment back right after sending it to him.

Alternatively, you could construct the payment as an anyone can pay transaction where the output is greater than the input you provide. You would give him this transaction, then he would add funds of his own and announce it and wait for it to be mined before announcing the key in the transaction spending it. This way he could not lock up your funds without locking up funds of his own.

==Further improving privacy==
Many other transaction types also use the same hash locked pattern, but privacy can be further improved:
A ZK-payment can be transformed using the [https://bitcointalk.org/index.php?topic=321228.0 CoinSwap] approach where the payer first pays into an ordinary 2-of-2 escrow+refund with the payee. They then would perform the ZK-payment transactions described above externally to the Bitcoin network, and if everything goes through without cheating the payer just signs a 2-of-2 release to pay the payee directly, without disclosing to the network that a hashlocked transaction was used. If the payer fails to release the escrow directly, the payee can just release it by announcing the hashlock and hashlock redeem.

Coinbase

2020-01-17T12:10:42Z

JonathanCross: "The Times" ≠ "FT" (Financial Times)

:''For the business, see [[Coinbase (business)]].''

The '''coinbase''' is the content of the 'input' of a generation [[transaction]]. While regular transactions use the 'inputs' section to refer to their parent transaction outputs, a generation transaction has no parent, and creates new coins from nothing.

The coinbase can contain any arbitrary data. The [[genesis block]] famously contains the dated title of a newspaper article in The Times:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

User talk:Luke-jr

2019-08-12T23:33:39Z

JonathanCross: /* Nick Szabo */ new section

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

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

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

== Headers ==

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

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

== deep web ==

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

== 247exchange ==

Hello Luke,
is it possible to list our exchange service 247exchange.com here please: https://en.bitcoin.it/wiki/Buying_Bitcoins_(the_newbie_version)?
We accept credit/debit cards (Visa, MasterCard, Maestro) for instant buying Bitcoin. SWIFT and SEPA bank transfers are also accepted. All countries except USA (where we don't have the licenses yet) are supported.
Our exchange is licensed, secure and easy-to-use.
Thanks in advance!

== Weighing in on my discussion with RyanC ==

Hi Luke, I've been discussing the pros/cons of Warpwallets with Ryan Castelluci on his [[User talk:Ryanc|talk page]]. Could you share your analysis?

It's a long discussion so to reiterate my position:

1) There is a [https://nakedsecurity.sophos.com/2013/08/12/android-random-number-flaw-implicated-in-bitcoin-thefts/ real problem] with the faithfulness of blackbox RNGs that is hard to solve. RyanC agrees with me on that point.

2) It's unwise to trust systems we can't verify when the stakes are high. For example, we can recommend users verify they're running a trustworthy wallet on a clean computer. Sounds great but if you really want to be sure that's very hard even for an expert. We can recommend they verify their wallet is actually (not just "supposed to", according to the source) using a faithful CSPRNG to generate the seed but '''nobody''' knows how to do that.

3) What I like about Warpwallet is that it provides a unique blend of [http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ simplicity with security].

It's not idiot proof, but none of the other solutions are either. For some use cases it's a genuinely better recommendation than the more traditional alternatives, and if that's true we owe it to the non-experts who look up to us not to parrot old advice. When a new technique comes along, let's think it through.

We also need to accept that different solutions have relative advantages and trade-offs. Computer security is hard. There's no way around nuance. There are no absolutes. Nothing we recommend will fully protect users from being stupid or negligent. Some users will always choose the dancing pigs.

We can recommend they don't store large amounts in hot wallets, but they'll do that anyway. We can recommend they don't backup their "encrypted" wallet to the cloud, but of course they will. We can recommend a random passphrase and they'll use something from a dictionary or a famous quote. We can recommend they pay more for a hardware wallet from a trustworthy source, they won't be able to tell who's trustworthy and they'll just opt to pay less. They're lose their paper backups to the cleaning lady, fire and flood. They will forget their encryption passwords.

We don't respond to that by treating everyone like stupid irresponsible babies. We accept personal responsibility and give those that want it the best advice we have.

4) Warpwallet is mostly guilty by association with naive SHA256 Brainwallets. Putting the SHA256 technique in anything with a web interface was like leaving a loaded gun around. Of course people got hurt and that's tragic.

I understand why the natural reaction to that is just to taboo the whole brainwallet concept after that, but using extreme key stretching together with salting is something qualitatively different.

You can't just cut and paste the SHA256 brainwallet public service announcement on to the new thing because the stupid thing came first. That would be like giving SHA256 brainwallets a pass if Warpwallet came first. The devil is in the details. We need to re-evaluate based on evidence. Warpwallet changes the cost of attack so that there's no longer a weak central point of failure users are known to be notoriously bad at.

Case in point, the Warpwallet challenge offered a $20,000 jackpot to crack an intentionally weak 8-character unsalted wallet and survived unclaimed for 2.5 years. RyanC has argued a large botnet running his software could crack the challenge in a year or so and I hope someone does that to prove him right.

But if the challenge was modified to use an unknown e-mail salt, Ryanc's Brainflayer running on a 25M node botnet would never find it. The universe would end first. If Warpwallet challenge included a list of 1000 possible e-mail salts, it would take the botnet 9 years to crack. To search 10,000 suspected e-mail salts: 90 years. That's not my opinion, that's math.

Maybe I'm missing something, but my conclusion is that if you use Warpwallet with a pretty good passphrase and your e-mail as salt, you're much more likely to get your coins stolen by someone beating you over the head with a $5 wrench than a Brainflayer botnet with millions of nodes running for decades.

Don't you agree? If not, that's fine, but please help me understand why.

== Nick Szabo ==

Hi Luke-jr.
Would be great to have more info on why the [[Nick Szabo]] article was deleted.
We have a number or articles referencing him -- it's hard to argue he doesn't deserve an article here. Was it just incomplete or low quality?

Thanks, -- [[User:JonathanCross|JonathanCross]] ([[User talk:JonathanCross|talk]]) 23:33, 12 August 2019 (UTC)

Template:MainPage Topics

2019-08-12T23:23:30Z

JonathanCross: Adding Privacy

{|cellpadding="2" style="background-color: inherit;"
|-
| scope="col" style="width: 200px;" |
* '''[[Introduction]]
* '''[[Getting started]]
* '''[[Myths]]
* '''[[Securing your wallet]]
* '''[https://en.bitcoin.it/wiki/Help:FAQ FAQ]
* [https://bitcoincharts.com/ Bitcoin Statistics]
| scope="col" style="width: 200px;" |
* [[:Category:Technical|Technical articles]]
* [[Protocol specification]]
* [[Secure Trading|Best practices for traders]]
* [[Bitcoin Improvement Proposals]]
* [[Privacy]]
|}

{|cellpadding="2" style="background-color: inherit;"
|-
! scope="col" style="width: 200px;" |
! scope="col" style="width: 200px;" |
|-
|

* [[Software]]
* [[Mining]]
* [[Trading bitcoins|Exchanges]]
* [[:Category:Directories|Local Directories]]
* [[:Category:Marketing|Marketing resources]]
* [[People]]
|
* [[:Category:Clients|Clients]] / [[:Category:Frontends|Frontends]]
* [[:Category:Economics|Economics]]
* [[Donation-accepting_organizations_and_projects|Donation-accepting sites]]
* [[Meetups]] and [[Conferences]]
|}

<div style="text-align: right;" class="noprint">[{{fullurl:Template:MainPage_Topics|action=edit}} '''Edit'''] – '''[[Special:Categories|See More]]'''</div>
<noinclude>{{p-move}}</noinclude>

Privacy

2019-08-12T23:17:32Z

JonathanCross: /* Forced address reuse */ Fixing typos.

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.

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.

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.

=== Summary ===

To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:

* 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.
* 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.
* 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.
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.
* 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.
* Use [[Lightning Network]] as much as possible.
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].
* 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).
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].

== Introduction ==

Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.

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).

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.

[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]

=== Example - Adversary controls source and destination of coins ===

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:

[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]

* Transaction of coins on address A to address B. Authorized by <signature of address A>.
* Transaction of coins on address B to address C. Authorized by <signature of address B>.

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.

=== Example - Non-anonymous Chinese newspaper buying ===

In this example the adversary controls the destination and finds the source from metadata.

# You live in China and want to buy a "real" online newspaper for Bitcoins.
# 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.
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!
# 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".
# 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.

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).

=== Example - A perfectly private donation ===

On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.

# The aim is to donate to some organization that accepts bitcoin.
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.
# Send the entire balance to a donation address of that organization.
# Finally you destroy the computer hardware used.

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.

=== Multiple interpretations of a blockchain transaction ===

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.

Consider this example transaction:

1 btc ----> 1 btc
3 btc 3 btc

This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.

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).

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:

# [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).
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.
# 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.
# 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.
# Alice pays 4 btc to Bob (but using two outputs for some reason).
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.
# 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]].
# 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]].
# Alice and Bob pay 4 btc to Carol (but using two outputs).

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.

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.

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.

=== Threat model ===

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.

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.

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.

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).

=== Method of data fusion ===

[[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.]]

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.

[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]

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).

=== Why privacy ===

Financial privacy is an essential element to fungibility in Bitcoin: if you can meaningfully distinguish one coin from another, then their fungibility is weak. If our 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 and transactional costs and makes Bitcoin less valuable as a money.

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.

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.

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.

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.

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[dot]org/index.php?topic=334316.msg3588908#msg3588908</ref>.

== Blockchain attacks on privacy ==

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.

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.

[[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.

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>.

=== [[Common-input-ownership heuristic]] ===

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.

For example, consider this transaction with inputs A, B and C; and outputs X and Y.

A (1 btc) --> X (4 btc)
B (2 btc) Y (2 btc)
C (3 btc)

This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.

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.

=== [[Change]] address detection ===

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.

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>.

Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:

==== Address reuse ====

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 its very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".

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.

Avoiding [[address reuse]] is an obvious remedy. Another idea is that that 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.

==== Wallet fingerprinting ====

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.

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

--> C1
A1 --> B2 --> C2
--> B2 --> D1
--> D2 --> E1
--> E2

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.

--> X
A1 --> X --> X
--> B2 --> X
--> D2 --> E1
--> X

There are a number of ways to get evidence used for identifying wallet software:

* 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.

* [[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.

* [[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.

* 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".

* 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.

* 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>.

* 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.

* 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.

* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.

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.

==== Round numbers ====

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.

==== [[Fee bumping]] ====

[[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.

This could be mitigated by some of the time reducing the amount of both outputs, or reducing only the payment amount (in a sender-pays-for-fee model).

==== Unnecessary input heuristic ====

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.

2 btc --> 4 btc
3 btc 1 btc

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.

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:

2 btc --> 4 btc
3 btc 6 btc
5 btc

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.

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.

==== Sending to a different script type ====

Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.

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.

This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).
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.

This has the most effect on early adopters of new wallet technology, like p2sh or segwit.
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.
This will improve over time as the new technology gains wider adoption.

==== Wallet bugs ====

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.

==== Equal-output [[CoinJoin]]====

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:

A (1btc)
X (5btc) ---> B (1btc)
Y (3btc) C (4btc)
D (2btc)

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.

==== Cluster growth ====

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.

=== Transaction graph ===

As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. This information from all the transactions and addresses is often called the transaction graph.

Transactions are usually assumed to correspond to real economic transactions, but sometimes transactions actually just represent someone sending bitcoins to themselves.

==== Taint analysis ====

''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.

=== Amount ===

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.

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>.

==== Input amounts revealing sender wealth ====

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.

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>.

==== Exact payment amounts (no change) ====

Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.

This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.

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 sending donations using manual coin selection to explicitly avoid change.

=== Batching ===

[[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.

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>

<blockquote>
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.

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.

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.
</blockquote>

=== Unusual scripts ===

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.

2-of-3 multisig is by far the most common non-single-signature script as of 2019.

=== Mystery shopper payment ===

A 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.

=== Forced address reuse ===

Forced [[address reuse]] is when an adversary pays small amounts 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>.

The correct behaviour by wallets is to not spend coins that have landed on an already-used addresses.

=== Amount correlation ===

Amounts correlation refers to searching the entire [[block chain]] for output amounts.

For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.

V --> [black box privacy tech] --> V - fee

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.

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.

V --> [privacy tech] --> w0
--> w1
--> w2

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.

=== Timing correlation ===

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.

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.

== Non-blockchain attacks on privacy ==

=== Traffic analysis ===

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.

An adversary able to snoop on your internet connection (such as your ISP, a Wifi provider or a VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. 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.

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]].

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.

=== Custodial Wallets ===

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.

Main article: [[Browser-based wallet]]

=== Wallet history retrieval from third-party ===

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.

==== Blockchain explorer websites ====

[[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.

To get information about your [[transaction]]s it is much better to use your wallet software, not some website.

==== BIP 37 ====

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.

Main article: [[BIP37 privacy problems]]

==== Public Electrum servers ====

[[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.

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.

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.

=== Communication eavesdropping ===

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.

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]].

=== Revealing data when transacting bitcoin ===

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.

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).

=== Digital forensics ===

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.

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.

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.

== Methods for improving privacy (non-blockchain) ==

=== Obtaining bitcoins anonymously ===

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.

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.

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>.

==== Cash trades ====

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.

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.

'''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.

'''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.

'''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.

'''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.

==== Cash substitute ====

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.

==== Employment ====

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.

==== Mining ====

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).

==== Stealing ====

In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref>

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.

=== Spending bitcoins anonymously ===

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.

=== Wallet history synchronization ===

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).

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.

==== Full node ====

[[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.

==== Private information retrieval ====

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.

==== Client-side block filtering ====

[[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.

==== Address query via onion routing ====

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.

=== Countermeasures to traffic analysis ===

[[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>

[[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.

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.

==== Tor and tor broadcasting ====

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]].

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[dot]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.

[[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>.

==== Dandelion ====

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>

==== Interactive peer broadcasting ====

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.

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]].

==== Receiving bitcoin data over satellite ====

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.

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.

Main article: https://blockstream.com/satellite/

== Methods for improving privacy (blockchain) ==

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.

=== Avoiding [[address reuse]] ===

[[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]].

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".

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.

[[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.

==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====

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.

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.

=== Coin control ===

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>.

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.

=== Multiple transactions ===

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.

Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.

=== Change avoidance ===

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.

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.

Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]

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.

=== Multiple change outputs ===

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.

=== Script privacy improvements ===

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.

'''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)
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]].

'''[[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.

'''[[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]].

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>.

'''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>.

'''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.

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.

'''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>.

'''[[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.

=== ECDH addresses ===

[[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.

However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[#Mystery_shopper_payment|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.

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.

=== Centralized mixers ===

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.

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.

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>.

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.

Main article: [[Mixing service]]

=== CoinJoin ===

[[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>.

==== Equal-output CoinJoin ====

Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.

2 btc --> 3 btc
3 btc 2 btc

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:

2 btc --> 2 btc
3 btc 2 btc
1 btc

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.

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).

==== PayJoin ====

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.

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:

2 btc --> 3 btc
5 btc 4 btc

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.

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>.

=== CoinSwap ===

[[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.

[[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:

Alice's Address ---> escrow address 1 ---> Bob's Address
Bob's Address ---> escrow address 2 ---> Alice's Address

Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].

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.

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.

As of 2018 no CoinSwap implementation has been deployed.

=== CoinJoinXT ===

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.

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.

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.

=== TumbleBit ===

[[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.

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.

=== Off-chain transactions ===

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.

Main article: [[Off-Chain Transactions]]

'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].

==== Blinded bearer certificates ====

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.

Main article: [[Blinded bearer certificates]]

==== Sidechains ====

[[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.

Main article: [[Sidechain]]

=== Confidential transactions ===

[[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.

Main article: [[Confidential transactions]]

=== Discussion ===

==== Privacy vs scalability ====

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).

[[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.

In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.

==== Steganography ====

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.

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.

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.

== Lightning Network ==

[[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]].

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.

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.

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.

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.

=== Onion routing ===

The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md
</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.

==== Onion routing overlaid with network topology ====

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.

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.

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]].

==== Rendez-vous routing ====

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.

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.

=== Atomic Multipath Payments ===

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.

=== Common hashlock value ===

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.

[[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>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>.

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.

=== Custodial wallets ===

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.

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>.

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.

=== Private script types ===

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.

=== Probing payments to reveal channel states ===

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.

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.

== Existing privacy solutions ==

This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.

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.

=== Lightning Network ===

There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.

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.

[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].

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.

=== Handmade CoinJoin ===

[[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.

=== JoinMarket ===

[[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).

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.

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.

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]].

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.

Main article: [[JoinMarket]]

=== Wasabi Wallet ===

[[Wasabi Wallet]] is a wallet that implements [[CoinJoin]]. It is open source and written in C#, .NET Core. The package includes Tor and all traffic between the clients and the server goes through it, so IP addresses are hidden. It is easy to install and use. The wallet includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control. The wallet uses [[Client-side block filtering]] to obtain its own transaction history in a private way.

CoinJoins happen between users without any liquidity provider middlemen. As of the beginning of 2019, coinjoins happen approximately once every hour and a half.

Users' wallets connect to a server which coordinates the [[CoinJoin]]. The wallet uses schnorr blind signatures (which is similar to the cryptography used in chaumian blind signatures and [[blinded bearer certificates]]) so that this server or anyone else does not learn the linkage between the mixed transaction inputs and outputs. The server is run by the zkSNACKs company which has developed Wasabi Wallet, the company makes its income by taking a fee (0.17% per participant as of 2019) from each coinjoin transaction.

Main article: [[Wasabi Wallet]]

=== Samourai Wallet ===

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.

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.

=== Liquid sidechain ===

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.

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 of 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.

== Examples and case studies ==

Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.

=== Bad privacy example - Exchange front running ===
# You are a trader and have an account on a bitcoin [[exchange]].
# You want to deposit some bitcoins to sell.
# You send bitcoins to the same exchange deposit address you have used in the past.
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.
# 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.
# You sell the bitcoins for a less attractive price than you otherwise would have.
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.

Lesson: [[Address reuse]] is terrible for privacy.

=== Bad privacy example - Savings revealed with [[address reuse]] ===
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].
# All your bitcoin savings to this same address, let's say it contains $1 million worth.
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.
# He mentions it to someone in a cafe or bar.
# 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>.

Lesson: [[Address reuse]] is terrible for privacy.

=== Bad privacy example - Savings revealed with data collection ===

# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.
# 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.

=== Example - Evading sanctions ===
# You live in a country that is under international trade sanctions from other countries.
# Because of this you cannot buy the online newspaper you want.
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.

=== Example - Transacting with your online poker buddies without revealing your real name ===
# You play online poker with some people (for real money).
# You win big. Lots of money goes to you and your buddies are annoyed.
# 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.
# Your irritated poker buddies can't find your real name.

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]]).

=== Example - Donation without your employer knowing ===
# You earn money in bitcoin, your employer has sent you bitcoins as salary.
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.
# 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.
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).

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.

=== Example - Donation without anyone knowing ===
# You want to support X charity or political group without anyone knowing.
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].

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.

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.

=== Example - Receiving donations privately ===
# 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.
# You want to spend the donations without anyone on the internet knowing.
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.
# Withdraw the money straight into another similar bitcoin service website.
# Take care to use different transactions in order to stop the amounts being correlated.
# Make sure to wait a little while to stop the timings being used to link together transactions
# 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.

Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.

Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc
-> 1addrD 0.7btc -> 1addrJ 0.25btc
-> 1addrK 0.25btc

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.

=== Example - Storing savings privately ===
# 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.
# 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]].
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.
# 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]].

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.

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.

=== Example - Stopping incoming payments from different sources from being linked together ===
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].
# 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.
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.
# You run the JoinMarket tumbler script which will combine both balances without linking them together.

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]].

=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===
# 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).
# Install [[JoinMarket]] and point it at your own [[full node]].
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.
# 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.
# 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>.

=== Bad privacy example - Using a blockchain explorer ===
# You receive a payment of bitcoin at one of your [[address]]es.
# 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.
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.
# 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.

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.

=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===
# 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.
# 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.
# You send the bitcoins back to your wallet in one transaction.
# 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.

Lesson: Transactions have amounts visible to all which must be treated with care for privacy.

=== Example - Privacy altcoin mixing ===
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.
# 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.

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.

=== Example - Daily commerce with Lightning Network ===
# 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.
# You download and install a [[Lightning Network]] wallet and use that for all purchases.
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.

=== Bad privacy example - Sending to a static donation address without precautions ===
# You own bitcoin and keep it in a custodial wallet.
# You want to donate to charity or political group X.
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).
# They disagree with your views and then they close your account.

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).

=== Bad privacy example - Receiving donations spied on with [[#Mystery_shopper_payment|mystery shopper payments]] ===
# You want to accept bitcoin donations but don't want to reveal the total donated amount.
# You set up a web server to give out unique addresses for each visitor.
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].
# The adversary now has a good idea of your total donation income.

Lesson: [[#Mystery_shopper_payment|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]].

=== Real life example - Bitcoin-stealing malware using static addresses ===
# You are a creator of stealware (malware that steals money from its victim).
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.

This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk[dot]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>

=== Bad privacy example - Bitcoin-stealing malware spied on with mystery shopper payments ===
# You are an infosec researcher studying bitcoin-stealing malware.
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[#Mystery shopper payment]].
# The malware author sends all their received stolen to an exchange in one [[transaction]], including your payment.
# 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.
# 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.

Lesson: [[#Mystery_shopper_payment|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].

=== Example - Single-use lightweight wallet over Tor ===
# You want to anonymously buy something or donate to something online.
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.
# You spend the entire balance of bitcoins buying or donating to the thing you want.
# After you're done you delete the wallet and never use it again.

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.

=== Bad privacy example - Lightweight wallet over Tor used multiple times ===
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.

# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.
# You install [[Electrum]] wallet and configure it to use [[Tor]].
# You pay for the novelty hat and have it sent to your mail address.
# You pay for the VPN to improve your web browsing privacy.
# 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]].
# 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!

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]].

Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)

=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# 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.

=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.
# 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.
# [[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.
# 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]].
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.

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].

=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===
# Go to a website which accepts bitcoin donations like ThePirateBay.
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.
# 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.
# Another possibility is that ThePirateBay is using [[CoinJoin]].

=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# 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.
# 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.
# 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>.
# 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>.
# 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.

=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk[dot]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.
# 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]].
# 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.
# A quote from the analyst:
<blockquote>
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''

''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.''

''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).''
</blockquote>

Lesson: The [[common-input-ownership heuristic]] isn't always right.

=== Real life example - The QuadrigaCX exchange wallet analysis ===

# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.
# 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.
# 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]].
# 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.

Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/

Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/

=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===

# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.
# 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.
# Some of Bustabit's customers were being warned and banned by Coinbase.com.
# 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.
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.
# No more Bustabit customers were ever warned or banned
# 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.

=== Real life example - Rare multisignature scripts ===
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.
# 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>.
# 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.
# 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>.
# 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>.

=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===

# 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]].
# ''"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."''

Lesson: [[Address reuse]] is terrible for privacy.

=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===

# 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>.
# They offered a 50% bounty for any help or information leading to finding their bitcoins again
# 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.
# All traces are lost from what anybody has been able to tell.

For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.

=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===

# 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.
# Bitcoin's blockchain leaks a lot of privacy-relevant information.
# 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>.
# 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.

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.

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.

=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===

# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.
# 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>

=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===

# 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.
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])
# 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.
# 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.
# 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.

Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.

=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===

# 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>.
# 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.
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.
# They also used [[#Mystery_shopper_payment|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.
# 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.
# 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.
# 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

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.

Ransomware is a threat. Always keep good backups of your important data.

==See also==

* [[Common-input-ownership heuristic]]
* [[Address reuse]]
* [[CoinJoin]]
* [[PayJoin]]
* [[Transaction surveillance company]]
* [[Client-side block filtering]]
* [[Full node#Privacy]]
* [[Lightning Network]]

==References==
<references />

[[Category:Privacy]]

Privacy

2019-08-12T23:13:56Z

JonathanCross: /* Bad privacy example - Receiving donations spied on with mystery shopper payments */ Fixing typos.

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.

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.

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.

=== Summary ===

To save you reading the rest of the article, here is a quick summary of how normal bitcoin users can improve their privacy:

* 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.
* 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.
* 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.
* Use a wallet backed by your own [[full node]] or [[client-side block filtering]], definitely not a web wallet.
* 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.
* Use [[Lightning Network]] as much as possible.
* If lightning is unavailable, use a wallet which correctly implements [[CoinJoin]].
* 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).
* If [[#Digital forensics|digital forensics]] are a concern then use a solution like [https://tails.boum.org/ Tails Operating System].

== Introduction ==

Users interact with bitcoin through [[software]] which may leak information about them in various ways that damages their anonymity.

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).

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.

[[File:Unknownaddress.png|thumb|The flow of Bitcoins is highly public.]]

=== Example - Adversary controls source and destination of coins ===

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:

[[File:knownaddress.png|thumb|Finding an identity of one address allows you to attack the anonymity of the transactions.]]

* Transaction of coins on address A to address B. Authorized by <signature of address A>.
* Transaction of coins on address B to address C. Authorized by <signature of address B>.

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.

=== Example - Non-anonymous Chinese newspaper buying ===

In this example the adversary controls the destination and finds the source from metadata.

# You live in China and want to buy a "real" online newspaper for Bitcoins.
# 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.
# Unfortunately, you choose poorly in who you buy the newspaper from: you've chosen a government agent!
# 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".
# 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.

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).

=== Example - A perfectly private donation ===

On the other hand, here is an example of somebody using bitcoin to make a donation that is completely anonymous.

# The aim is to donate to some organization that accepts bitcoin.
# You run a [[Bitcoin Core]] wallet entirely through [[Tor]].
# Download some extra few hundred gigabytes of data over [[Tor]] so that the total download bandwidth isn't exactly blockchain-sized.
# [[Pool vs. solo mining|Solo-mine]] a block, and have the newly-mined coins sent to your wallet.
# Send the entire balance to a donation address of that organization.
# Finally you destroy the computer hardware used.

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.

=== Multiple interpretations of a blockchain transaction ===

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.

Consider this example transaction:

1 btc ----> 1 btc
3 btc 3 btc

This transaction has two inputs, worth 1 btc and 3 btc, and creates two outputs also worth 1 btc and 3 btc.

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).

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:

# [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).
# Alice provides both inputs and pays 1 btc to Bob, with 3 btc paid back to Alice as the change.
# 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.
# 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.
# Alice pays 4 btc to Bob (but using two outputs for some reason).
# Fake transaction - Alice owns all inputs and outputs, and is simply moving coins between her own [[address]]es.
# 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]].
# 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]].
# Alice and Bob pay 4 btc to Carol (but using two outputs).

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.

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.

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.

=== Threat model ===

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.

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.

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.

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).

=== Method of data fusion ===

[[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.]]

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.

[[File:Privacy-data-fusion-newspaper-buying-diagram.png|200px|thumb|right|Data fusion diagram example with newspaper buyer.]]

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).

=== Why privacy ===

Financial privacy is an essential element to fungibility in Bitcoin: if you can meaningfully distinguish one coin from another, then their fungibility is weak. If our 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 and transactional costs and makes Bitcoin less valuable as a money.

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.

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.

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.

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.

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[dot]org/index.php?topic=334316.msg3588908#msg3588908</ref>.

== Blockchain attacks on privacy ==

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.

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.

[[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.

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>.

=== [[Common-input-ownership heuristic]] ===

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.

For example, consider this transaction with inputs A, B and C; and outputs X and Y.

A (1 btc) --> X (4 btc)
B (2 btc) Y (2 btc)
C (3 btc)

This [[transaction]] would be an indication that [[address]]es B and C are owned by the same person who owns [[address]] A.

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.

=== [[Change]] address detection ===

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.

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>.

Now are listed possible ways to infer which of the outputs of a transaction is the [[change]] output:

==== Address reuse ====

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 its very hard to imagine how false positives would arise (except by intentional design of wallets). This heuristic is also called the "shadow heuristic".

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.

Avoiding [[address reuse]] is an obvious remedy. Another idea is that that 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.

==== Wallet fingerprinting ====

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.

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

--> C1
A1 --> B2 --> C2
--> B2 --> D1
--> D2 --> E1
--> E2

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.

--> X
A1 --> X --> X
--> B2 --> X
--> D2 --> E1
--> X

There are a number of ways to get evidence used for identifying wallet software:

* 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.

* [[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.

* [[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.

* 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".

* 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.

* 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>.

* 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.

* 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.

* Coin Selection. Various wallet softwares may choose which UTXOs to spend using different algorithms that could be used for fingerprinting.

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.

==== Round numbers ====

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.

==== [[Fee bumping]] ====

[[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.

This could be mitigated by some of the time reducing the amount of both outputs, or reducing only the payment amount (in a sender-pays-for-fee model).

==== Unnecessary input heuristic ====

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.

2 btc --> 4 btc
3 btc 1 btc

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.

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:

2 btc --> 4 btc
3 btc 6 btc
5 btc

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.

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.

==== Sending to a different script type ====

Sending funds to a different script type than the one you're spending from makes it easier to tell which output is the change.

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.

This is also possible if the inputs are of mixed types (created by wallets supporting multiple script types for backwards compatibility).
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.

This has the most effect on early adopters of new wallet technology, like p2sh or segwit.
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.
This will improve over time as the new technology gains wider adoption.

==== Wallet bugs ====

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.

==== Equal-output [[CoinJoin]]====

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:

A (1btc)
X (5btc) ---> B (1btc)
Y (3btc) C (4btc)
D (2btc)

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.

==== Cluster growth ====

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.

=== Transaction graph ===

As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. This information from all the transactions and addresses is often called the transaction graph.

Transactions are usually assumed to correspond to real economic transactions, but sometimes transactions actually just represent someone sending bitcoins to themselves.

==== Taint analysis ====

''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.

=== Amount ===

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.

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>.

==== Input amounts revealing sender wealth ====

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.

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>.

==== Exact payment amounts (no change) ====

Payments that send exact amounts and take no change are a likely indication that the bitcoins didn't move hands.

This usually means that the user used the "send maximum amount" wallet feature to transfer funds to her new wallet, to an exchange account,
to fund a lightning channel, or other similar cases where the bitcoins remain under the same ownership.

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 sending donations using manual coin selection to explicitly avoid change.

=== Batching ===

[[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.

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>

<blockquote>
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.

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.

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.
</blockquote>

=== Unusual scripts ===

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.

2-of-3 multisig is by far the most common non-single-signature script as of 2019.

=== Mystery shopper payment ===

A 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.

=== Forced address reuse ===

Forced [[address reuse]] are when an adversary pays small amounts 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 understand as a way to intentionally do [[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>.

The correct behaviour by wallets is to not spend coins that have landed on an already-used addresses.

=== Amount correlation ===

Amounts correlation refers to searching the entire [[block chain]] for output amounts.

For example, say we're using any black box privacy technology that breaks the [[transaction]] graph.

V --> [black box privacy tech] --> V - fee

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.

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.

V --> [privacy tech] --> w0
--> w1
--> w2

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.

=== Timing correlation ===

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.

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.

== Non-blockchain attacks on privacy ==

=== Traffic analysis ===

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.

An adversary able to snoop on your internet connection (such as your ISP, a Wifi provider or a VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. 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.

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]].

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.

=== Custodial Wallets ===

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.

Main article: [[Browser-based wallet]]

=== Wallet history retrieval from third-party ===

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.

==== Blockchain explorer websites ====

[[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.

To get information about your [[transaction]]s it is much better to use your wallet software, not some website.

==== BIP 37 ====

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.

Main article: [[BIP37 privacy problems]]

==== Public Electrum servers ====

[[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.

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.

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.

=== Communication eavesdropping ===

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.

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]].

=== Revealing data when transacting bitcoin ===

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.

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).

=== Digital forensics ===

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.

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.

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.

== Methods for improving privacy (non-blockchain) ==

=== Obtaining bitcoins anonymously ===

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.

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.

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>.

==== Cash trades ====

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.

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.

'''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.

'''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.

'''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.

'''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.

==== Cash substitute ====

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.

==== Employment ====

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.

==== Mining ====

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).

==== Stealing ====

In theory another way of obtaining anonymous bitcoin is to steal them.<ref>https://twitter.com/thegrugq/status/1062194678089404421</ref>

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.

=== Spending bitcoins anonymously ===

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.

=== Wallet history synchronization ===

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).

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.

==== Full node ====

[[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.

==== Private information retrieval ====

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.

==== Client-side block filtering ====

[[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.

==== Address query via onion routing ====

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.

=== Countermeasures to traffic analysis ===

[[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>

[[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.

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.

==== Tor and tor broadcasting ====

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]].

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[dot]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.

[[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>.

==== Dandelion ====

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>

==== Interactive peer broadcasting ====

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.

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]].

==== Receiving bitcoin data over satellite ====

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.

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.

Main article: https://blockstream.com/satellite/

== Methods for improving privacy (blockchain) ==

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.

=== Avoiding [[address reuse]] ===

[[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]].

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".

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.

[[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.

==== Avoiding [[#Forced_address_reuse|forced address reuse]] ====

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.

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.

=== Coin control ===

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>.

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.

=== Multiple transactions ===

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.

Privacy-conscious merchants and services should provide customers with more than one bitcoin [[address]] that can be paid.

=== Change avoidance ===

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.

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.

Main article: [[Techniques_to_reduce_transaction_fees#Change_avoidance]]

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.

=== Multiple change outputs ===

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.

=== Script privacy improvements ===

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.

'''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)
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]].

'''[[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.

'''[[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]].

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>.

'''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>.

'''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.

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.

'''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>.

'''[[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.

=== ECDH addresses ===

[[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.

However [[ECDH address]]es do not solve all privacy problems as they are still vulnerable to [[#Mystery_shopper_payment|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.

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.

=== Centralized mixers ===

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.

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.

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>.

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.

Main article: [[Mixing service]]

=== CoinJoin ===

[[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>.

==== Equal-output CoinJoin ====

Say this transaction is a [[CoinJoin]], meaning that the 2 BTC and 3 BTC inputs were actually owned by different entities.

2 btc --> 3 btc
3 btc 2 btc

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:

2 btc --> 2 btc
3 btc 2 btc
1 btc

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.

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).

==== PayJoin ====

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.

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:

2 btc --> 3 btc
5 btc 4 btc

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.

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>.

=== CoinSwap ===

[[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.

[[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:

Alice's Address ---> escrow address 1 ---> Bob's Address
Bob's Address ---> escrow address 2 ---> Alice's Address

Obviously Alice and Bob generate new [[address]]es each to avoid the privacy loss due to [[address reuse]].

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.

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.

As of 2018 no CoinSwap implementation has been deployed.

=== CoinJoinXT ===

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.

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.

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.

=== TumbleBit ===

[[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.

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.

=== Off-chain transactions ===

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.

Main article: [[Off-Chain Transactions]]

'''[[Lightning Network]]''' is a huge topic in bitcoin privacy so it is [[#Lightning_Network|discussed in its own section]].

==== Blinded bearer certificates ====

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.

Main article: [[Blinded bearer certificates]]

==== Sidechains ====

[[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.

Main article: [[Sidechain]]

=== Confidential transactions ===

[[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.

Main article: [[Confidential transactions]]

=== Discussion ===

==== Privacy vs scalability ====

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).

[[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.

In the long term as bitcoin [[miner fees]] go up, resource-costly privacy technologies will be priced out and replaced by resource-efficient ones.

==== Steganography ====

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.

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.

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.

== Lightning Network ==

[[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]].

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.

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.

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.

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.

=== Onion routing ===

The Lightning protocol uses onion routing<ref>https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md
</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.

==== Onion routing overlaid with network topology ====

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.

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.

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]].

==== Rendez-vous routing ====

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.

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.

=== Atomic Multipath Payments ===

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.

=== Common hashlock value ===

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.

[[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>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>.

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.

=== Custodial wallets ===

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.

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>.

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.

=== Private script types ===

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.

=== Probing payments to reveal channel states ===

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.

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.

== Existing privacy solutions ==

This section is about bitcoin software which implements privacy features as its main goal, especially avoiding the privacy leaks due to the blockchain.

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.

=== Lightning Network ===

There are several implementations of [[Lightning Network]] as of early-2019; such as [[LND]], [[c-lightning]], [[eclair]], etc.

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.

[[Lightning Network]] wallets usually the standard privacy tech like [[Deterministic wallet]]s and warnings against [[address reuse]].

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.

=== Handmade CoinJoin ===

[[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.

=== JoinMarket ===

[[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).

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.

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.

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]].

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.

Main article: [[JoinMarket]]

=== Wasabi Wallet ===

[[Wasabi Wallet]] is a wallet that implements [[CoinJoin]]. It is open source and written in C#, .NET Core. The package includes Tor and all traffic between the clients and the server goes through it, so IP addresses are hidden. It is easy to install and use. The wallet includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control. The wallet uses [[Client-side block filtering]] to obtain its own transaction history in a private way.

CoinJoins happen between users without any liquidity provider middlemen. As of the beginning of 2019, coinjoins happen approximately once every hour and a half.

Users' wallets connect to a server which coordinates the [[CoinJoin]]. The wallet uses schnorr blind signatures (which is similar to the cryptography used in chaumian blind signatures and [[blinded bearer certificates]]) so that this server or anyone else does not learn the linkage between the mixed transaction inputs and outputs. The server is run by the zkSNACKs company which has developed Wasabi Wallet, the company makes its income by taking a fee (0.17% per participant as of 2019) from each coinjoin transaction.

Main article: [[Wasabi Wallet]]

=== Samourai Wallet ===

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.

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.

=== Liquid sidechain ===

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.

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 of 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.

== Examples and case studies ==

Privacy is a very multifaceted and practical topic, it is helpful to follow examples to better understand how all the concepts are related.

=== Bad privacy example - Exchange front running ===
# You are a trader and have an account on a bitcoin [[exchange]].
# You want to deposit some bitcoins to sell.
# You send bitcoins to the same exchange deposit address you have used in the past.
# Because of the [[address reuse]], its easy to see on the blockchain that some bitcoins are being sent to the exchange.
# 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.
# You sell the bitcoins for a less attractive price than you otherwise would have.
# This is easily avoided by clicking the '''Generate New Deposit Address''' button on the exchange's website and depositing there.

Lesson: [[Address reuse]] is terrible for privacy.

=== Bad privacy example - Savings revealed with [[address reuse]] ===
# You save in bitcoin, using a [[Paper Wallet|single-address paper wallet]] which results in [[address reuse]].
# All your bitcoin savings to this same address, let's say it contains $1 million worth.
# You buy a small amount of bitcoins to add to your savings, depositing in the paper wallet.
# The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.
# He mentions it to someone in a cafe or bar.
# 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>.

Lesson: [[Address reuse]] is terrible for privacy.

=== Bad privacy example - Savings revealed with data collection ===

# You save in bitcoin. Trading on an exchange which you [[#Revealing_data_when_transacting_bitcoin|reveal all your data to]].
# Mostly you buy coins but sometimes you sell. You only ever use this one exchange.
# 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.

=== Example - Evading sanctions ===
# You live in a country that is under international trade sanctions from other countries.
# Because of this you cannot buy the online newspaper you want.
# You navigate to the newspaper website with Tor so that they can't tell your origin country from your IP address.
# You buy bitcoins with cash and send them to wallet software on your computer, then use the bitcoins to buy the newspaper.
# Bitcoin transactions don't have geographical information about them, so your payment is not discovered as coming from a sanctioned country.

=== Example - Transacting with your online poker buddies without revealing your real name ===
# You play online poker with some people (for real money).
# You win big. Lots of money goes to you and your buddies are annoyed.
# 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.
# Your irritated poker buddies can't find your real name.

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]]).

=== Example - Donation without your employer knowing ===
# You earn money in bitcoin, your employer has sent you bitcoins as salary.
# You want to support X charity or political group with a donation of 0.1 BTC, but don't want your employer knowing.
# 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.
# Withdraw 0.1 BTC and put the desired donation address as the withdrawal address.
# Withdraw the remaining 0.2 BTC back into your own wallet (to a brand new address, avoiding [[address reuse]]).

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.

=== Example - Donation without anyone knowing ===
# You want to support X charity or political group without anyone knowing.
# Download and install a wallet which is backed by a [[full node]] such as [[Bitcoin Core]].
# Buy the exact amount of bitcoin for cash (get slightly more because of transaction fees and volatility), have the coins sent to your wallet.
# Send the coins to the group to donation. The [[transaction]] should be broadcasted over [[Tor]].

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.

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.

=== Example - Receiving donations privately ===
# 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.
# You want to spend the donations without anyone on the internet knowing.
# The donation address is part of a wallet backed by a [[full node]] such as [[Armory]].
# Broadcast a transaction over [[Tor]] to deposit the donation money into a bitcoin website which allows anonymous deposits and withdrawals.
# Withdraw the money straight into another similar bitcoin service website.
# Take care to use different transactions in order to stop the amounts being correlated.
# Make sure to wait a little while to stop the timings being used to link together transactions
# 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.

Take an example with 1 BTC. Each arrow -> is a new withdrawal transaction.

Wallet Casino1 Altcoin Exchange Casino2 Futures Exchange Wallet
1btc -> 1addrA 1btc -> 1addrB 0.1btc -> 1addrE 0.1btc -> 1addrG 0.4btc -> 1addrH 0.25btc
-> 1addrC 0.2btc -> 1addrF 0.9btc -> 1addrF 0.6btc -> 1addrI 0.25btc
-> 1addrD 0.7btc -> 1addrJ 0.25btc
-> 1addrK 0.25btc

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.

=== Example - Storing savings privately ===
# 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.
# 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]].
# Run JoinMarket's tumbler script which has it create many [[CoinJoin]] transactions with the aim to break the link between addresses.
# 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]].

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.

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.

=== Example - Stopping incoming payments from different sources from being linked together ===
# If you had both payments in the same wallet they may be linked together with the [[common-input-ownership heuristic]].
# 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.
# You send the nurse income into one [[JoinMarket]] mixdepth and the stripper income into another mixdepth.
# You run the JoinMarket tumbler script which will combine both balances without linking them together.

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]].

=== Example - Withdrawing casino winnings to a bitcoin exchange without either entity knowing the source or destination of funds ===
# 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).
# Install [[JoinMarket]] and point it at your own [[full node]].
# Have the casino winnings sent to your JoinMarket wallet in three different payments of 5btc + 2btc + 3btc, they should go to seperate mixdepths.
# 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.
# 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>.

=== Bad privacy example - Using a blockchain explorer ===
# You receive a payment of bitcoin at one of your [[address]]es.
# 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.
# The blockchain explorer website now knows that your IP address is very interested in that particular bitcoin address.
# 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.

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.

=== Bad privacy example - Privacy altcoin mixing failing due to amount correlation ===
# 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.
# 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.
# You send the bitcoins back to your wallet in one transaction.
# 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.

Lesson: Transactions have amounts visible to all which must be treated with care for privacy.

=== Example - Privacy altcoin mixing ===
# Similar to the previous example, you have bitcoins you want to mix. You trade into and out of a privacy altcoin to do it.
# 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.

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.

=== Example - Daily commerce with Lightning Network ===
# 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.
# You download and install a [[Lightning Network]] wallet and use that for all purchases.
# Privacy attacks like [[common-input-ownership heuristic]], [[address reuse]] and change address detection fundamentally don't work on any [[Off-Chain Transactions]] technology.

=== Bad privacy example - Sending to a static donation address without precautions ===
# You own bitcoin and keep it in a custodial wallet.
# You want to donate to charity or political group X.
# You create a [[transaction]] on the custodial wallet's website sending some money to the group's donation address.
# The custodial wallet server can see where you're sending it (especially easily if the group uses a static donation address).
# They disagree with your views and then they close your account.

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).

=== Bad privacy example - Receiving donations spied on with [[#Mystery_shopper_payment|mystery shopper payments]] ===
# You want to accept bitcoin donations but don't want to reveal the total donated amount.
# You set up a web server to give out unique addresses for each visitor.
# An adversary who wants to get an idea of your total donation income donates a small amount of bitcoin to you.
# You combine all donations to use as inputs one transaction, thereby linking them together with the [[common-input-ownership heuristic]].
# The adversary now has a good idea of your total donation income.

Lesson: [[#Mystery_shopper_payment|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]].

=== Real life example - Bitcoin-stealing malware using static addresses ===
# You are a creator of stealware (malware that steals money from its victim).
# You hardcode some bitcoin address into your malware where the ill-gottens are sent to.
# Any malware researcher can now see how many bitcoins you have stolen simply by putting the addresses into a blockchain explorer.

This has been done in many cases including: the Wannacry malware<ref>https://twitter.com/msuiche/status/863082346014224385</ref><ref>https://bitcointalk[dot]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>

=== Bad privacy example - Bitcoin-stealing malware spied on with mystery shopper payments ===
# You are an infosec researcher studying bitcoin-stealing malware.
# The malware author has coded a [[ECDH address|ECDH address scheme]] into their malware.
# Your analysis of the malware only reveals the ECDH public key rather than bitcoin [[address]]es, so the malware author thinks he is private.
# You send a small amount of bitcoin to an [[address]] derived from the ECDH public key as a [[#Mystery shopper payment]].
# The malware author sends all their received stolen to an exchange in one [[transaction]], including your payment.
# 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.
# 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.

Lesson: [[#Mystery_shopper_payment|mystery shopper payments]] along with the [[common-input-ownership heuristic]] can be used to deanonymize even people who avoid [[address reuse]].

=== Example - Single-use lightweight wallet over Tor ===
# You want to anonymously buy something or donate to something online.
# You install [[Electrum]] wallet and configure it to use [[Tor]], or use [https://tails.boum.org Tails OS].
# You buy bitcoins anonymously with cash and have them sent to your Electrum wallet.
# You spend the entire balance of bitcoins buying or donating to the thing you want.
# After you're done you delete the wallet and never use it again.

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.

=== Bad privacy example - Lightweight wallet over Tor used multiple times ===
Very similar to the previous example, but more than one [[address]] and [[transaction]] is used.

# You want to use bitcoin for more than one use-case, for example buying a novelty hat and paying for a VPN.
# You install [[Electrum]] wallet and configure it to use [[Tor]].
# You pay for the novelty hat and have it sent to your mail address.
# You pay for the VPN to improve your web browsing privacy.
# 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]].
# 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!

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]].

Lesson 2: Note that [https://tails.boum.org TailsOS] as of 2018 uses this privacy model for Electrum(!)

=== Real life example - Public donation address combined with the [[common-input-ownership heuristic]] ===
# Go to a website which accepts bitcoin donations like the [https://tails.boum.org/donate/ Tails OS donation page].
# Take their donation address (in this case <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>) and search it in the www.walletexplorer.com site.
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# 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.

=== Real life example - [[#Digital forensics|Digital forensics]] aids with investigation of the MtGox exchange ===
# [[Mt. Gox]] is a now-defunct bitcoin exchange which shut down in 2013 due to insolvency.
# 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.
# [[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.
# 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]].
# The analysis revealed that there were multiple thefts from mtgox and the exchange was insolvent for most of its existence.

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].

=== Real life example - Flawed use of the [[common-input-ownership heuristic]] exaggerates donation income ===
# Go to a website which accepts bitcoin donations like ThePirateBay.
# Take their donation address (in this case <code>1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM</code>) and search it in the www.walletexplorer.com site.
# The site uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# We can see most of the amount and volume of donations to ThePirateBay: https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM
# The results indicate that ThePirateBay is making hundreds of millions of dollars in donations per day, which is not believable.
# 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.
# Another possibility is that ThePirateBay is using [[CoinJoin]].

=== Real life example - Incorrect clusters found by the [[common-input-ownership heuristic]] ===
# The www.walletexplorer.com website uses the [[common-input-ownership heuristic]], [[address reuse]] and possibly other techniques to cluster together addresses.
# 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.
# 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.
# 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>.
# 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>.
# 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.

=== Real life example - Handmade coinjoin mislead a bitcoin analyist ===
# The inventor of [[CoinJoin]] Greg Maxwell posted a thread on [https://bitcointalk[dot]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.
# 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]].
# 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.
# A quote from the analyst:
<blockquote>
''Originally looks like they were owned by someone with the vanity address of GMaxweLL: 14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb''

''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.''

''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).''
</blockquote>

Lesson: The [[common-input-ownership heuristic]] isn't always right.

=== Real life example - The QuadrigaCX exchange wallet analysis ===

# In early 2019 the exchange QuadrigaCX shut down and many of its customers were left unable to access their bitcoin deposits, likely forever.
# A customer wanted to analyze the blockchain to find information about QuadrigaCX's wallet.
# They asked on internet forums for other customers to reveal their deposit [[address]]es and [[transaction]]s, many customers did so.
# 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.
# 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]].
# 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.

Main article: https://blog.zerononcense.com/2019/02/04/quadrigacx-chain-analysis-report-pt-1-bitcoin-wallets/

Reddit comments: https://www.reddit.com/r/Bitcoin/comments/amut05/investigation_proves_an_exchange_quadriga_ran_a/

=== Real life example - Stopping Bustabit casino customers getting banned from Coinbase.com ===

# Coinbase.com is a bitcoin [[exchange]]. Bustabit is an online casino that uses bitcoin.
# 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.
# Some of Bustabit's customers were being warned and banned by Coinbase.com.
# 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.
# Bustabit also imported many thousands of [[Address reuse|re-used addresses]] into [[JoinMarket]] and made them be used as inputs in many [[CoinJoin]] transactions.
# No more Bustabit customers were ever warned or banned
# 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.

=== Real life example - Rare multisignature scripts ===
# As of January 2019 [[multisignature]] contracts are visible to any observer of the blockchain.
# 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>.
# 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.
# 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>.
# 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>.

=== Real life example - Freelance IT contractor has his co-workers figure out his salary ===

# 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]].
# ''"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."''

Lesson: [[Address reuse]] is terrible for privacy.

=== Real life example - Hacker hides destination of 445 btc with [[CoinJoin]] ===

# 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>.
# They offered a 50% bounty for any help or information leading to finding their bitcoins again
# 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.
# All traces are lost from what anybody has been able to tell.

For good advice on how to store bitcoins without having them stolen by hackers see the [[Storing bitcoins]] article on this wiki.

=== Bad privacy example - Data fusion of blockchain data and web cookies when online shopping with Bitcoin ===

# 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.
# Bitcoin's blockchain leaks a lot of privacy-relevant information.
# 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>.
# 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.

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.

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.

=== Bad privacy example - Centralized mixers being easily unmixed with amount correlation ===

# BitcoinFog is a centralized bitcoin mixer, it charges 1-3% for a mix.
# 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>

=== Bad privacy example - Data fusion of blockchain data and IP address transaction broadcasting data ===

# 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.
# The researchers use [[address reuse]] and the [[common-input-ownership heuristic]] (the paper authors do not mention the possibility of [[CoinJoin]])
# 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.
# 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.
# 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.

Lesson: Private transaction broadcasting (for example over [[tor]]) is necessary for privacy.

=== Real life example - 2018 paper on analysis of bitcoin ransomware transactions ===

# 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>.
# 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.
# To find ransomware [[address]]es the researchers found online reports by victims and reverse-engineered ransomware binaries to find addresses within.
# They also used [[#Mystery_shopper_payment|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.
# 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.
# 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.
# 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

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.

Ransomware is a threat. Always keep good backups of your important data.

==See also==

* [[Common-input-ownership heuristic]]
* [[Address reuse]]
* [[CoinJoin]]
* [[PayJoin]]
* [[Transaction surveillance company]]
* [[Client-side block filtering]]
* [[Full node#Privacy]]
* [[Lightning Network]]

==References==
<references />

[[Category:Privacy]]

Bitcoin XT

2019-03-03T22:10:43Z

JonathanCross: /* Controversy */ Adding ref for Max Keiser quote and removing episode number (was incorrect)

{{infobox software|logo=[[File:xt.png|256px]]|image=[[File:bitcoinxt.png|256px]]|caption=The identifying marks of an XT client
|bg=orange
|author=[[Gavin Andresen]] [[Mike Hearn]]
|website=[https://bitcoinxt.software bitcoinxt.software]
}}'''Bitcoin XT''' was a fork of [[Bitcoin Core]] created by [[Mike Hearn]] in 2014. Originally designed to introduce alternative P2P rules, it later gained significant notoriety and support after its adoption of [[BIP 0101|BIP 101]] without community support in 2015, giving it importance in the [[block size limit controversy]].<ref name="ooc">{{cite web|work=[[The Neighbourhood Pool Watch]]|author=[[organofcorti]]|title=BIP101 implementation flaws|date=27 August 2015|accessdate=27 August 2015|url=http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html}}</ref> After Andresen's resignation from the position of [[Bitcoin Core]] maintainer, he and [[Mike Hearn]] organized Bitcoin XT to address several controversial ideas lacking the consensus required to be implemented in Bitcoin Core.<ref>{{cite web|work=Medium|title=An XT FAQ|author=[[Mike Hearn|Hearn, Mike]]|date=27 August 2015|accessdate=27 August 2015|url=https://medium.com/@octskyward/an-xt-faq-38e78aa32ff0}}</ref>

BIP 101 was implemented in Bitcoin XT on August 6, 2015<ref>[https://github.com/bitcoinxt/bitcoinxt/commit/946e3ba8c7806a66c2b834d3817ff0c986c0811b]</ref> and released on August 15.<ref>{{cite web|url=https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1|title=Why is Bitcoin forking? — Faith and future|author=Mike Hearn|work=Medium}}</ref> If 75% of the last 1000 blocks were observed to have particular version bits set, it would have ceased enforcing the 1 MB block size limit and also have added a few new rules. However, this threshold was never achieved and no new XT blocks are being created today.{{citation needed}}

In January 2016, BIP 101 was removed from Bitcoin XT and replaced with the one-time block size increase to 2 MB present in [[Bitcoin Classic]].<ref>https://github.com/bitcoinxt/bitcoinxt/pull/117</ref> In the year following this change, adoption of Bitcoin XT decreased dramatically, with fewer than 30 nodes remaining by January 2017.<ref name="cdns">{{cite web |url=https://coin.dance/nodes/xt |title=Bitcoin XT Nodes Summary |work=coin.dance |accessdate=7 January 2017 }}</ref> Later attempts by other codebases to increase the block size to 2 MB including Bitcoin Classic and [[SegWit2x]] have also failed.<ref name="cd">{{cite web|url=https://www.coindesk.com/no-fork-no-fire-segwit2x-nodes-stall-running-abandoned-bitcoin-code/|title=No Fork, No Fire: Segwit2x Nodes Stall Running Abandoned Bitcoin Code|work=[[CoinDesk]]|author=Higgins, Stan|date=November 17, 2017|accessdate=November 29, 2017}}</ref>

==Miners==
Miners that side with Bitcoin XT will produce blocks with a new version number.<ref name="avc">{{cite web|title=The Bitcoin XT Fork|work=AVC|author=Wilson, Fred|date=17 August 2015|accessdate=28 August 2015|url=http://avc.com/2015/08/the-bitcoin-xt-fork/}}</ref> This indicates to the rest of the network that they support XT.<ref name="avc"/> When 75% of the last 1000 blocks are new-version blocks, these miners will automatically abandon Bitcoin and begin mining on a new Bitcoin XT blockchain.<ref name="avc"/> This will begin after a waiting period of two weeks in hopes the economy in this time may force anyone who hasn't switched yet to do so.<ref name="avc"/>

Users and miners running full Bitcoin nodes will reject the XT blockchain starting with the first block that is larger than one megabyte in size, and thus be unaffected provided it fails to achieve economic consensus.

==Users and merchants==
If insufficient mining hash power runs XT to reach supermajority then nothing will happen. If enough does, XT users will follow a new blockchain and cease to be using and trading bitcoins.

==Controversy==

Later in January 2016, frustrated of his proposal being massively outvoted, Mike Hearn made a media stunt declaring on various US national and international press agencies that "Bitcoin has failed". Max Keiser quoted Bram Cohen <ref>Whiny Ragequitting https://medium.com/@bramcohen/whiny-ragequitting-cab164b1e88</ref> in describing Hearn's move as "whiny rage quitting" <ref>Mike Hearn's move from Bitcoin to Banks - Stacy Herbert, Max Keiser & Simon Dixon discuss https://www.youtube.com/watch?v=ubqjei3Jd-U</ref> and other members of the community pointed to an extensive account of manipulations http://gettopical.com/bitcoin/e289a9a5189008d994e80666e9038089 (unfortunately today many twitter screenshots are broken).

==See Also==
* [[BIP 0101]]
* [[Scalability FAQ]]

==References==
<references/>

[[Category:Block size limit controversy]]
[[Category:Direct code forks of Bitcoin Core]]
[[Category:Failed hardforks]]
[[Category:Contentious hardforks]]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:Open Source]]

Block size limit controversy

2019-03-03T21:36:40Z

JonathanCross: Linking hardfork

{{see also|Scalability FAQ}}
Originally, Bitcoin's block size was limited by the number of database locks required to process it (at most 10000).
This limit was effectively around 500-750k in serialized bytes, and was forgotten until 2013 March.
In 2010, an explicit block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it hidden in two commits<ref>https://www.reddit.com/r/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a30b56eb "fix openssl linkage problems"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 1.</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a790fa46f40 "don't count or spend payments until they have 1 confirmation"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 2.</ref> in secret. This limit was effectively a no-op due to the aforementioned forgotten limit.

In 2013 March, the original lock limit was discovered by accident (Bitcoin Core v0.8.0 failed to enforce it, leading to upgraded nodes splitting off the network).
After resolving the crisis, it was determined that since nobody knew of the limit, it was safe to assume there was consensus to remove it, and a [[hardfork]] removing the limit was scheduled and cleanly activated in 2013 May. From this point forward, the 1 MB limit became the effective limiting factor of the block size for the first time.

The limit was not changed again before 2017 and was believed to require a very invasive hard fork to change. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.

== Arguments in favor of increasing the blocksize ==
* More transactions per second
* Off-chain solutions are not yet ready to take off the load from the main blockchain.

== Contentions ==
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.
** Neutral: Bitcoin competitors will have lower fees
** Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin
* Small blocks eventually will require higher fees for fast confirmations.
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
** Negative: Bitcoin may look unattractive to new users with high fees
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}
** Negative: Bitcoin users pay higher fees
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref>
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref>
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* "Congestion" concerns can be solved with mempool improvements including transaction eviction.
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentralization ===
* Larger blocks make full nodes more expensive to operate.
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who have hash-power are able to control their own hash power if and only if they run a full node.
* Less individuals who control hash-power will run full nodes if running one becomes more expensive<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.

==History==
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork. Satoshi and theymos immediately said not to implement it, as it would make the user's node incompatible with the network.<ref name="dontuse">[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 "+1 theymos. Don't use this patch"] Satoshi explains here that ''if'' a change is necessary, a hard fork ''could'' be implemented with a countdown.</ref> This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.<ref name="dontuse" />
===BIP 100===
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.
===Bitcoin XT===
[[File:xt.png|thumb|128px|Bitcoin XT logo]]{{main|Bitcoin XT}}
Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.

XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.
===BIP 102===
Increase to 2 MB on November 11, 2015.
===BIP 103===
Increase by 17.7% annually until 2063.
===Bitcoin Classic===
{{main|Bitcoin Classic}}
Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.
===Segregated Witness===
[[File:segwit.png|thumb|128px|SegWit logo]]{{main|Segregated Witness}}
The final solution deployed was Segwit, increasing the block size limit to 2-4 MB without a hardfork.

== Entities positions ==
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Magnr]]
| {{Yes|Yes: "We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref>
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref>
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref>
|
|-
| Bitrated
| {{No}} "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref>
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref>
|
|-
| [[MPEx]]
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref>
|
|-
| Ethereum 
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)<ref>http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6</ref>
|
|-
| [[F2Pool]]
| {{Neutral|Neutral: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref>
|
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref>
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref>
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref>
|
|-
| [[BitPay]]
| {{Yes}} "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref>
| {{Yes|Yes: "In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core."}} - Stephen Pair<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref>
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref> "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
| {{Yes}} "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref> "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref>
|
|-
| [[Blocktrail]]
|{{Yes}} "We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref> 
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref>
|
|-
| [[BTC Guild]]

| {{Yes}} "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref>
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref>
|
|-
| [[Coinbase (business)|CoinBase]]
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref> "Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref>
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref>
|-
| [[Coinify]]
| {{Yes}} "We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref>
|
|-
| [[Adam Back]]
| {{Yes|Yes: "For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It's not a free choice it is a security/scalability tradeoff. No one will thank us if we "scale" bitcoin but break it in hard to recover ways at the same time."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
| {{No}} "I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor" - Dr. Adam Back<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref>
|
|-
| [[OKCoin]]
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref>
|
|-
| [[Third Key Solutions]]
| {{Yes}} "Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref>
|
|-
| [[Xapo]]
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref>
|
|}

==References==
<references/>
[[Category:2015 events]]

Bitcoin Core

2019-03-03T21:32:39Z

JonathanCross: /* Naming Controversy */ Linking UASF

'''Bitcoin Core''' (formerly '''Bitcoin-Qt''') is the third [[Bitcoin]] [[Clients|client]], developed by [[Wladimir van der Laan]] based on the original reference code by [[Satoshi Nakamoto]].<ref>https://gavintech.blogspot.co.uk/2012/03/full-disclosure-bitcoin-qt-on-windows.html, Full disclosure: Bitcoin-Qt on Windows vulnerability, 21st October 2012</ref><ref>https://nvd.nist.gov/vuln/detail/CVE-2012-4682, Vulnerability Summary for CVE-2012-4682, 21st October 2012</ref> It has been bundled with [[bitcoind]] since version 0.5. Bitcoin-Qt has been rebranded to '''[[Bitcoin Core]]''' since version 0.9.0 <ref name="Rebranding to Bitcoin Core">{{cite web|title=Bitcoin Core version 0.9.0 released|url=https://bitcoin.org/en/release/v0.9.0|publisher=Bitcoin.org|accessdate=19 March 2014}}</ref>.

Bitcoin Core can be used as a desktop client for regular payments or as a server utility for merchants and other payment services.

===Current version===
Source code (and build instructions for supported platforms) can be found on the [https://github.com/bitcoin/bitcoin Bitcoin GitHub page].

==Features==
* Most popular software implementation of a bitcoin [[full node]]. Provides trustless validation that all of bitcoin's consensus rules are being followed.
* Has an RPC interface allowing developers to interface with Core and access the bitcoin currency trustlessly.
* Has a GUI frontend, Bitcoin-Qt, allowing ordinary users to use bitcoin with full validation.
* Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
* All functionality of the original wxWidgets client
* Asks for confirmation before sending coins
* CSV export of transactions
* Clearer transaction list with status icons and real-time filtering
* Progress bar on initial block download
* Languages: Dutch, English, German, Chinese and many more. Translations are being done by volunteers on [https://www.transifex.com/projects/p/bitcoin/ Transifex].
* Sendmany support in UI (send to multiple recipients in one transaction)
* Multiple [[Units|unit]] support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
* Splash screen that details progress
* Debug window
* Payment requests (BIP 70)
* Coin control

== Naming Controversy ==

Some people like Peter Todd, Luke-jr and Greg Maxwell warned against the renaming to Bitcoin Core because it implied a centralization.<ref>https://www.reddit.com/r/Bitcoin/comments/60jmq2/a_proposal_for_and_demo_of_a_new_bitcoin_address/df73k2h/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/60owl3/did_you_know_that_bitcoin_core_opposed_its_own/</ref><ref>https://bitcoinfoundation.org/forum/index.php?/topic/95-new-name-for-bitcoin-qt-bitcoind/&</ref>.

Bitcoin Core right now may be the most popular or "reference" [[full node]] implementation, but that status depends on the [[economic majority]] continuing to use it<ref>https://bitcoinmagazine.com/articles/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427/</ref>. Should one day come where another implementation overtakes it economically, that implementation would become the reference implementation. In one situation in 2017 significant parts of the economy moved to the BIP148 [[UASF]] implementation<ref>https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/</ref> and then moved back to Core after BIP148 was successful. The point here is that Bitcoin Core does not control bitcoin and the naming "Core" is misleading in that respect.

On the other hand, many people are happy with the name Bitcoin Core and continue to use it. As long as it's emphasized that Bitcoin Core is just one possible software implementation of bitcoin that people are free to use or not use.

==See also==

* [[bitcoind]]
* [[Full node]]
* [[Bitcoin Knots]]
* [[QBitcoin]]

==External Links==

* [https://bitcoin.org/en/download Download link at bitcoin.org]
* [https://bitcoin.org/en/version-history Version history]
* [https://bitcoincore.org/ Bitcoin Core website]
* [https://bitcointalk.org/index.php?topic=15276.0 Forum thread] (includes screenshots)
* [https://github.com/bitcoin/bitcoin Current GitHub repository shared with bitcoind]

== References ==

<references/>

[[es:Bitcoin-Qt]]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:Open Source]]

{{Bitcoin Core documentation}}

UASF

2019-03-03T21:29:33Z

JonathanCross: REDIRECT to Softfork

#REDIRECT [[Softfork]]

Mastering Bitcoin

2019-02-25T21:40:58Z

JonathanCross: Adding more information about the 2nd edition, stats, collaboration, etc.

'''''Mastering Bitcoin''''' by [[Wikipedia:Andreas Antonopoulos|Andreas M. Antonopoulos]] is [https://github.com/bitcoinbook/bitcoinbook/blob/develop/book.asciidoc a freely-available book] on Bitcoin published in 2015 by O'Reilly Media.

Mastering Bitcoin is a digital currency best seller<ref>https://www.amazon.com/Best-Sellers-Books-Digital-Currencies/zgbs/books/10806607011</ref> and has been translated by volunteers into more than 10 languages[https://bitcoinbook.info/translations-of-mastering-bitcoin/]. The second edition added 30% more content covering topics such as [[SegWit]], [[SIGHASH]] types and the [[Lightning Network]] (Chapters 6 and 7). The book has been completely written on GitHub from day one with contributions from 114 individuals <ref>https://github.com/bitcoinbook/bitcoinbook/graphs/contributors</ref> mirroring the open, collaborative model of Bitcoin development itself.

[[Category:Educational]]
{{italic}}
==See Also==
[https://bitcoin.org/en/developer-documentation Bitcoin.org Developer Documentation]
*''Mastering Bitcoin'' from O'Reilly (DRM-free book; May 2015 edition):
**[https://isidore.co/calibre/get/epub/5328 EPUB format]
**[https://isidore.co/calibre/get/pdf/5328 PDF format]
*[https://isidore.co/calibre#panel=book_details&book_id=6316 ''Mastering Bitcoin: Programming the Open Blockchain'' from O'Reilly] ([https://isidore.co/calibre/get/epub/6316 DRM-free EPUB]; June 2017, 2nd edition)
*[https://github.com/aantonop/bitcoinbook GitHub page]
*[https://www.bitcoinbook.info/ Author's book page]

==References==

<references/>

SIGHASH

2019-02-25T21:26:13Z

JonathanCross: Redirect SIGHASH to Contract#SIGHASH_flags

#redirect [[Contract#SIGHASH_flags]]

Contract

2019-02-25T21:21:44Z

JonathanCross: /* Theory */ Adding "SIGHASH flags" header.

A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.

By building low trust protocols that interact with Bitcoin, entirely new products can be created:

* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.

This page also lists some smaller examples.

Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper,
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.

==A warning about the mempool transaction replacement mechanism==

In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7#diff-118fcbaaba162ba17933c7893247df3aR522 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.

==Theory==

Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.

Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.

Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.

==== SIGHASH flags ====

Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:

# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".

The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.

Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

There are two general patterns for safely creating contracts:

# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.

This is to ensure that people always know what they are agreeing to.

Together, these features let us build interesting new financial tools on top of the block chain.

==Example 1: Providing a deposit==

Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day.

The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.

We can solve this problem with a contract:

# The user and website send each other a newly-generated public key.
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
# User sends the hash of Tx1 to the website.
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
# The user broadcasts Tx1, then broadcasts Tx2.

At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.

What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.

What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.

Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.

==Example 2: Escrow and dispute mediation==

A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.

In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:

# Agree with the merchant on a dispute mediator (e.g., ClearCoin).
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.
# Create a transaction (Tx1) with an output script as follows and broadcast it:

2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY

Now the coins are locked in such a way that they can only be spent by the following methods:

# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)

When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.

==Example 3: Assurance contracts==

An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors.

One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.

Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.

We can model this in Bitcoin as follows:

# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.
# The finished transaction is broadcast, sending the pledged coins to the announced address.

This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.

By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.

The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.

It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.

An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.

An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.

==Example 4: Using external state==

Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.

Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.

To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.

The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.

Here is an example. The man creates a transaction spending his output, and sets the output to:

<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG

This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:

if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);

This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.

Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.

It is used in the following algorithm:

# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.

If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.

Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:

today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5
Require exchange rate to be between two values on a given date

google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0
A bet on me doing something that I will never actually do

// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.
if (eurovision_winner() == 'Azerbaijan')
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
else
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.

The [http://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.

===Trust minimization: challenges===

There are various ways to reduce the level of required trust in the oracle.

Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question.

===Trust minimization: multiple independent oracles===

The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion. An implementation of such a system, and explanation was published in the '''[http://github.com/orisi/wiki/wiki/Orisi-White-Paper Orisi whitepaper]'''.

The idea, in short, is that independent oracles could be run by a set of trustworthy independent actors. Contract participants would first settle upon a set of oracles they both are comfortable using - for example by trusting [http://oracles.lo/ a dedicated site] - and then sign a contract requiring most of the oracles signatures to resolve.

One of the interesting properties of such a system is that it can possibly implement very complicated sets of scripts and external inputs, while being based on a set of standard bitcoin scripts. Another property is that the oracles can possibly replace each ones by forwarding the funds to new [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ multisig addresses] when they discover that one of the oracles is faulty/corrupted. Finally, such oracles could be used to implement sidechains without dedicated blockchain opcodes.

===Trust minimization: trusted hardware===

Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the [[trusted platform module | TPM]] chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).

===Trust minimization: Amazon AWS oracles===

Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.

==Example 5: Trading across chains==

The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust.

For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.

To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:

# Party 'A' generates some random data, x (the secret).
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').

This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.

The chain-trade script could look like this:

IF
2 <key A> <key B> 2 CHECKMULTISIGVERIFY
ELSE
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY
ENDIF

The contract input script looks like either:

<sig A> <sig B> 1

or

<secret x> <sig B> 0

i.e., the first data element selects which phase is being used.

See [[Atomic cross-chain trading]] for details.

Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.

Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.

==Example 6: Pay-for-proof contracts: buying a solution to any pure function==

In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.

For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.

Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]

==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==

Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.

For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

One solution would be [[payment channel]]s like in the [[Lightning Network]].

Another alternative is the following protocol. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.

We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.

# Create a public key (K1). Request a public key from the server (K2).
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's private key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"
# The server signs T2 using its private key associated with K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).
# The client verifies the servers signature is correct and aborts if not.
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its own. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.

This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.

This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].

The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.

The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.

==Example 8: Multi-party decentralised lotteries==

Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.

==See Also==

* [[Script]]
* [[Binary options]]
* [[Oracle]]
* [[Fidelity bonds]]

[[Category:Technical]]

Mastering Bitcoin

2019-02-25T21:18:27Z

JonathanCross: "O'Reilly publishers" => "O'Reilly Media"

'''''Mastering Bitcoin''''' by [[Wikipedia:Andreas Antonopoulos|Andreas M. Antonopoulos]] is [https://github.com/bitcoinbook/bitcoinbook/blob/develop/book.asciidoc a freely-available book] on Bitcoin published in 2015 by O'Reilly Media.

Mastering Bitcoin is a digital currency best seller<ref>https://www.amazon.com/Best-Sellers-Books-Digital-Currencies/zgbs/books/10806607011</ref> and has been translated by volunteers into more than 10 languages[https://bitcoinbook.info/translations-of-mastering-bitcoin/].

[[Category:Educational]]
{{italic}}
==See Also==
[https://bitcoin.org/en/developer-documentation Bitcoin.org Developer Documentation]
*''Mastering Bitcoin'' from O'Reilly (DRM-free book; May 2015 edition):
**[https://isidore.co/calibre/get/epub/5328 EPUB format]
**[https://isidore.co/calibre/get/pdf/5328 PDF format]
*[https://isidore.co/calibre#panel=book_details&book_id=6316 ''Mastering Bitcoin: Programming the Open Blockchain'' from O'Reilly] ([https://isidore.co/calibre/get/epub/6316 DRM-free EPUB]; June 2017, 2nd edition)
*[https://github.com/aantonop/bitcoinbook GitHub page]
*[https://www.bitcoinbook.info/ Author's book page]

==References==

<references/>

Mastering Bitcoin

2019-02-25T20:50:21Z

JonathanCross: Replace "a freely-available book" link with link to latest on GitHub and improve wording of "languages" portion

'''''Mastering Bitcoin''''' by [[Wikipedia:Andreas Antonopoulos|Andreas M. Antonopoulos]] is [https://github.com/bitcoinbook/bitcoinbook/blob/develop/book.asciidoc a freely-available book] on Bitcoin published in 2015 by O'Reilly publishers.

Mastering Bitcoin is a digital currency best seller<ref>https://www.amazon.com/Best-Sellers-Books-Digital-Currencies/zgbs/books/10806607011</ref> and has been translated by volunteers into more than 10 languages[https://bitcoinbook.info/translations-of-mastering-bitcoin/].

[[Category:Educational]]
{{italic}}
==See Also==
[https://bitcoin.org/en/developer-documentation Bitcoin.org Developer Documentation]
*''Mastering Bitcoin'' from O'Reilly (DRM-free book; May 2015 edition):
**[https://isidore.co/calibre/get/epub/5328 EPUB format]
**[https://isidore.co/calibre/get/pdf/5328 PDF format]
*[https://isidore.co/calibre#panel=book_details&book_id=6316 ''Mastering Bitcoin: Programming the Open Blockchain'' from O'Reilly] ([https://isidore.co/calibre/get/epub/6316 DRM-free EPUB]; June 2017, 2nd edition)
*[https://github.com/aantonop/bitcoinbook GitHub page]
*[https://www.bitcoinbook.info/ Author's book page]

==References==

<references/>

Wei Dai

2018-07-02T19:14:00Z

JonathanCross: Updating links to use `https` where possible.

{{Infobox person
|name = Wei Dai
|image =
|image_size =
|caption =
|birth_date =
|birth_place =
|death_date =
|death_place =
|field = [[cryptography]], [[computer science]], [[digital currencies]], [[crypto-anarchy]]
|citizenship =
|nationality =
|ethnicity =
|doctoral_advisor =
|academic_advisors =
|doctoral_students =
|notable_students =
|known_for = [[#b-money|b-money]], [[Crypto++]], [[VMAC]]
|alma_mater = Bachelor of Science degree from the [[University of Washington]] in computer science, with a minor in mathematics.
|influences = [[Timothy C. May]], [[Cypherpunks]]
|influenced = [[Satoshi Nakamoto]]
|awards =
|religion =
|signature = 
|footnotes =
|website = {{URL|http://www.weidai.com/}}
}}

'''Wei Dai''' (戴维 in Pinyin).<ref>{{cite web|title=Wei Dai Ask any LessWronger anything|url=https://www.lesswrong.com/posts/YdfpDyRpNyypivgdu/aalwa-ask-any-lesswronger-anything#TLvSTxuypiHBuoCLM|author=Wei Dai|date=January 12, 2014}}</ref> is a computer engineer<ref name=nytimes-satoshi>{{cite news|last1=Popper|first1=Nathaniel|title=Decoding the Enigma of Satoshi Nakamoto and the Birth of Bitcoin|url=https://www.nytimes.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and-the-birth-of-bitcoin.html|accessdate=31 August 2015|work=New York Times|date=May 15, 2015}}</ref> and cypherpunk<ref>{{cite news|author=Andrew Smith|work=The Sunday Times|date=March 2, 2014|url=http://failover-www.thesundaytimes.co.uk/Magazine/article1379779.html|title=Desperately seeking Satoshi}}</ref> best known as creator of [[#b-money|b-money]] and the developer of the Crypto++ library. Dai is listed as inventor on U.S. patents 5724279 and 6081598 which were assigned to Microsoft.

== Education and career ==
Mr. Dai graduated from the University of Washington with a degree in computer science<ref name="ieee-spectrum-2012">{{cite web|title=Bitcoin: The Cryptoanarchists’ Answer to Cash|url=https://spectrum.ieee.org/computing/software/bitcoin-the-cryptoanarchists-answer-to-cash|author=Morgen E. Peck|date=May 30, 2012|work=IEEE Spectrum}}</ref> and is described as an "intensely private computer engineer".<ref name=nytimes-satoshi></ref> His profile as a member of the advisory board<ref>{{cite web|title=B-Money|url=http://www.zoominfo.com/CachedPage/?archive_id=0&page_id=305671154&page_url=//www.registerhere.net/news/archive00/041900.html&page_last_updated=2002-07-16T11:05:01&firstName=Wei&lastName=Dai|author=Kerry Alexander|date=April 19, 2000}}</ref> for the (now defunct) VoteHere.net indicated:
<blockquote>
"Mr. Dai worked in the Cryptography Research Group at Microsoft Corporation in Redmond, Washington. While at Microsoft, he was involved in the study, design and implementation of cryptosystems for specialized applications. Prior to joining Microsoft, Mr. Dai was a programmer with TerraSciences of Acton, Massachusetts. Mr. Dai holds a Bachelor of Science degree from the University of Washington in computer science, with a minor in mathematics."
</blockquote>

== Cryptography ==
Dai has made numerous contributions to the field of cryptography and has identified critical Cipher Block Chaining (CBC) vulnerabilities affecting SSH2<ref>{{cite web|last1=ZiJie|first1=Xu|title=Some Fixes To SSH|url=https://eprint.iacr.org/2013/151.pdf|website=International Association for Cryptologic Research|accessdate=16 September 2015}}</ref> and the browser exploit against SSL/TLS known as BEAST (Browser Exploit Against SSL/TLS).<ref>{{cite news|last1=Goodin|first1=Dan|title=Google preps Chrome fix to slay SSL-attacking BEAST|url=https://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/|accessdate=16 September 2015|work=The Register|date=Sep 21, 2011}}</ref><ref>{{cite web|last1=Bard|first1=Gregory V.|title=A Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL|url=https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf|publisher=University of Maryland, Department of Mathematics|accessdate=16 September 2015}}</ref>

=== Crypto++ ===
[https://en.wikipedia.org/wiki/Crypto++ Crypto++] (also known as '''CryptoPP''', '''libcrypto++''', and '''libcryptopp''') is a free and open source C++ class library of cryptographic algorithms and schemes written by Wei Dai. Crypto++ has been widely used in academia, student projects, open source and non-commercial projects, as well as businesses.

=== VMAC ===
[https://en.wikipedia.org/wiki/VMAC VMAC] is a block cipher-based [https://en.wikipedia.org/wiki/Message_authentication_code message authentication code (MAC)] algorithm using a universal hash proposed by Ted Krovetz and Wei Dai in April 2007. The algorithm was designed for high performance backed by a formal analysis.<ref>{{cite web|last1=Krovetz|first1=Ted|last2=Dai|first2=Wei|title=VHASH Security|url=https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.9987|website=SiteSeerX|accessdate=16 September 2015|year=2007}}</ref>

=== [[b-money]] ===
In 1998, Dai helped to spark interest in [[Cryptocurrency|cryptocurrencies]]<ref name=washington-post-first-bitcoin /> with the publication of "b-money, an anonymous, distributed electronic cash system". In the paper, Dai outlines the basic properties of all modern day cryptocurrency systems: "...a scheme for a group of untraceable digital pseudonyms to pay each other with money and to enforce contracts amongst themselves without outside help".<ref>{{cite web|title=B-Money|url=http://www.weidai.com/bmoney.txt|author=Wei Dai|year=1998}}</ref>

== Influence on the development of Bitcoin ==
Described as "money which is impossible to regulate",<ref>{{cite news|title=The rise (and rise?) of Bitcoin|url=https://www.engadget.com/2013/05/08/engadget-primed-bitcoin/|author=Daniel Cooper|work=Engadget|date=May 8, 2013}}</ref> Dai's '''b-money''' described the core concepts later implemented in [[Bitcoin]]<ref>{{cite journal|work=Journal of Peer Production|issue=1.4|title=The politics of cryptography: Bitcoin and the ordering machines.|author=DuPont, Quinn|year=2014}}</ref> and other cryptocurrencies:

* Requires a specified amount of computational work (aka [[Proof of work]]).
* The work done is verified by the community who update a collective ledger book.
* The worker is awarded funds for their effort.
* Exchange of funds is accomplished by collective bookkeeping and authenticated with cryptographic hashes.
* Contracts are enforced through the broadcast and signing of transactions with digital signatures (i.e., [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]).

=== Relationship with Satoshi Nakamoto ===
Wei Dai and [[Adam Back]] were the first two people contacted by [[Satoshi Nakamoto]] as he was developing [[Bitcoin]] in 2008<ref name=nytimes-satoshi></ref> and the b-money paper was referenced in the subsequent Bitcoin whitepaper.<ref>{{cite web|url=https://bitcoin.org/bitcoin.pdf|title=Bitcoin: A Peer-to-Peer Electronic Cash System|author=[[Satoshi Nakamoto]]|}}</ref>

In a May 2011 article, noted cryptographer [[Nick Szabo]] states:

{{quote|text=Myself, Wei Dai, and [[Hal Finney]] were the only people I know of who liked the idea (or in Dai's case his related idea) enough to pursue it to any significant extent until Nakamoto (assuming Nakamoto is not really Finney or Dai).<ref>{{cite news|author=Nick Szabo |url=https://unenumerated.blogspot.com/2011/05/bitcoin-what-took-ye-so-long.html | title=Bitcoin, what took ye so long?|date=2011-05-28 |accessdate=2014-03-12|work=Unenumerated}}</ref>}}

However Dai questions b-money's influence on Bitcoin:

{{quote|text=...my understanding is that the creator of Bitcoin, who goes by the name Satoshi Nakamoto, didn't even read my article before reinventing the idea himself. He learned about it afterward and credited me in his paper. So my connection with the project is quite limited.<ref>{{cite web|url=https://www.lesswrong.com/posts/ijr8rsyvJci2edxot/making-money-with-bitcoin#hbEu9ue9eymNzaF2J|title=Wei_Dai comments on Making money with Bitcoin?|author=Wei Dai|}}</ref>}}

There has been much speculation as to the identity of Satoshi Nakamoto, with suspects including Wei Dai, [[Nick Szabo]], [[Hal Finney]] and accompanying denials.<ref name="LikeInAMirror1">{{cite web|title=Satoshi Nakamoto is (probably) Nick Szabo|url=https://likeinamirror.wordpress.com/2013/12/01/satoshi-nakamoto-is-probably-nick-szabo/#%21|work=LikeInAMirror|publisher=WordPress|accessdate=5 December 2013| archiveurl = http://web.archive.org/web/20140413135108/https://likeinamirror.wordpress.com/2013/12/01/satoshi-nakamoto-is-probably-nick-szabo/ | archivedate = 2014-04-13| deadurl=no}}</ref><ref>{{cite news |last= Weisenthal |first= Joe |url= https://www.businessinsider.com/did-shinichi-mochizuki-invent-bitcoin-2013-5?IR=T|title= Here's The Problem With The New Theory That A Japanese Math Professor Is The Inventor Of Bitcoin |publisher= Business Insider| date= 19 May 2013 |accessdate = 19 May 2013 | archiveurl = http://web.archive.org/web/20131103105304/http://www.businessinsider.com/did-shinichi-mochizuki-invent-bitcoin-2013-5 | archivedate = 2013-11-03| deadurl=no}}</ref><ref name="washington-post-first-bitcoin">{{cite news|last1=Peterson|first1=Andrea|title=Hal Finney received the first Bitcoin transaction. Here’s how he describes it.|url=https://www.washingtonpost.com/news/the-switch/wp/2014/01/03/hal-finney-received-the-first-bitcoin-transaction-heres-how-he-describes-it/|accessdate=16 September 2015|work=The Washington Post|date=January 3, 2014}}</ref><ref>{{cite news|last1=Vigna|first1=Paul|title=Bitcoin Creator ‘Satoshi Nakamoto’ Unmasked–Again?|url=https://blogs.wsj.com/moneybeat/2014/04/16/bitcoin-creator-satoshi-nakamoto-unmasked-again/|accessdate=16 September 2015|work=Wall Street Journal|date=Apr 16, 2014}}</ref>

=== Wei currency unit ===
The smallest unit of [[Ethereum#Ether|Ether]] (cryptocurrency of the [[Ethereum]] network) is the '''wei''' (named after Wei Dai).<ref>{{cite journal |last = Buterin|first = Vitalik|authorlink = Vitalik Buterin|url = https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-White-Paper|title = [English] White Paper: A Next-Generation Smart Contract and Decentralized Application Platform|work = ethereum / wiki on GitHub|publisher = Self-published|accessdate = 11 April 2014}}</ref><ref>{{cite web|last1=Wood|first1=DR. Gavin|title=Ethereum: A Secure Decentralised Generalised Transaction Ledger|url=http://gavwood.com/Paper.pdf|accessdate=16 September 2015}}</ref>

== External links ==
* [http://www.weidai.com/ Home page]
* [https://sourceforge.net/u/weidai/profile/ Profile on SourceForge]
* [https://www.lesswrong.com/users/wei_dai Posts on LessWrong]
* [https://nakamotoinstitute.org/authors/wei-dai/ Profile at the Nakamoto Institute]
* [https://scholar.google.com/citations?user=YQSmJLUAAAAJ&hl=en Wei Dai - Google Scholar Citations]

== References ==

Nanopayments

2018-02-15T06:09:57Z

JonathanCross: /* Notes */ Fix typo

''a.k.a. Micropayments''

Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.

It should be easy to see that a series of payments like this would be "spam" to Bitcoin, and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.

The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC, but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.

For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient.

Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.

=== Technical stuff: How can probabilistic transactions be created? ===

Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.

Alice will create a multi-input transaction that spends her own coin AND Bob's secret transaction. Here's where the random chance comes in. We're going to randomize the prevout identifying Bob's transaction. Multi-input transactions are not valid unless all their inputs exist, so if Bob's transaction is misidentified, the whole transaction is void.

For the hash identifying the secret transaction, Bob only gives Alice a numeric range that the hash is in. If the hash is H, and we want a 1/N chance of the nanopayment being real, then Bob would take H1=H-rand(N) and tell Alice the hash is between H1 and H1+N.

Alice chooses H2 in the range H1 to H1+N and creates the transaction. Input 1 is her coin, and input 2 uses H2 as the prevout hash that may or may not match Bob's secret transaction. She signs input 1 and gives the transaction to Bob. Note that signing one input locks in the prevouts of all inputs, so Bob can't change H2.

Bob now checks if the H2 she used equals H. If it is, he signs input 2 and broadcasts both his secret transaction and Alice's transaction.

If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.

=== What if Alice tries to [[double-spending|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain? ===

If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.

She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.

=== What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time? ===

This may not be a big enough problem to matter for most casual, low value uses.

If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients.

When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.

A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.

== Notes ==

This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.

[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

Although probabilistic payments were considered for the Lightning Network, the current lnd implementation does not use them. Instead, [https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L13-L18 it just rounds down to the nearest satoshi] when a channel is closed.

Nanopayments

2018-02-15T05:31:21Z

JonathanCross: /* Notes */ Adding info about lnd and probabilistic payment implimnetation

''a.k.a. Micropayments''

Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.

It should be easy to see that a series of payments like this would be "spam" to Bitcoin, and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.

The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC, but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.

For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient.

Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.

=== Technical stuff: How can probabilistic transactions be created? ===

Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.

Alice will create a multi-input transaction that spends her own coin AND Bob's secret transaction. Here's where the random chance comes in. We're going to randomize the prevout identifying Bob's transaction. Multi-input transactions are not valid unless all their inputs exist, so if Bob's transaction is misidentified, the whole transaction is void.

For the hash identifying the secret transaction, Bob only gives Alice a numeric range that the hash is in. If the hash is H, and we want a 1/N chance of the nanopayment being real, then Bob would take H1=H-rand(N) and tell Alice the hash is between H1 and H1+N.

Alice chooses H2 in the range H1 to H1+N and creates the transaction. Input 1 is her coin, and input 2 uses H2 as the prevout hash that may or may not match Bob's secret transaction. She signs input 1 and gives the transaction to Bob. Note that signing one input locks in the prevouts of all inputs, so Bob can't change H2.

Bob now checks if the H2 she used equals H. If it is, he signs input 2 and broadcasts both his secret transaction and Alice's transaction.

If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.

=== What if Alice tries to [[double-spending|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain? ===

If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.

She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.

=== What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time? ===

This may not be a big enough problem to matter for most casual, low value uses.

If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients.

When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.

A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.

== Notes ==

This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.

The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.

[[Tadge Dryja]] (of [[Lightning Network]] fame) talked about probabilistic payments in April 2016: [https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s]

Although probabilistic payments were considered for the Lightning Network, the current lnd implementation does not. Instead, [https://github.com/lightningnetwork/lnd/blob/master/lnwire/msat.go#L13-L18 it just rounds down to the nearest satoshi] when a channel is closed.

Nanopayments

2018-02-15T05:16:42Z

JonathanCross: /* Technical stuff: How can probabilistic transactions be created? */ Improving header formatting

Satoshi Client Node Discovery

2017-12-19T02:29:15Z

JonathanCross: /* DNS Addresses */ Updating line number for seed nodes and month to now.

==Overview==

The Satoshi client discovers the IP address and port of nodes in several different ways.

# Nodes discover their own external address by various methods.
# Nodes receive the callback address of remote nodes that connect to them.
# Nodes makes DNS request to receive IP addresses.
# Nodes can use addresses hard coded into the software.
# Nodes exchange addresses with other nodes.
# Nodes store addresses in a database and read that database on startup.
# Nodes can be provided addresses as command line arguments
# Nodes read addresses from a user provided text file on startup

A timestamp is kept for each address to keep track of when the node
address was last seen. The AddressCurrentlyConnected in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] handles
updating the timestamp whenever a message is received from a node.
Timestamps are only updated on an address and saved to the database
when the timestamp is over 20 minutes old.

See the Node Connectivity article for information on which type of
addresses take precedence when actually connecting to nodes.

In the first section we will cover how a node handles a request for
addresses via the "getaddr" message. By understanding the role of
timestamps, it will become more clear why timestamps are kept the way
they are for each of the different ways an address is discovered.

==Handling Message "getaddr"==

When a node receives a "getaddr" request, it first figures out how many
addresses it has that have a timestamp in the last 3 hours.
Then it sends those addresses, but if there are more than 2500 addresses
seen in the last 3 hours, it selects around 2500 out of the available
recent addresses by using random selection.

Now lets look at the ways a node finds out about node addresses.

==Discovery Methods==

===Local Client's External Address===
The client uses public web services which return the information to determine its own external, routable IP address.

The client runs a thread called ThreadGetMyExternalIP (in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp])
which attempts to determine the client's IP address as seen from the outside
world.

First, it attempts to connect to 91.198.22.70 port 80, which should be
the checkip.dyndns.org server. If connection fails, a DNS request is made
for checkip.dyndns.org and a connection is attempted to that address.
Next, it attempts to connect to 74.208.43.192 port 80, which should be
the www.showmyip.com server. If connection fails, a DNS request is made
for www.showmyip.com and a connection is attempted to that address.

For each address attempted above, the client attempts to connect,
send a HTTP request, read the appropriate response line, and parse the
IP address from it.
If this succeeds, the IP address is returned, it is advertised to any connected
nodes, and then the thread finishes (without proceeding to the next
address).

===Connect Callback Address===
When a node receives an initial "version" message, and that node initiated the connection, then the node advertises its address to the remote so that it can connect back to the local node if it wants to.

After sending its own address, it sends a "getaddr" request message to the remote node to learn about more addresses, if the remote node version is recent or if the local node does not yet have 1000 addresses.

===IRC Addresses===

As of version 0.6.x the Bitcoin client no longer uses IRC bootstrapping by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. This documentation below is accurate for most prior versions.

In addition to learning and sharing its own address, the node learned about other node addresses via an IRC channel. See [https://github.com/bitcoin/bitcoin/blob/847593228de8634bf6ef5933a474c7e63be59146/src/irc.cpp irc.cpp].

After learning its own address, a node encoded its own address into a string to be used as a nickname. Then, it randomly joined an IRC channel named between #bitcoin00 and #bitcoin99. Then it issued a WHO command. The thread read the lines as they appeared in the channel and decoded the IP addresses of other nodes in the channel. It did this in a loop, forever, until the node was shutdown.

When the client discovered an address from IRC, it set the timestamp on the address to the current time, but it used a "penalty" of 51 minutes, which means it looked like it was actually seen almost an hour earlier.

===DNS Addresses===
Upon startup, if peer node discovery is needed, the client then issues DNS requests to learn about the addresses of other peer nodes. The client includes a list of host names for DNS services that are seeded. As of December, 2017 the list (from chainparams.cpp<ref>[https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L128 bitcoin/src/chainparams.cpp at master]</ref>) includes:

* seed.bitcoin.sipa.be
* dnsseed.bluematt.me
* dnsseed.bitcoin.dashjr.org
* seed.bitcoinstats.com
* seed.bitcoin.jonasschnelli.ch
* seed.btc.petertodd.org

A DNS reply can contain multiple IP addresses for a requested name.

Addresses discovered via DNS are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

===Hard Coded "Seed" Addresses===
The client contains hard coded IP addresses that represent bitcoin nodes.

These addresses are only used as a last resort, if no other method has produced any addresses at all. When the loop in the connection handling thread ThreadOpenConnections2() sees an empty address map, it uses the "seed" IP addresses as backup.

There is code is move away from seed nodes when possible. The presumption is that this is to avoid overloading those nodes. Once the local node has enough addresses (presumably learned from the seed nodes), the connection thread will close seed node connections.

Seed Addresses are initially given a zero timestamp,
therefore they are not advertised in response to a "getaddr" request.

===Ongoing "addr" advertisements===
Nodes may receive addresses in an "addr" message after having sent a "getaddr" request, or "addr" messages may arrive unsolicited, because nodes advertise addresses gratuitously when they relay addresses (see below), when they advertise their own address periodically, and when a connection is made.

If the address is from a really old version, it is ignored; if from a not-so-old version, it is ignored if we have 1000 addresses already.

If the sender sent over 1000 addresses, they are all ignored.

Addresses received from an "addr" message have a timestamp, but the timestamp is not necessarily honored directly.

For every address in the message:
# If the timestamp is too low or too high, it is set to 5 days ago.
# We subtract 2 hours from the timestamp and add the address.

Note that when any address is added, for any reason, the code that calls AddAddress() does not check to see if it already exists. The AddAddresss() function in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] will do that, and if the address already exists, further processing is done to update the address record. If the advertised services of the address have changed, that is updated and stored.

If the address has been seen in the last 24 hours and the timestamp is currently over 60 minutes old, then it is updated to 60 minutes ago.

If the address has NOT been seen in the last 24 hours, and the timestamp is currently over 24 hours old, then it is updated to 24 hours ago.

====Address Relay====

Once addresses are added from an "addr" message (see above), they then may be relayed to the other nodes. First, the following criteria must be set [9]:

#The address timestamp, after processing, is within 60 minutes of the current time
#The "addr" message contains 10 addresses or less
#And fGetAddr is not set on the node. fGetAddr starts false, is set to true when we request addresses from a node, and it is cleared when we receive less than 1000 addresses from a node.
#The address must be routable.

For every address that meets the above criteria, the node hash the address, the current day (in the form of an integer), and a random 256 bit value (generated at client startup). The node takes the two addresses with the lowest hash values and relays "addr" messages to them. This ensures that each node only relays "addr" messages to two other clients at any given time, that the two other clients are randomly selected, and that the random selection starts over at least once every 24 hours.

====Self broadcast====

Every 24 hours, the node advertises its own address to all connected nodes.

It also clears the list of the addresses we think the remote node has, which will trigger a refresh of sends to nodes. This code is in SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp].

====Old Address Cleanup====

In SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp], there is code to remove old addresses.

This is done every ten minutes, as long as there are 3 active connections.

The node erases messages that have not been used in 14 days as long as there are at least 1000 addresses in the map, and as long as the erasing process has not taken more than 20 seconds.

===Addresses stored in the Database===
Addresses are stored in the database when AddAddress() is called.

Addresses are read on startup when AppInit2() calls LoadAddresses(), which is located in [https://github.com/bitcoin/bitcoin/blob/master/src/db.cpp db.cpp].

Currently, it appears all addresses are stored all at once whenever any address is stored or updated<ref>[http://bitcointalk.org/index.php?topic=26436.0 Lots of disk activity on Bitcoin startup: easy fix?]</ref>. Indeed, AddAddress is seen to take over .01 seconds in various testing and is typically called tens of thousands of times in the initial 12 hours of running the client.

===Command Line Provided Addresses===

The user can specify nodes to connect to with the
-addnode <ip>
command line argument. Multiple nodes may be specified.

Addresses provided on the command line are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

The user can also specify an address to connect to with the -connect <ip>
command line argument. Multiple nodes may be specified.

The -connect argument differs from -addnode in that -connect addresses are not added to the address database and when -connect is specified, only those addresses are used.

===Text File Provided Addresses===

The client will automatically read a file named "addr.txt" in the bitcoin data directory and will add any addresses it finds in there as node addresses. These nodes are given no special preference over other addresses. They are just added to the pool.

Addresses loaded from the text file are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

==See Also==

* [[Network#Bootstrapping|Network - Boostrapping]]

==References==
<references />

[[Category:Developer]]
[[Category:Technical]]

How to import private keys

2017-12-19T01:54:48Z

JonathanCross: /* Start Bitcoin client */ "damon" => "daemon"

'''WARNING'''

Before reading this page, users should note that messing with ECDSA private keys is very dangerous and can result in losing bitcoins, even long after the import.
It is recommended that outside of self-generated vanity addresses, users should ''never'' import (or export) private keys.<ref>[https://bitcoin.stackexchange.com/questions/29948/why-doc-says-importing-private-keys-is-so-dangerous Bitcoin StackExchange - Why doc says importing private keys is so dangerous?]</ref><ref>[https://bitcoin.stackexchange.com/questions/18619/why-so-many-warnings-about-importing-private-keys Bitcoin StackExchange - Why so many warnings about importing private keys?]</ref>

= Using Blockchain.info =
As of August 2012, possibly the easiest way to import a private key is using [[Blockchain.info]]'s My Wallet service. When successully imported through the "Import/Export" screen, the bitcoins assigned to a private key can be immediately sent to any Bitcoin address.

= Using BIPS =
As of August 2013, [[File:BIPS.gif|20px|link=https://bips.me]] [[BIPS]] allows for easy import of private key using Paper Wallet - Import. User can choose to type in the private key manually or scan a QR code containing the private key using the camera. The user must wait 6 confirmations for access to the funds, and system is based on batch importation.

= Using Mycelium =
Steps described are with the following settings:
* Export mode enabled
* Aggregated view disabled

== Partial spend from cold storage ==
Use this function if you would like to keep some funds on the paper wallet.
# Download [https://play.google.com/store/apps/details?id=com.mycelium.wallet&hl=en Mycelium] from the Android Play Store or through iTunes.
# Press the menu button and select "Cold Storage"
# Scan in private key
# Select your destination address
# Select the amount
## Press the blue currency tag at the top to toggle currency.
# Send!

After spending, the private key in memory is destroyed so the paper private key remains somewhat secure. Despite this, best practice is to immediately send the remaining balance to a paper wallet that was generated offline.

== Import key from a paper wallet ==
Use this function if you would like to import a private key so all funds are immediately available for spending.
# Download [https://play.google.com/store/apps/details?id=com.mycelium.wallet&hl=en Mycelium] from the Android Play Store or through iTunes.
# Key Management
# Press the blue '+' symbol
# Scan in private key

After importing this paper private key, you might consider destroying the original so it cannot be found and your funds stolen. Alternatively, you can keep it safe to be used as an offline backup.

= Using bitcoind =
'''If you have Version 7 or later it is now trival.''' See: [[How to import private keys v7+]]

If you are using [[Cold storage]], a [[Paper wallet]] or generating [https://bitcointalk.org/index.php?topic=25804.0 vanity addresses] you may have a need to import a [[Private key]]. Since Bitcoin-QT/bitcoind v0.6.0, you can import private keys using built-in RPC command [[importprivkey]]. Before v0.6.0, you needed to rely on third-party [[wallet.dat]] manipulation tool such as [[Pywallet]].

This article describes how to import a private key through the RPC API of bitcoind, which is a topic for advanced users.

'''Note that importing a key to bitcoind and/or Bitcoin-Qt may be dangerous and is not recommended unless you understand the full details of how it works'''

== Start Bitcoin client ==
Unlike third-party wallet.dat manipulation tools such as [[Pywallet]], you do not have to close the Bitcoin client before proceeding. Instead, you need to start the bitcoind server.
* Close bitcoin-qt and start <code>bitcoind -daemon</code> in Terminal Emulator. The version of bitcoind MUST be the same as bitcoin-qt!

Bitcoin-QT does not enable its RPC interface by default. To enable it:
* Close Bitcoin-QT and restart it with ''bitcoin-qt -server''.

== Unlock your wallet ==
If you have an encrypted wallet (recommended), you need to unlock it temporarily before importing private keys. The RPC command for unlocking an encrypted wallet is ''walletpassphrase <passphrase> <timeout>''. Typing this directly in a bash terminal will leave your wallet passphrase directly in the bash history but there are a couple of techniques you can use to avoid this. Simply add a space before the command:

(space)bitcoind walletpassphrase yourpassphrase 120

Another alternative is to use a bash variable:

read x
(input your passphrase)
bitcoind walletpassphrase "$x" 120 # Do not set the timeout too long or too short.

== Import Private key(s) ==
The last command unlocked your wallet temporarily for 120 seconds, during which time you must import your private keys. Since private keys can be as important as your passphrase, you may want to use the same techniques as above to prevent their being recorded in bash history (bash variable or space before the command):

(space)bitcoind importprivkey "5yourveryveryveryverylongprivatekeystring" "my-new-key" # "my-new-key" is a label for the key/address pair and is optional

The importing process is now started. Bitcoind will rescan the entire block data to ensure this key has not been used before. This process will take from one to two minutes, depending on your CPU performance. DO NOT abort it before finishing!

To avoid rescanning run the following.

(space)bitcoind importprivkey 5yourveryveryveryverylongprivatekeystring" "label-here" rescan=false

If no errors occurs, the import is a success and Bitcoin-QT users will be able to see the new address in the GUI immediately. If you need to import more keys, just repeat the instructions above. There is currently no command to import a batch of private keys so you will need to wait a minute or two for each key to be imported.

== Cleaning up ==

bitcoind walletlock

This will lock your wallet again (so you don't have to wait for timeout)

unset x
unset y

These commands will clear the passphrase and private key from memory if you used the ''read'' technique. If you started bitcoind, you will need to stop it before Bitcoin-QT will start again:

bitcoind stop

===Deleting Keys===
At some point, you may wish to delete private keys from a wallet.dat file but as of version v0.6.0 of Bitcoin-QT/bitcoind, there is no RPC method available for this purpose.

==References==
<references />

[[Category:Instructional]]

Myths

2017-09-21T18:50:16Z

JonathanCross: /* Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization */ Improvements: cash is still more "anonymous".

Let's clear up some common Bitcoin misconceptions.

== Bitcoin is just like all other digital currencies; nothing new ==

Nearly all other digital currencies are centrally controlled. This means that:
* They can be printed at the subjective whims of the controllers
* They can be destroyed by attacking the central point of control
* Arbitrary rules can be imposed upon their users by the controllers

Being decentralized, Bitcoin solves all of these problems.

== Bitcoins don't solve any problems that fiat currency and/or gold doesn't solve ==

Unlike gold, bitcoins are:
* Easy to transfer
* Easy to secure
* Easy to verify
* Easy to granulate

Unlike fiat currencies, bitcoins are:
* Predictable and limited in [[Controlled_Currency_Supply|supply]]
* Not controlled by a central authority (such as [http://en.wikipedia.org/wiki/Federal_Reserve The United States Federal Reserve])
* Not debt-based

Unlike electronic fiat currency systems, bitcoins are:
* Potentially anonymous
* Freeze-proof
* Faster to transfer
* Cheaper to transfer

== Miners, developers or some other entity could change Bitcoin's properties to benefit themselves ==

Bitcoin's properties cannot be illegitimately changed as long as most of bitcoin's [[economic majority|economy]] uses [[full node]] wallets. Transactions are irreversible and uncensorable as long as [[Majority_attack|no single coalition of miners has more than 50% hash power]] and the transactions have an [[Confirmation#How_Many_Confirmations_Is_Enough|appropriate number of confirmations]].

Bitcoin requires certain properties to be enforced for it to be a good form of money, for example:

# Nobody ever created money out of nothing (except for [[Mining|miners]], and only according to a [[Controlled supply|well-defined schedule]]).
# Nobody ever spent coins without knowing their [[private key]].
# Nobody spent the same coin twice
# Nobody violated any of the other tricky rules that are needed to make the system work ([[difficulty]], [[proof of work]], DoS protection, ...).

These rules ''define'' bitcoin. A [[full node]] is software that verifies the rules of bitcoin. Any transaction which breaks these rules is not a valid bitcoin transaction and would be rejected in the same way that a careful goldsmith rejects fool's gold.

Full node wallets should be used by any intermediate bitcoin user or above and especially [[Why_Your_Business_Should_Use_a_Full_Node_to_Accept_Bitcoin|bitcoin businesses]]. Therefore anybody attempting to create bitcoins with invalid properties will find themselves being rejected by any trading partners. Note that lightweight wallets and web wallets do not have the low-trust benefits of full node wallets. Lightweight (SPV) wallets will blindly trust the miners, meaning if 51% of miners printed infinite coins or spent the same coin twice then lightweight wallet users would happily accept these fake bitcoins as payment. Web wallets blindly trust the web server which could display anything at all.

[[Mining|Miners]] are required to choose between multiple ''valid'' transaction histories. A coalition of more than 50% of miner power is able to (at great expense to themselves) [[Majority_attack|rewrite transaction history]], so miner decentralization is necessary to keep transactions irreversible. Miners burn a lot of electrical power in the mining process so they must constantly be trading their bitcoin income in order to pay bills. This makes miners utterly dependent on the bitcoin economy at large and therefore gives them a strong incentive to mine ''valid'' bitcoin blocks that full nodes will accept as payment.

Influential figures in the community (such as developers, politicians or investors) may try to use their influence to convince people to download and run modified full node software which changes bitcoin's properties in illegitimate ways. This is unlikely to succeed as long as counterarguments can freely spread through the media, internet forums and chatrooms. Many bitcoin users do not follow the bitcoin forums on a regular basis or even speak English. All appeals to run alternative software should be looked at critically for whether the individual agrees with the changes being proposed. Full node software should always be open source so any programmer can examine the changes for themselves. Because of the co-ordination problem, there is usually a strong incentive to stick with the status quo.

See also: [[Full_node#Economic_strength]]
See also this blog post: [http://nakamotoinstitute.org/mempool/who-controls-bitcoin/ Who Controls Bitcoin?]

== Bitcoin is backed by processing power ==

It is not correct to say that Bitcoin is "backed by" processing power. A currency being "backed" means that it is pegged to something else via a central party at a certain exchange rate yet you cannot exchange bitcoins for the computing power that was used to create them. Bitcoin is in this sense not backed by anything. It is a currency in its own right. Just as gold is not backed by anything, the same applies to Bitcoin.

The Bitcoin currency is ''created'' via processing power, and the integrity of the block chain is ''protected'' by the existence of a network of powerful computing nodes from certain [[Weaknesses#Attacker_has_a_lot_of_computing_power|attacks]].

== Bitcoins are worthless because they aren't backed by anything ==

One could argue that gold isn't backed by anything either. Bitcoins have properties resulting from the system's design that allows them to be subjectively valued by individuals. This valuation is demonstrated when individuals freely exchange for or with bitcoins. Please refer to the [http://en.wikipedia.org/wiki/Subjective_theory_of_value Subjective Theory of Value].

See also: the "[[#Bitcoin_is_backed_by_processing_power|Bitcoin is backed by processing power]]" myth.

== The value of bitcoins are based on how much electricity and computing power it takes to mine them ==

This statement is an attempt to apply to Bitcoin the [http://en.wikipedia.org/wiki/Labor_theory_of_value labor theory of value], which is generally accepted as false. Just because something takes X resources to create does not mean that the resulting product will be worth X. It can be worth more, or less, depending on the utility thereof to its users.

In fact the causality is the reverse of that (this applies to the labor theory of value in general). The cost to mine bitcoins is based on how much they are worth. If bitcoins go up in value, more people will mine (because [[Mining|mining]] is profitable), thus [[difficulty]] will go up, thus the cost of mining will go up. The inverse happens if bitcoins go down in value. These effects balance out to cause mining to always cost an amount proportional to the value of bitcoins it produces<ref>[https://www.bitcoinmining.com Bitcoin Mining]</ref>.

== Bitcoin has no intrinsic value (unlike some other things) ==

This is simply not true. Each bitcoin gives the holder the ability to embed a large number of short in-transaction messages in a globally distributed and timestamped permanent data store, namely the bitcoin blockchain. There is no other similar datastore which is so widely distributed. There is a tradeoff between the exact number of messages and how quickly they can be embedded. But as of December 2013, it's fair to say that one bitcoin allows around 1000 such messages to be embedded, each within about 10 minutes of being sent, since a fee of 0.001 BTC is enough to get transactions confirmed quickly. This message embedding certainly has intrinsic value since it can be used to prove ownership of a document at a certain time, by including a one-way hash of that document in a transaction. Considering that electronic notarization services charge something like $10/document, this would give an intrinsic value of around $10,000 per bitcoin.

While some other tangible commodities do have intrinsic value, that value is generally much less than its trading price. Consider for example that gold, if it were not used as an inflation-proof store of value, but rather only for its industrial uses, would certainly not be worth what it is today, since the industrial requirements for gold are far smaller than the available supply thereof.

In any event, while historically intrinsic value, as well as other attributes like divisibility, fungibility, scarcity, durability, helped establish certain commodities as mediums of exchange, it is certainly not a prerequisite. While bitcoins are accused of lacking 'intrinsic value' in this sense, they make up for it in spades by possessing the other qualities necessary to make it a good medium of exchange, equal to or better than [http://en.wikipedia.org/wiki/Commodity_money commodity money].

Another way to think about this is to consider the value of bitcoin the global network, rather than each bitcoin in isolation. The value of an individual telephone is derived from the network it is connected to. If there was no phone network, a telephone would be useless. Similarly the value of an individual bitcoin derives from the global network of bitcoin-enabled merchants, exchanges, wallets, etc... Just like a phone is necessary to transmit vocal information through the network, a bitcoin is necessary to transmit economic information through the network.

Value is ultimately determined by what people are willing to trade for - by supply and demand.

== Bitcoin is illegal because it's not legal tender ==
In March 2013, the U.S. [http://en.wikipedia.org/wiki/Financial_Crimes_Enforcement_Network Financial Crimes Enforcement Network] issues a new set of guidelines on "de-centralized virtual currency", clearly targeting Bitcoin. Under the new guidelines, "a user of virtual currency is not a Money Services Businesses (MSB) under FinCEN's regulations and therefore is not subject to MSB registration, reporting, and record keeping regulations." <ref>[http://arstechnica.com/tech-policy/2013/03/us-regulator-bitcoin-exchanges-must-comply-with-money-laundering-laws/ US regulator: Bitcoin exchanges must comply with money-laundering laws | Ars Technica]</ref> [[Mining|Miners]], when mining bitcoins for their own personal use, aren't required to register as a MSB or Money Transmitter. <ref>[http://fincen.gov/news_room/rp/rulings/html/FIN-2014-R001.html Application of FinCEN’s Regulations to Virtual Currency Mining Operations | Fincen]</ref>

In general, there are a [http://en.wikipedia.org/wiki/Local_currency number of currencies] in existence that are not official government-backed currencies. A currency is, after all, nothing more than a convenient unit of account. While national laws may vary from country to country, and you should certainly check the laws of your jurisdiction, in general trading in any commodity, including digital currency like Bitcoin, [http://en.wikipedia.org/wiki/BerkShares BerkShares], game currencies like WoW gold, or Linden dollars, is not illegal.

== Bitcoin is a form of domestic terrorism because it only harms the economic stability of the USA and its currency ==

According to [http://en.wikipedia.org/wiki/Definitions_of_terrorism#United_States the definition of terrorism in the United States], you need to do violent activities to be considered a terrorist for legal purposes. Recent off-the-cuff remarks by politicians have no basis in law or fact.

Also, Bitcoin isn't domestic to the US or any other country. It's a worldwide community, as can be seen in this [https://bitnodes.21.co/nodes/live-map/ map of Bitcoin nodes].

== Bitcoin will only enable tax evaders which will lead to the eventual downfall of civilization ==

Cash transactions offer an increased level of [[anonymity]], yet are still taxed successfully. It is up to you to follow the applicable tax laws in your home country, or face the consequences.

While it may be easy to transfer bitcoins pseudonymously, ''spending'' them on tangibles is just as hard as spending any other kind of money anonymously. Tax evaders are often caught because their lifestyle and assets are inconsistent with their reported income, and not necessarily because government is able to follow their money.

Finally, the Bitcoin [[blockchain]] is a permanent record of all transactions, meaning it can be mined for info at any time in the future making investigation, tracing of funds, etc much easier than with other forms of payment.

== Bitcoins can be printed/minted by anyone and are therefore worthless ==

Bitcoins are not printed/minted. Instead, [[Blocks]] are computed by miners and for their efforts they are awarded a specific amount of bitcoins and transaction fees paid by others. See [[Mining]] for more information on how this process works.

== Bitcoins are worthless because they're based on unproven cryptography ==

SHA256 and [[ECDSA]] which are used in Bitcoin are well-known industry standard algorithms. SHA256 is endorsed and used by the US Government and is standardized (FIPS180-3 Secure Hash Standard). If you believe that these algorithms are untrustworthy then you should not trust Bitcoin, credit card transactions or any type of electronic bank transfer. Bitcoin has a sound basis in well understood cryptography.

== Early adopters are unfairly rewarded ==

Early adopters are rewarded for taking the higher risk with their time and money. The capital invested in bitcoin at each stage of its life invigorated the community and helped the currency to reach subsequent milestones. Arguing that early adopters do not deserve to profit from this is akin to saying that early investors in a company, or people who buy stock at a company IPO (Initial Public Offering), are unfairly rewarded.

This argument also depends on bitcoin early adopters using bitcoins to store rather than transfer value. The daily trade on the exchanges (as of Jan 2012) indicates that smaller transactions are becoming the norm, indicating trade rather than investment. In more pragmatic terms, "fairness" is an arbitrary concept that is improbable to be agreed upon by a large population. Establishing "fairness" is no goal of Bitcoin, as this would be impossible.

Looking forwards, considering the amount of publicity bitcoin received as of April 2013, there can be no reasonable grounds for complaint for people who did not invest at that time, and then see the value (possibly) rising drastically higher.

By starting to mine or acquire bitcoins today, you too can become an early adopter.

== 21 million coins isn't enough; doesn't scale ==

One Bitcoin is divisible down to eight decimal places. There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin system.

The value of "1 BTC" represents 100,000,000 of these. In other words, each bitcoin is divisible by up to 108.

As the value of the unit of 1 BTC grew too large to be useful for day to day transactions, people started dealing in smaller [[Units|units]], such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).

== Bitcoins are stored in wallet files, just copy the wallet file to get more coins! ==

No, your wallet contains your secret keys, giving you the rights to spend your bitcoins. Think of it like having bank details stored in a file. If you give your bank details (or bitcoin wallet) to someone else, that doesn't double the amount of money in your account. You can spend your money or they can spend your money, but not both.

== Lost coins can't be replaced and this is bad ==

Bitcoins are divisible to 0.00000001, so there being fewer bitcoins remaining is not a problem for the currency itself. If you lose your coins, indirectly all other coins are worth more due to the reduced supply. Consider it a donation to all other bitcoin users.

A related question is: Why don't we have a mechanism to replace lost coins? The answer is that it is impossible to distinguish between a 'lost' coin and one that is simply sitting unused in someone's wallet. And for amounts that are provably destroyed or lost, there is no census that this is a bad thing and something that should be re-circulated.

== It's a giant ponzi scheme ==
In a [[Wikipedia:Ponzi_scheme|Ponzi Scheme]], the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.

A Ponzi scheme is a zero sum game. In a ponzi scheme, early adopters can only profit at the expense of late adopters, and the late adopters always lose. Bitcoin can have a win-win outcome. Earlier adopters profit from the rise in value as Bitcoin becomes better understood and in turn demanded by the public at large. All adopters benefit from the usefulness of a reliable and widely-accepted decentralized peer-to-peer currency.<ref name=Jeff_Tucker>cf. {{cite news | author-link = Wikipedia:Jeffrey_Tucker | url = http://libertarianstandard.com/2013/12/01/ponzi-logic-debunking-gary-north/ | title = Ponzi Logic: Debunking Gary North | last = Tucker | first = Jeffrey | date = 1 December 2013 | work = The Libertarian Standard | accessdate = 2015-04-11}}</ref>

It is also important to note that [[Satoshi Nakamoto]], creator of bitcoin, has never spent a bitcoin (other than giving them away when they were worthless) which we can verify by checking the blockchain.

== Finite coins plus lost coins means deflationary spiral ==
As deflationary forces may apply, economic factors such as hoarding are offset by human factors that may lessen the chances that a [[Deflationary spiral]] will occur.

== Bitcoin can't work because there is no way to control inflation ==

Inflation is simply a rise of prices over time, which is generally the result of the devaluing of a currency. This is a function of supply and demand. Given the fact that the supply of bitcoins is fixed at a certain amount, unlike fiat money, the only way for inflation to get out of control is for demand to disappear. Temporary inflation is possible with a rapid adoption of Fractional Reserve Banking but will stabilize once a substantial number of the 21 million "hard" bitcoins are stored as reserves by banks.

Given the fact that Bitcoin is a distributed system of currency, if demand were to decrease to almost nothing, the currency would be doomed anyway.

The key point here is that Bitcoin as a currency can't be inflated by any single person or entity, like a government, as there's no way to increase supply past a certain amount.

Indeed, the most likely scenario, as Bitcoin becomes more popular and demand increases, is for the currency to increase in value, or deflate, until demand stabilizes.

== The Bitcoin community consists of anarchist/conspiracy theorist/gold standard 'weenies' ==

The members of the community vary in their ideological stances. While it may have been started by ideological enthusiasts, Bitcoin now speaks to a large number of regular pragmatic folk, who simply see its potential for reducing the costs and friction of global e-commerce.

== Anyone with enough computing power can take over the network ==

CONFIRMED, see [[Weaknesses]].

That said, as the network grows, it becomes harder and harder for a single entity to do so. Already the Bitcoin network's computing power is quite ahead of the world's fastest supercomputers, together.

What an attacker can do once the network is taken over is quite limited. Under no circumstances could an attacker create counterfeit coins, fake transactions, or take anybody else's money. An attacker's capabilities are limited to taking back their own money that they very recently spent, and preventing other people's transactions from receiving confirmations. Such an attack would be very costly in resources, and for such meager benefits there is little rational economic incentive to do such a thing.

Furthermore, this attack scenario would only be feasible for as long as it was actively underway. As soon as the attack stopped, the network would resume normal operation.

== Bitcoin violates governmental regulations ==

There is no known governmental regulation which disallows the use of Bitcoin.

See also: the "[[#Bitcoins_are_illegal_because_they.27re_not_legal_tender|Bitcoins are illegal because they're not legal tender]]" myth.

== Fractional reserve banking is not possible ==

It is possible. See the main article, [[Fractional Reserve Banking and Bitcoin]]

== After 21 million coins are mined, no one will generate new blocks ==

When operating costs can't be covered by the block creation bounty, which will happen some time before the total amount of BTC is reached, miners will earn some profit from [[transaction fees]]. However unlike the block reward, there is [http://bitcoin.stackexchange.com/questions/876/how-much-will-transaction-fees-eventually-be/895#895 no coupling between transaction fees and the need for security], so there is less of a guarantee that the amount of [[Mining|mining]] being performed will be sufficient to maintain the network's security.

== Bitcoin has no built-in chargeback mechanism and this is bad ==

Bitcoin base-layer transactions are [[Irreversible Transactions|final and irreversible by design]], but consumer protection can still built into bitcoin in other layers on top. The most practical way of doing this is [[Multisignature|multisig]] escrow. For example when trading over-the-counter, [[Secure_Trading#Use_an_Escrow_Service|using an escrow]] is essential protection.

It's worth noting that virtually all successful consumer-facing bitcoin businesses do indeed already implement some kind of consumer protection; Routine escrow was used by Localbitcoins, Silk Road and the bitcoin ebay-site Bitmit. Others such as online bitcoin casinos rely on their long-standing reputation, while others such as Coinbase.com rely on the legal and regulatory system.

The bitcoin method of routinely using escrow has benefits over competitors like credit cards. The security of credit cards is not very good which results in higher costs overall and the possibility of payments being reversed for months afterwards. By contrast when bitcoins have been released to the seller from escrow, they cannot be reversed as the coins are truely in the seller's possession. The requirement to use real-life names for credit cards and PayPal also excludes unbanked people and those from countries with less developed financial infrastructure. There are also downsides like bitcoin is not yet as widely accepted as credit cards and is not a front for providing lines of credit.

== Quantum computers would break Bitcoin's security ==

While ECDSA is indeed not secure under quantum computing, quantum computers don't yet exist and probably won't for a while.
The DWAVE system often written about in the press is, even if all their claims are true, not a quantum computer of a kind that could be used for cryptography.
Bitcoin's security, when used properly with a new address on each transaction, depends on more than just ECDSA: Cryptographic hashes are much stronger than ECDSA under QC.
Bitcoin's security was designed to be upgraded in a forward compatible way and could be [http://en.wikipedia.org/wiki/Post-quantum_cryptography upgraded] if this were considered an imminent threat.

See the implications of quantum computers on public key cryptography here http://en.wikipedia.org/wiki/Quantum_computer#Potential

The ''risk'' of quantum computers is also there for financial institutions, like banks, because they heavily rely on cryptography when doing transactions.

== Bitcoin makes self-sufficient artificial intelligence possible ==
[[StorJ]]<ref>[http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html StorJ And Bitcoin Autonomous Agents]</ref>, a theorized autonomous agent which utilizes humans to build itself and issues autonomous payments for improvement work done, is not a conscious entity. Whatever AI is possible, is not going to be magically more possible simply because it could incentivize human behaviour with pseudonymous Bitcoin payments.

== [[Mining|Bitcoin mining]] is a waste of energy and harmful for ecology ==
No more so than the wastefulness of mining gold out of the ground, melting it down and shaping it into bars, and then putting it back underground again. Not to mention the building of big fancy buildings, the waste of energy printing and minting all the various fiat currencies, the transportation thereof in armored cars by no less than two security guards for each who could probably be doing something more productive, etc.

As far as mediums of exchange go, Bitcoin is actually quite economical of resources, compared to others.

'''Economic Argument 1'''

[[Mining|Bitcoin mining]] is a highly competitive, dynamic, almost [http://en.wikipedia.org/wiki/Perfect_market perfect], market. Mining rigs can be set up and dismantled almost anywhere in the world with relative ease. Thus, market forces are constantly pushing mining activity to ''places'' and ''times'' where the marginal price of electricity is low or zero. These electricity products are cheap for a reason. Often, it’s because the electricity is difficult (and wasteful) to transport, difficult to store, or because there is low demand and high supply. Using electricity in this way is a lot less wasteful than simply plugging a mining rig into the mains indiscriminately.

For example, Iceland produces an excess of cheap electricity from renewable sources, but it has no way of exporting electricity because of its remote location. It is conceivable that at some point in future Bitcoin mining will only be profitable in places like Iceland, and unprofitable in places like central Europe, where electricity comes mostly from nuclear and fossil sources.

Market forces could even push mining into innovative solutions that have an effective electricity consumption of ''zero''. Mining always produces heat equivalent to the energy consumed - for example, 1000 watts of mining equipment produces the same amount of heat as a 1000 watt heating element used in an electric space heater, hot tub, water heater, or similar appliance. Someone already in a willing position to incur the cost of electricity for its heat value alone could run mining equipment specially designed to mine bitcoins while capturing and utilizing the heat produced, without incurring any energy costs beyond what they already intended to spend on heating.

(Note that this is just an example; mining will not always produce heat equivalent to the energy consumed because some energy is inevitably released as electromagnetic radiation, among others.)

'''Economic Argument 2'''

When the environmental costs of mining are considered, they need to be weighed up against the benefits. If you question Bitcoin on the grounds that it consumes electricity, then you should also ask questions like this: Will Bitcoin promote economic growth by freeing up trade? Will this speed up the rate of technological innovation? Will this lead to faster development of green technologies? Will Bitcoin enable new, border crossing [http://en.wikipedia.org/wiki/Smart_grid smart grid] technologies? …

Dismissal of Bitcoin because of its costs, while ignoring its benefits, is a dishonest argument. In fact, any environmental argument of this type is dishonest, not just pertaining to Bitcoin. Along similar lines, it could be argued that wind turbines are bad for the environment because making the steel structure consumes energy.

'''Ratio of Capital Costs versus Electrical Costs'''

The BFL Jalapeno hashes at 5.5 Gh/s using 30W. That device consumes about $40 per year in electricity (using U.S. residential average of about $0.15 per kWh.) But the device costs over $300 including shipping. Thus, just about a quarter of all costs over a two-year useful life goes to electricity. This compares to GPUs where more than 90% of costs over a two-year life went to electricity. Even more efficient designs can be expected in the future.

== Shopkeepers can't seriously set prices in bitcoins because of the volatile exchange rate ==

The assumption is that bitcoins must be sold immediately to cover operating expenses. If the shopkeeper's back-end expenses were transacted in bitcoins as well, then the exchange rate would be irrelevant. Larger adoption of Bitcoin would make prices [http://en.wikipedia.org/wiki/Sticky_%28economics%29 sticky]. Future volatility is expected to decrease, as the size and depth of the market grows.

In the meantime, many merchants simply regularly pull the latest market rates from the exchanges and automatically update the prices on their websites. Also you might be able to buy a put option in order to sell at a fixed rate for a given amount of time. This would protect you from drops in price and simplify your operations for that time period.

== Like Flooz and e-gold, bitcoins serve as opportunities for criminals and will be shut down ==

* Visa, MasterCard, PayPal, and cash all serve as opportunities for criminals as well, but society keeps them around due to their recognized net benefit.
* Hopefully Bitcoin will grow to the point where no single organization can disrupt the network, or would be better served by helping it.
* Terrorists fly aircraft into buildings, but the governments have not yet abolished consumer air travel. Obviously the public good outweighs the possible bad in their opinion.
* Criminal law differs between jurisdictions.

== Bitcoins will be shut down by the government just like Liberty Dollars were ==

Liberty Dollars started as a commercial venture to establish an alternative US currency, including physical banknotes and coins, backed by precious metals. This, in and of itself, is not illegal. They were prosecuted under counterfeiting laws because the silver coins allegedly resembled US currency.

Bitcoins do not resemble the currency of the US or of any other nation in any way, shape, or form. The word "dollar" is not attached to them in any way. The "$" symbol is not used in any way.

Bitcoins have no representational similarity whatsoever to US dollars.

Of course, actually 'shutting down' Liberty Dollars was as easy as arresting the head of the company and seizing the offices and the precious metals used as backing. The decentralized Bitcoin, with no leader, no servers, no office, and no tangible asset backing, does not have the same vulnerability.

== Bitcoin is not decentralized because the developers can dictate the software's behavior ==

The Bitcoin protocol was originally defined by Bitcoin's inventor, [[Satoshi Nakamoto]], and this protocol has now been widely accepted as the standard by the community of miners and users.

Though the developers of the original Bitcoin client still exert influence over the Bitcoin community, their power to arbitrarily modify the protocol is very limited. Since the release of Bitcoin v0.3, changes to the protocol have been minor and always in agreement with community consensus.

Protocol modifications, such as increasing the block award from 25 to 50 BTC, are not compatible with clients already running in the network. If the developers were to release a new client that the majority of miners perceives as corrupt, or in violation of the project’s aims, that client would simply not catch on, and the few users who do try to use it would find that their transactions get rejected by the network.

There are also other [[:Category:Clients|Bitcoin clients made by other developers]] that adhere to the Bitcoin protocol. As more developers create alternative clients, less power will lie with the developers of the original Bitcoin client.

== Bitcoin is a pyramid scheme ==

Bitcoin is nearly opposite of a [[Wikipedia:Pyramid_scheme|pyramid scheme]] in a mathematical sense. Because Bitcoins are algorithmically made scarce, no exponential benefit is derived from introducing new users to use of it. There is a quantitative benefit in having additional interest or demand, but this is in no way exponential.<ref name="Jeff_Tucker" />

== Bitcoin was hacked ==

In the history of Bitcoin, there has never been an attack on the [[block chain]] that resulted in stolen money from a confirmed output. Neither has there ever been a reported theft resulting directly from a vulnerability in the [[Original Bitcoin client|original Bitcoin client]], or a vulnerability in the protocol. Bitcoin is secured by standard cryptographic functions. These functions have been peer reviewed by cryptography experts and are considered unlikely to be breakable in the foreseeable future.

It is safe to say that the currency itself has never been 'hacked'. However, several major ''websites'' using the currency have been hacked, often resulting in high profile Bitcoin heists. These heists are misreported in some media as hacks on Bitcoin itself. An analogy: Just because someone stole US dollars from a supermarket till, doesn’t mean that the US dollar as a currency has been 'hacked'.

Most bitcoin thefts are the result of inadequate [[Securing your wallet|wallet security]]. In response to the wave of thefts in 2011 and 2012, the community has developed risk-mitigating measures such as [[Wallet_encryption|wallet encryption]], support for [[BIP_0011|multiple signatures]], [[How_to_set_up_a_secure_offline_savings_wallet|offline wallets]], [[Paper_wallet|paper wallets]], and [[Hardware_wallet|hardware wallets]]. As these measures gain adoption by merchants and users, the number of thefts drop.

==References==
<references/>

[[de:Mythen]]
[[ru:Мифы о биткоине]]

P2sh

2017-09-21T18:33:25Z

JonathanCross: Redirect to Pay_to_script_hash

#REDIRECT [[Pay_to_script_hash]]

P2pkh

2017-09-21T18:31:00Z

JonathanCross: Adding redirect to Transaction#Pay-to-PubkeyHash

#REDIRECT [[Transaction#Pay-to-PubkeyHash]]

P2PKH

2017-09-21T18:29:48Z

JonathanCross: Adding redirect to Transaction#Pay-to-PubkeyHash

#REDIRECT [[Transaction#Pay-to-PubkeyHash]]

Wallet encryption

2017-09-17T10:36:33Z

JonathanCross: Updating link to Bitcoin Core's wallet.dat info

This page describes the algorithm used for encrypting the '''[[Wallet#Bitcoin_Core|wallet.dat]]''' file used in the original [[Bitcoin client]].

Wallet encryption uses [https://en.wikipedia.org/wiki/AES-256 AES-256-CBC] to encrypt only the private keys that are held in a wallet. The keys are encrypted with a master key
which is entirely random. This master key is then encrypted with
AES-256-CBC with a key derived from the passphrase using [https://en.wikipedia.org/wiki/SHA-512 SHA-512] and
OpenSSL's <code>EVP_BytesToKey</code> and a dynamic number of rounds determined by
the speed of the machine which does the initial encryption (and is
updated based on the speed of a computer which does a subsequent
passphrase change). Although the underlying code supports multiple
encrypted copies of the same master key (and thus multiple passphrases)
the client does not yet have a method to add additional passphrases.

At runtime, the client loads the wallet as it normally would, however
the keystore stores the keys in encrypted form. When the passphrase
is required (to top up keypool or send coins) it will either be queried
by a GUI prompt, or must first be entered with the <code>walletpassphrase</code>
[[Original_Bitcoin_client/API_calls_list#Full_list|RPC command]]. This will change the wallet to "unlocked" state where the
unencrypted master key is stored in memory (in the case of GUI, only for
long enough to complete the requested operation, in RPC, for as long as
is specified by the second parameter to <code>walletpassphrase</code>). The wallet is
then locked (or can be manually locked using the <code>walletlock</code> RPC command)
and the unencrypted master key is removed from memory.

== Implementation details of wallet encryption ==

When the wallet is locked, calls to <code>sendtoaddress</code>, <code>sendfrom</code>, <code>sendmany</code>, and <code>keypoolrefill</code> will return ''Error -13: "Error: Please enter the wallet passphrase with walletpassphrase first."''

When the wallet is unlocked, calls to <code>walletpassphrase</code> will fail.

When a wallet is encrypted, the passphrase is required to top up the
keypool, thus, if the passphrase is rarely entered, it is possible that
keypool might run out. In this case, the default key will be used as the
target for payouts for mining, and calls to <code>getnewaddress</code> and <code>getaccount</code>
address will return an error. In order to prevent such cases, the keypool
is automatically refilled when <code>walletpassphrase</code> is called with a correct
passphrase and when <code>topupkeypool</code> is called (while the wallet is unlocked).
Note that the keypool continues to be topped up on various occasions when
a new key from pool is used and the wallet is unlocked (or unencrypted).

When wallet passphrase enrcyption becomes enabled, any unused keys from the keypool are flushed (marked as used) and new keys protected with encyption are added. For this reason, make a new backup of your wallet so that you will be able to recover the keys from the new key pool should access to your backups be necessary.

[[Category:Technical]]

Wallet

2017-09-17T10:35:05Z

JonathanCross: /* Bitcoin Core */ Linking to wallet encryption info

A Bitcoin '''wallet''' is a collection of private keys but may also refer to [[Clients|client software]] used to manage those keys and to make transactions on the Bitcoin network.

This page covers various wallet formats in use.

=== [[Bitcoin Core]] ===

The original Bitcoin client stores private key information in a file named '''wallet.dat''' following the so called [https://bitcointalk.org/index.php?topic=4448.0 "bitkeys"] format.

It contains:

* keypairs for each of your [[address|addresses]]
* transactions done from/to your addresses
* user preferences
* default key
* reserve keys
* [[Accounts_explained|accounts]]
* a version number
* [[Key pool]]
* Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.

The wallet.dat file is located in the [[data directory|Bitcoin data directory]] and may be [[Wallet_encryption|encrypted with a password]].

It is intended that a wallet file be used on only one installation of Bitcoin at a time. Attempting to clone a wallet file for use on multiple computers will result in "weird behavior"<ref>[http://forum.bitcoin.org/index.php?topic=5324.msg77896#msg77896 Multiple instance of bitcoin with the same wallet]</ref>.

The format of this file is Berkeley DB. Tools that can manipulate wallet files include [[pywallet]].

=== [[Armory]] ===

The Armory client uses a custom [[Deterministic wallet]] format [https://www.bitcoinarmory.com/wallet-format/ described here] and runs on top of [[Bitcoin Core]].

=== [[Blockchain.info#Wallet|Blockchain.info]] ===

Blockchain.info offers a [[Browser-based_wallet#Hybrid_e-wallets|hybrid eWallet]] called "My Wallet". It use a plain text [https://blockchain.info/wallet/wallet-format JSON wallet format]. Private keys Keys are stored in base58.

=== [[Denarium.com]] ===

Denarium is Physical Bitcoin coin manufacturer. Denarium produces easy, handy and secure wallets in a coin form. The private key is stored under a security seal without password protection. Denarium also offers a trustless multisignature coins, which eliminates the need to trust the manufacturer.

=== [[Ledger Wallet]] ===

Ledger Wallet manufactures various hardware wallets.

=== [[Multibit]] ===

Multibit HD (the current version) uses a [[BIP 0032]] (type 2) [[Deterministic wallet]] with the [https://www.multibit.org/en/help/hd0.1/files.html format described here]. The "Classic" version used the bitcoinj [https://github.com/google/protobuf protobuf] wallet file.

=== [[Blocktrail]] ===

Blocktrail offers a [[BIP 0032]] (type 2) [[Deterministic wallet]] and for added security also implements [[Multisignature]] wallet technology.

=== [[TREZOR]] ===

TREZOR is an isolated hardware environment for offline transaction signing and using a small display you can visually verify the transaction contents.

=== [https://opendime.com Opendime] ===

Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times. Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.

==See Also==

* [[Transaction fees]]
* [[Securing your wallet]]
* [[EWallet]]
* [[Deterministic Wallet]]
* [https://bitcoin.org/en/choose-your-wallet Choose your wallet]

==References==
<references />

BIP 0038

2017-05-14T17:44:41Z

JonathanCross: Updating

<pre>
BIP: 38
Layer: Applications
Title: Passphrase-protected private key
Author: Mike Caldwell <mcaldwell@swipeclock.com>
Aaron Voisine <voisine@gmail.com>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0038
Status: Draft (Some confusion applies: The announcements for this never made it to the list, so it hasn't had public discussion)
Type: Standards Track
Created: 2012-11-20
License: PD
</pre>

{{BipMoved|bip-0038.mediawiki}}

[[Category: BIP]]

BIP 0043

2017-05-14T17:43:10Z

JonathanCross: Updating

{{bip}}

<pre>
BIP: 43
Layer: Applications
Title: Purpose Field for Deterministic Wallets
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043
Status: Draft
Type: Informational
Created: 2014-04-24
</pre>

{{BipMoved|bip-0043.mediawiki}}

BIP 0044

2017-05-14T17:41:24Z

JonathanCross: Updating

{{bip}}

<pre>
BIP: 44
Layer: Applications
Title: Multi-Account Hierarchy for Deterministic Wallets
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Comments-Summary: Mixed review (one person)
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0044
Status: Proposed
Type: Standards Track
Created: 2014-04-24
</pre>

{{BipMoved|bip-0044.mediawiki}}

BIP 0039

2017-05-14T17:40:24Z

JonathanCross: Updating

{{bip}}

<pre>
BIP: 39
Layer: Applications
Title: Mnemonic code for generating deterministic keys
Author: Marek Palatinus <slush@satoshilabs.com>
Pavol Rusnak <stick@satoshilabs.com>
Aaron Voisine <voisine@gmail.com>
Sean Bowe <ewillbefull@gmail.com>
Comments-Summary: Unanimously Discourage for implementation
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0039
Status: Proposed
Type: Standards Track
Created: 2013-09-10
</pre>

{{BipMoved|bip-0039.mediawiki}}

BIP 0032

2017-05-14T17:39:08Z

JonathanCross: Updating

{{bip}}

RECENT CHANGES:
* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
* (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)
* (30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation)
* (25 May 2013) Added test vectors
* (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.

<pre>
BIP: 32
Layer: Applications
Title: Hierarchical Deterministic Wallets
Author: Pieter Wuille <pieter.wuille@gmail.com>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032
Status: Final
Type: Informational
Created: 2012-02-11
License: BSD-2-Clause
</pre>

{{BipMoved|bip-0032.mediawiki}}

BIP 0009

2017-05-14T17:36:36Z

JonathanCross: Creating BIP 9

{{bip}}

<pre>
BIP: 9
Title: Version bits with timeout and delay
Author: Pieter Wuille <pieter.wuille@gmail.com>
Peter Todd <pete@petertodd.org>
Greg Maxwell <greg@xiph.org>
Rusty Russell <rusty@rustcorp.com.au>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009
Status: Final
Type: Informational
Created: 2015-10-04
License: PD
</pre>

{{BipMoved|bip-0009.mediawiki}}

BIP 0002

2017-05-14T17:35:03Z

JonathanCross: Updating Preamble

{{bip}}

<pre>
BIP: 2
Title: BIP process, revised
Author: Luke Dashjr <luke+bip@dashjr.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002
Status: Active
Type: Process
Created: 2016-02-03
License: BSD-2-Clause
OPL
Replaces: 1
</pre>

{{BipMoved|bip-0002.mediawiki}}

[[Category:BIP|D]]

BIP 0001

2017-05-14T17:32:14Z

JonathanCross: Reformatting to match other BIPs and adding note about BIP 2.

{{bip}}

<pre>
BIP: 1
Title: BIP Purpose and Guidelines
Author: Amir Taaki <genjix@riseup.net>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
Status: Replaced
Type: Process
Created: 2011-08-19
Superseded-By: 2
</pre>

{{BipMoved|bip-0001.mediawiki}}

=== Notes ===

This BIP has been superseded by [[BIP_0002|BIP 2]].

Segregated Witness

2017-05-14T17:22:55Z

JonathanCross: /* See Also */ Adding BIP 173

{{stub}}

'''Segregated Witness''' (aka "SegWit") defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.

==See Also==

* [[BIP_0141|BIP 141]] Segregated Witness (Consensus layer)
* [[BIP_0143|BIP 143]] Transaction Signature Verification for Version 0 Witness Program
* [[BIP_0144|BIP 144]] Segregated Witness (Peer Services)
* [[BIP_0145|BIP 145]] getblocktemplate Updates for Segregated Witness
* [[BIP_0147|BIP 147]] Dealing with dummy stack element malleability
* [[BIP_0173|BIP 173]] Base32 address format for native v0-16 witness outputs
* [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segregated Witness Benefits]

BIP 0173

2017-05-14T17:22:12Z

JonathanCross: Creating BIP_173

{{bip}}

<pre>
BIP: 173
Layer: Applications
Title: Base32 address format for native v0-16 witness outputs
Author: Pieter Wuille <pieter.wuille@gmail.com>
Greg Maxwell <greg@xiph.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173
Status: Draft
Type: Informational
Created: 2016-03-20
License: BSD-2-Clause
Replaces: 142
</pre>

{{BipMoved|bip-0173.mediawiki}}

BIP 0147

2017-05-14T17:15:46Z

JonathanCross: Adding landing page for bip-0147

{{bip}}

<pre>
BIP: 147
Layer: Consensus (soft fork)
Title: Dealing with dummy stack element malleability
Author: Johnson Lau <jl2012@xbt.hk>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147
Status: Draft
Type: Standards Track
Created: 2016-09-02
License: PD
</pre>

{{BipMoved|bip-0147.mediawiki}}

Lightning Network

2017-05-14T17:11:05Z

JonathanCross: Linking segwit

'''Lightning Network''' is a proposed implementation of [[Hashed Timelock Contracts]] (HTLCs) with bi-directional [[payment channels]] which allows payments to be securely routed across multiple peer-to-peer payment channels.<ref name="ln_pdf">[https://lightning.network/lightning-network-paper.pdf Lightning Network paper, v0.5.9.1] Joseph Poon & Thaddeus Dryja ''Retrieved 2016-04-10''</ref> This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.

== Key features ==
Key features of the Lightning Network proposal include,

* '''Rapid payments:''' payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.
* '''No third-party trust:''' the two peers in a channel pay each other directly using regular Bitcoin transactions (of which only one is broadcast) so at no point does any third party control their funds.
* '''Reduced blockchain load:''' only channel open transactions, channel close transactions, and (hopefully infrequent) anti-fraud respends need to be committed to the blockchain, allowing all other payments within Lightning Network channels to remain uncommitted. This allows Lightning Network users to make frequent payments secured by Bitcoin without placing excessive load on full nodes which must process every transaction on the blockchain.
* '''Channels can stay open indefinitely:''' as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.
* '''Rapid cooperative closes:''' if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.
* '''Outsourcable enforcement:''' if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
* '''Onion-style routing:''' payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).
* '''Multisignature capable:''' each party can require that their payments into the channel be signed by multiple keys<ref name="poon_multisig">[https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html 2-of-3 Instant Escrow, or How to Do "2-of-3 Multisig Contract" Equivilant on Lightning] Joseph Poon ''Retrieved 2016-04-11''</ref>, giving them access to additional security techniques.
* '''Securely cross blockchains:''' payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.
* '''Sub-satoshi payments:''' payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.<ref name="dryja_directed_graph"/> For example, Alice can pay Bob 0.1 satoshi by creating a 1-satoshi payment with 10-to-1 odds so that 90% of the time she does this she pays him 0 satoshis and 10% of the time she pays him 1 satoshi for an average payment of 0.1 satoshis.
* '''Single-funded channels:''' when Alice needs to send a payment to Bob and doesn't currently have a way to pay him through the Lightning Network (whether because she can't reach him or because she doesn't have enough money in an existing channel), she can make a regular on-chain payment that establishes a channel without Bob needing to add any of his funds to the channel. Alice only uses 12 bytes more than she would for a non-Lightning direct payment and Bob would only need about 25 more [[segwit]] virtual bytes to close the channel than he would had he received a non-Lightning direct payment.<ref name="dryja_directed_graph"/>

== Glossary ==

This section attempts to document the most frequently used terms found in Lightning Network literature that may not be familiar to a general technical audience, including both the new terms created by Lightning Network designers as well as pre-existing terms that may not be well known from Bitcoin, cryptography, network routing, and other fields.

The list below should be in alphabetical order. Any commonly-used synonyms or analogs for a term are placed in parenthesis after the term.

* '''Bi-directional payment channel:'''<ref name="ln_pdf"/> a payment channel where payments can flow both directions, from Alice to Bob and back to Alice. This is contrasted with Spillman-style and CLTV-style payment channels where payments can only go one direction and once Alice has paid Bob all of the bitcoins she deposited in the channel funding transaction, the channel is no longer useful and so will be closed.
* '''Breach Remedy Transaction:'''<ref name="ln_pdf"/> the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using <code>OP_CSV</code>. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).
* '''Channel''' (Lightning channel<ref name="ln_pdf"/>, payment channel<ref name="spillman_channel">[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html Anti DoS for tx replacement] Jeremy Spillman Retrieved 2016-04-17</ref>) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.
* '''Commitment Transaction:'''<ref name="ln_pdf"/> a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The '''Initial Commitment Transaction'''<ref name="ln_pdf"/> is the first of these transactions; it records the inital balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a ''funding transaction'' for a new channel under the cooperative conditions necessary to create an ''exercise settlement transaction''.
* '''Contract:'''<ref name="szabo_smart_contracts">[http://szabo.best.vwh.net/smart_contracts_idea.html The Idea of Smart Contracts] Nick Szabo Retrieved 2016-04-17</ref> an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a ''smart contract''.
* '''CSV:''' (<code>OP_CheckSequenceVerify</code>, <code>OP_CSV</code>)<ref name="bip68"/> a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See ''relative locktime.''
* '''Delivery Transaction:'''<ref name="ln_pdf"/> not really a transaction but rather the name for the outputs in the ''commitment transaction'' which Alice and Bob receive if one of them closes the channel unilaterally in the correct (current) state. If the channel is closed in an old state (indicating possible fraud), a ''breach remedy transaction'' will be generated from the output that would have paid the party closing the channel. If the channel is closed cooperatively, they'll create an ''exercise settlement transaction'' instead.
* '''Dispute period:''' (dispute resolution period<ref name="poon_time_bitcoin_ln">[https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf Time, Bitcoin, and the Lightning Network] Joseph Poon Retrieved 2016-04-17</ref>) the period of time that Alice has to get her ''breach remedy transaction'' added to the blockchain after Mallory has an old ''commitment transaction'' added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.
* '''Dual-funded channel:'''<ref name="dryja_directed_graph">[https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_2 LN as a Directed Graph: Single-Funded Channel Topology] Thaddeus Dryja Retrieved 2016-04-17</ref> a channel opened by a ''funding transaction'' containing inputs from both Alice and Bob. Compare to a ''single-funded channel'' where only Alice's inputs contribute to the balance of the channel.
* '''Encumbrance:'''<ref>[http://chimera.labs.oreilly.com/books/1234000001802/ch02.html Mastering Bitcoin, Chapter 2: How Bitcoin Works] Andreas Antonopoulos Retrieved 2016-04-17</ref> a generic name for any conditions that must be satisfied before a bitcoin output may be spent. Early Bitcoin transactions placed all their conditions in the scriptPubKey; later the introduction of P2SH allowed conditions to be added in a redeemScript which the scriptPubKey committed to; the introduction of soft fork [[segwit]] will add a similar mechanism for detached conditions that the scriptPubKey commits to; in addition, there are even more novel ways to add conditions to outputs that are discussed but rarely used. The term "encumbrance" allows specifying what the conditions do without fussing over exactly where the conditions appear in a serialized transaction.
* '''Exercise Settlement Transaction:'''<ref name="ln_pdf"/> a form of the ''commitment transaction'' created cooperatively by Alice and Bob when they want to close their channel together. Unlike a regular commitment transaction, none of the outputs on an exercise settlement transaction are time locked, allowing them to be immediately respent.
* '''Exhausted:'''<ref name="dryja_directed_graph"/> (exhausted channel) a payment channel where no additional payments can be made in one direction (such as from Alice to Bob). The person controlling the exhausted side of a Lightning channel loses nothing from fraudulently trying to commit an old channel state, so allowing a channel to become exhausted (or too near to being exhausted) is unpreferable. (Exception: channels can be securely started in an exhausted state, such as a ''single-funded channel.''
* '''Full push:'''<ref name="dryja_directed_graph"/> when Alice pays the full amount of the channel to Bob in the ''initial commitment transaction'', which ''exhausts'' the channel without incentivizing fraud because Alice doesn't have a previous ''commitment transaction'' that she can broadcast. This term is used in the context of a ''single-funded transaction'' and stands in contrast to an ''overpayment'' where Alice deposits more than she pays Bob in that initial payment so that she can continue to use the channel without needing to ''rebalance''.
* '''Funding Transaction:'''<ref name="ln_pdf"/> (deposit transaction) a transaction created collaboratively by Alice and Bob to open a Lightning channel. In a single-funded channel, Alice provides all the funding;<ref name="dryja_directed_graph"/> in a dual-funded channel, Alice and Bob both provide some funding. This is the first of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a commitment transaction from a previous channel being closed under cooperative conditions.
* '''Half-signed:'''<ref name="ln_pdf"/> a transaction input which requires two signatures to be added to the blockchain but which only has one signature attached. (More generally, this could be any input that has fewer signatures attached than it needs to be added to the blockchain.)
* '''Hash lock:'''<ref>[https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05135.html BIP - Hash Locked Transaction] Tier Nolan Retrieved 2016-04-17</ref> an encumbrance to a transaction output that requires the pre-image used to generate a particular hash be provided in order to spend the output. In Lightning, this is used to allow payments to be routable without needing to trust the intermediaries.
* '''HTLC:''' (Hashed Timelocked Contract<ref name="russell_deployable_lightning">[https://github.com/ElementsProject/lightning/raw/master/doc/deployable-lightning.pdf Reaching the Ground with Lightning] Rusty Russell Retrieved 2016-04-17</ref>) a contract such as that used in a Lightning Channel where both a ''hash lock'' and a ''time lock'' are used, the hash lock being used to allow Alice to route payments to Bob even through a Mallory that neither of them trust, and the time lock being used to prevent Mallory from stealing back any payments he made to Alice within the channel (provided Alice enforces the contract).
* '''Intermediary:'''<ref name="ln_pdf"/> When Bob has one channel open with Alice and another channel open with Charlie, Bob can serve as an intermediary for transferring payments between Alice and Charlie. With Lightning payments being secured with a ''hash lock,'' Bob can't steal the payment from Alice to Charlie when it travels through Bob's node. Lightning payments can securely travel through a theoretically unlimited number of intermediaries.
* '''Limbo channel:'''<ref name="dryja_directed_graph"/> an optional special state for a Lightning channel where it cannot be immediately closed by one or both of the parties unilaterally (it can still be immediately closed cooperatively). This is used in particular for ''PLIPPs.''
* '''Multisig:'''<ref name="bitcoin_0_1_code"/> (multisignature, m-of-n multisig) a transaction output that requires signatures from at least one of a set of two or more different private keys. Used in Lightning to give both Alice and Bob control over their individual funds within a channel by requiring both of them sign ''commitment transactions''.
* '''Node:''' (Lightning node<ref name="ln_pdf"/>) a wallet with one or more open Lightning channels. This should not be confused with a Bitcoin [[full node]] that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user.
* '''Overfunding:'''<ref name="dryja_directed_graph"/> in a ''single-funded channel,'' Alice deposits more bitcoins into the channel than she pays Bob in the initial payment, allowing her to make additional payments through the Lightning network. This stands in contrast to a ''full push'' where Alice only deposits enough to pay Bob in the initial payment.
* '''PILPP:''' (Pre-Image Length Probabilistic Payments<ref name="dryja_directed_graph"/>) a specific type of ''probabilistic payment'' within a payment channel where Alice creates string with a random length and Bob guesses the length; if he guesses correctly, Alice has to pay him; if he guesses incorrectly, Alice gets to keep her money.
* '''Pre-image:'''<ref>[https://en.wikipedia.org/wiki/Image_%28mathematics%29#Inverse_image Image (mathematics)] English Wikipedia contributors Retrieved 2016-04-17</ref> (R<ref name="ln_pdf"/>) data input into a hash function, which produces a hash of the pre-image. Inputting the same pre-image into the same hash function will always produce the same hash; Lightning uses this feature to create ''hash locks''.
* '''Probabilistic Payment:'''<ref>[[Nanopayments]] Bitcoin Wiki contributors Retrieved 2016-04-17</ref> a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See ''PLIPP'' for a specific type of probabilistic payment possible within a Lightning channel.
* '''R:''' the variable commonly used<ref name="ln_pdf"/> in formulas to represent a ''pre-image''.
* '''Rebalance:'''<ref>[https://blockstream.com/2015/09/01/lightning-network/ The Lightning Network: What Is It and What's Happening?] Rusty Russell Retrieved 2016-04-17</ref> a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See ''bi-directional payment channels.''
* '''Relative locktime:'''<ref name="bip68"/> the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure ''breach remedy transactions'' may be broadcast within a time period starting from when an old ''commitment transaction'' is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.
* '''Revocable Sequence Maturity Contract (RSMC):'''<ref name="ln_pdf"/> a ''contract'' used in Lightning to revoke the previous ''commitment transaction''. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create ''breach remedy transactions'' for the previous commitment transaction. This property allows Lightning to support ''bi-directional payment channels'', recover from failed ''HTLC'' routing attempts without needing to commit to the blockchain, as well as provide advanced features such as ''PILPPs.''
* '''Single-funded channel:'''<ref name="dryja_directed_graph"/> a channel opened by a ''funding transaction'' containing only inputs from Alice. Compare to a ''dual-funded channel'' where Alice and Bob both contribute inputs to the initial balance of the channel.
* '''Timelock:'''<ref>[http://rusty.ozlabs.org/?p=450 Lightning Networks Part I: Revocable Transactions] Rusty Russell 2016-04-17</ref> either an encumbrance to a transaction that prevents that transaction from being added to the blockchain before a particular time or block height (as is the case with [[nLockTime]], or an encumbrance that prevents a spend from a transaction output from being added to the blockchain before a particular time or block height (as is the case of OP_CLTV, consensus enforced sequence number relative locktime, and OP_CSV). In Lightning, this is used to prevent malicious intermediaries from holding other users' funds hostages as well as to allow victims of attempted theft to submit breach remedy transactions before the thief can respend the funds he stole.
* '''TTL:''' (Time To Live<ref>[http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000019.html Re: Routing on the Lightning Network?] Rusty Russell Retrieved 2016-04-17</ref>) when Alice pays Bob with a ''hash locked'' in-channel payment that's ultimately intended for Charlie, she specifies how long Bob has to deliver the payment (its time to live) before the payment becomes invalid. When Bob pays Charlie with his own in-channel payment that has the same hash lock, Bob specifies a slightly shorter amount of time that Charlie has to reveal the pre-image that unlocks the hash lock before Bob's payment becomes invalid. This ensures that either Bob receives the data necessary to remove the hash lock from the payment he received from Alice or the payment he made to Charlie is invalidated; Alice gets the same guarantee that either the payment she made to Bob ultimate goes through to Charlie or her payment to Bob is invalidated.
* '''Unilateral:'''<ref name="ln_pdf"/> any action performed by only one of the participants in a channel without requesting or needing permission from the other participant. Lightning allows channels to be closed unilaterally (so Alice can close the channel by herself if Bob becomes unresponsive) and attempted fraud can be penalized unilaterally (so Alice can take any bitcoins Mallory tried to steal when he broadcast an old ''commitment transaction'').
* '''UTXO:'''<ref>[https://bitcoin.org/en/glossary/unspent-transaction-output Unspent Transaction Output (UTXO)] Bitcoin.org Developer Glossary Retrieved 2016-04-17</ref> (Unspent Transaction Output) spendable bitcoins. A transaction output lists a bitcoin amount and the conditions (called an ''encumbrance'') that need to be fulfilled in order to spend those bitcoins. Once those bitcoins have been spent on the blockchain, no other transaction in the same blockchain can spend the same bitcoins, so an Uspent Transaction Output (UTXO) is bitcoins that can be spent.

== References ==
<references>
<ref name="bitcoin_0_1_code">[http://satoshi.nakamotoinstitute.org/code/ Bitcoin 0.1 code] Satoshi Nakamoto Retrieved 2016-04-11</ref>
<ref name="bip68">[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers] Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona Retrieved 2016-04-12</ref>
<references/>

Running Bitcoin

2017-05-14T17:10:21Z

JonathanCross: Linking segwit

There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin”), and a 'headless' version (called [[bitcoind]]). They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files. You can run one copy of either Bitcoin or bitcoind on your system at a time (if you accidently try to launch another, the copy will let you know that Bitcoin or bitcoind is already running and will exit).

__TOC__

==Linux Quickstart==

The simplest way to start from scratch with the command line client, automatically syncing blockchain and creating a wallet, is to just run this command (without arguments) from the directory containing your bitcoind binary:

./bitcoind

To run with the standard GUI interface:

./bitcoin-qt

==Command-line arguments==

These commands are accurate as of Bitcoin Core version '''v0.14.0'''.

{| style="valign:top;"
! scope="col" style="width: 20pt;border: 0px" |
! scope="col" style="width: 150pt;" | Command
! scope="col" | Description
|-
| || -? || Print this help message and exit
|-
| || -version || Print version and exit
|-
| || -alertnotify=<cmd> || Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message)
|-
| || -blocknotify=<cmd> || Execute command when the best block changes (%s in cmd is replaced by block hash)
|-
| || -assumevalid=<hex> || If this block is in the chain assume that it and its ancestors are valid and potentially skip their script verification (0 to verify all, default: 00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90, testnet: 00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc)
|-
| || -conf=<file> || Specify configuration file (default: bitcoin.conf)
|-
| || -datadir=<dir> || Specify data directory
|-
| || -dbcache=<n> || Set database cache size in megabytes (4 to 16384, default: 300)
|-
| || -loadblock=<file> || Imports blocks from external blk000??.dat file on startup
|-
| || -maxorphantx=<n> || Keep at most <n> unconnectable transactions in memory (default: 100)
|-
| || -maxmempool=<n> || Keep the transaction memory pool below <n> megabytes (default: 300)
|-
| || -mempoolexpiry=<n> || Do not keep transactions in the mempool longer than <n> hours (default: 336)
|-
| || -blockreconstructionextratxn=<n> || Extra transactions to keep in memory for compact block reconstructions (default: 100)
|-
| || -par=<n> || Set the number of script verification threads (-2 to 16, 0 = auto, <0 = leave that many cores free, default: 0)
|-
| || -pid=<file> || Specify pid file (default: bitcoind.pid)
|-
| || -prune=<n> || Reduce storage requirements by enabling pruning (deleting) of old blocks. This allows the pruneblockchain RPC to be called to delete specific blocks, and enables automatic pruning of old blocks if a target size in MiB is provided. This mode is incompatible with -txindex and -rescan. Warning: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, >550 = automatically prune block files to stay under the specified target size in MiB)
|-
| || -reindex-chainstate || Rebuild chain state from the currently indexed blocks
|-
| || -reindex || Rebuild chain state and block index from the blk*.dat files on disk
|-
| || -sysperms || Create new files with system default permissions, instead of umask 077 (only effective with disabled wallet functionality)
|-
| || -txindex || Maintain a full transaction index, used by the getrawtransaction rpc call (default: 0)
|-
|-
| colspan="3" | '''Connection options:'''
|-
| || -addnode=<ip> || Add a node to connect to and attempt to keep the connection open
|-
| || -banscore=<n> || Threshold for disconnecting misbehaving peers (default: 100)
|-
| || -bantime=<n> || Number of seconds to keep misbehaving peers from reconnecting (default: 86400)
|-
| || -bind=<addr> || Bind to given address and always listen on it. Use [host]:port notation for IPv6
|-
| || -connect=<ip> || Connect only to the specified node(s); -noconnect or -connect=0 alone to disable automatic connections
|-
| || -discover || Discover own IP addresses (default: 1 when listening and no -externalip or -proxy)
|-
| || -dns || Allow DNS lookups for -addnode, -seednode and -connect (default: 1)
|-
| || -dnsseed || Query for peer addresses via DNS lookup, if low on addresses (default: 1 unless -connect/-noconnect)
|-
| || -externalip=<ip> || Specify your own public address
|-
| || -forcednsseed || Always query for peer addresses via DNS lookup (default: 0)
|-
| || -listen || Accept connections from outside (default: 1 if no -proxy or -connect/-noconnect)
|-
| || -listenonion || Automatically create Tor hidden service (default: 1)
|-
| || -maxconnections=<n> || Maintain at most <n> connections to peers (default: 125)
|-
| || -maxreceivebuffer=<n> || Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
|-
| || -maxsendbuffer=<n> || Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
|-
| || -maxtimeadjustment || Maximum allowed median peer time offset adjustment. Local perspective of time may be influenced by peers forward or backward by this amount. (default: 4200 seconds)
|-
| || -onion=<ip:port> || Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)
|-
| || -onlynet=<net> || Only connect to nodes in network <net> (ipv4, ipv6 or onion)
|-
| || -permitbaremultisig || Relay non-P2SH multisig (default: 1)
|-
| || -peerbloomfilters || Support filtering of blocks and transaction with bloom filters (default: 1)
|-
| || -port=<port> || Listen for connections on <port> (default: 8333 or testnet: 18333)
|-
| || -proxy=<ip:port> || Connect through SOCKS5 proxy
|-
| || -proxyrandomize || Randomize credentials for every proxy connection. This enables Tor stream isolation (default: 1)
|-
| || -rpcserialversion || Sets the serialization of raw transaction or block hex returned in non-verbose mode, non-segwit(0) or [[segwit]](1) (default: 1)
|-
| || -seednode=<ip> || Connect to a node to retrieve peer addresses, and disconnect
|-
| || -timeout=<n> || Specify connection timeout in milliseconds (minimum: 1, default: 5000)
|-
| || -torcontrol=<ip>:<port> || Tor control port to use if onion listening enabled (default: 127.0.0.1:9051)
|-
| || -torpassword=<pass> || Tor control port password (default: empty)
|-
| || -upnp=<pass> || Use UPnP to map the listening port (default: 0)
|-
| || -whitebind=<addr> || Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
|-
| || -whitelist=<IP address or network> || Whitelist peers connecting from the given IP address (e.g. 1.2.3.4) or CIDR notated network (e.g. 1.2.3.0/24). Can be specified multiple times. Whitelisted peers cannot be DoS banned and their transactions are always relayed, even if they are already in the mempool, useful e.g. for a gateway
|-
| || -whitelistrelay || Accept relayed transactions received from whitelisted peers even when not relaying transactions (default: 1)
|-
| || -whitelistforcerelay || Force relay of transactions from whitelisted peers even if they violate local relay policy (default: 1)
|-
| || -maxuploadtarget=<n> || Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit (default: 0)
|-
|-
| colspan="3" | '''Wallet options:'''
|-
| || -disablewallet || Do not load the wallet and disable wallet RPC calls
|-
| || -keypool=<n> || Set key pool size to <n> (default: 100)
|-
| || -fallbackfee=<amt> || A fee rate (in BTC/kB) that will be used when fee estimation has insufficient data (default: 0.0002)
|-
| || -mintxfee=<amt> || Fees (in BTC/kB) smaller than this are considered zero fee for transaction creation (default: 0.00001)
|-
| || -paytxfee=<amt> || Fee (in BTC/kB) to add to transactions you send (default: 0.00)
|-
| || -rescan || Rescan the block chain for missing wallet transactions on startup
|-
| || -salvagewallet || Attempt to recover private keys from a corrupt wallet on startup
|-
| || -spendzeroconfchange || Spend unconfirmed change when sending transactions (default: 1)
|-
| || -txconfirmtarget=<n> || If paytxfee is not set, include enough fee so transactions begin confirmation on average within n blocks (default: 6)
|-
| || -usehd || Use hierarchical deterministic key generation (HD) after BIP32. Only has effect during wallet creation/first start (default: 1)
|-
| || -walletrbf || Send transactions with full-RBF opt-in enabled (default: 0)
|-
| || -upgradewallet || Upgrade wallet to latest format on startup
|-
| || -wallet=<file> || Specify wallet file (within data directory) (default: wallet.dat)
|-
| || -walletbroadcast || Make the wallet broadcast transactions (default: 1)
|-
| || -walletnotify=<cmd> || Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
|-
| || -zapwallettxes=<mode> || Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup (1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
|-
|-
| colspan="3" | '''ZeroMQ notification options:'''
|-
| || -zmqpubhashblock=<address> || Enable publish hash block in <address>
|-
| || -zmqpubhashtx=<address> || Enable publish hash transaction in <address>
|-
| || -zmqpubrawblock=<address> || Enable publish raw block in <address>
|-
| || -zmqpubrawtx=<address> || Enable publish raw transaction in <address>
|-
|-
| colspan="3" | '''Debugging/Testing options:'''
|-
| || -uacomment=<cmt> || Append comment to the user agent string
|-
| || -debug=<category> || Output debugging information (default: 0, supplying <category> is optional). If <category> is not supplied or if <category> = 1, output all debugging information.<category> can be: addrman, alert, bench, cmpctblock, coindb, db, http, libevent, lock, mempool, mempoolrej, net, proxy, prune, rand, reindex, rpc, selectcoins, tor, zmq, qt.
|-
| || -help-debug || Show all debugging options (usage: --help -help-debug)
|-
| || -logips || Include IP addresses in debug output (default: 0)
|-
| || -logtimestamps || Prepend debug output with timestamp (default: 1)
|-
| || -minrelaytxfee=<amt> || Fees (in BTC/kB) smaller than this are considered zero fee for relaying, mining and transaction creation (default: 0.00001)
|-
| || -maxtxfee=<amt> || Maximum total fees (in BTC) to use in a single wallet transaction or raw transaction; setting this too low may abort large transactions (default: 0.10)
|-
| || -printtoconsole || Send trace/debug info to console instead of debug.log file
|-
| || -shrinkdebugfile || Shrink debug.log file on client startup (default: 1 when no -debug)
|-
|-
| colspan="3" | '''Chain selection options:'''
|-
| || -testnet || Use the test chain
|-
|-
| colspan="3" | '''Node relay options:'''
|-
| || -bytespersigop || Equivalent bytes per sigop in transactions for relay and mining (default: 20)
|-
| || -datacarrier || Relay and mine data carrier transactions (default: 1)
|-
| || -datacarriersize || Maximum size of data in data carrier transactions we relay and mine (default: 83)
|-
| || -mempoolreplacement || Enable transaction replacement in the memory pool (default: 1)
|-
|-
| colspan="3" | '''Block creation options:'''
|-
| || -blockmaxweight=<n> || Set maximum BIP141 block weight (default: 3000000)
|-
| || -blockmaxsize=<n> || Set maximum block size in bytes (default: 750000)
|-
| || -blockprioritysize=<n> || Set maximum size of high-priority/low-fee transactions in bytes (default: 0)
|-
| || -blockmintxfee=<amt> || Set lowest fee rate (in BTC/kB) for transactions to be included in block creation. (default: 0.00001)
|-
|-
| colspan="3" | '''RPC server options:'''
|-
| || -server || Accept command line and JSON-RPC commands
|-
| || -rest || Accept public REST requests (default: 0)
|-
| || -rpcbind=<addr> || Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)
|-
| || -rpccookiefile=<loc> || Location of the auth cookie (default: data dir)
|-
| || -rpcuser=<user> || Username for JSON-RPC connections
|-
| || -rpcpassword=<pw> || Password for JSON-RPC connections
|-
| || -rpcauth=<userpw> || Username and hashed password for JSON-RPC connections. The field <userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A canonical python script is included in share/rpcuser. The client then connects normally using the rpcuser=<USERNAME>/rpcpassword=<PASSWORD> pair of arguments. This option can be specified multiple times
|-
| || -rpcport=<port> || Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
|-
| || -rpcallowip=<ip> || Allow JSON-RPC connections from specified source. Valid for <ip> are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified multiple times
|-
| || -rpcthreads=<n> || Set the number of threads to service RPC calls (default: 4)
|-
|-
| colspan="3" | '''UI Options:'''
|-
| || -choosedatadir || Choose data directory on startup (default: 0)
|-
| || -lang=<lang> || Set language, for example "de_DE" (default: system locale)
|-
| || -min || Start minimized
|-
| || -rootcertificates=<file> || Set SSL root certificates for payment request (default: -system-)
|-
| || -splash || Show splash screen on startup (default: 1)
|-
| || -resetguisettings || Reset all settings changed in the GUI
|}

Many of the boolean options can also be set to off by specifying them with a "no" prefix: e.g. -nodnseed.

==Bitcoin.conf Configuration File==
All command-line options (except for -conf) may be specified in a configuration file, and all configuration file options may also be specified on the command line. Command-line options override values set in the configuration file.

The configuration file is a list of setting=value pairs, one per line, with optional comments starting with the '#' character.

The configuration file is not automatically created; you can create it using your favorite plain-text editor. A user-friendly configuration file generator is [https://jlopp.github.io/bitcoin-core-config-generator/ available here]. By default, Bitcoin (or bitcoind) will look for a file named 'bitcoin.conf' in the bitcoin [[data directory]], but both the data directory and the configuration file path may be changed using the -datadir and -conf command-line arguments.
{|
! Operating System
! Default bitcoin datadir
! Typical path to configuration file
|-
| Windows
| %APPDATA%\Bitcoin\
| C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf
|-
| Linux
| $HOME/.bitcoin/
| /home/username/.bitcoin/bitcoin.conf
|-
| Mac OSX
| $HOME/Library/Application Support/Bitcoin/
| /Users/username/Library/Application Support/Bitcoin/bitcoin.conf
|}

Note: if running Bitcoin in testnet mode, the sub-folder "testnet" will be appended to the data directory automatically.

==Sample Bitcoin.conf==

Copied from https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/examples/bitcoin.conf:

<pre>
##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##

# Network-related settings:

# Run on the test network instead of the real bitcoin network.
#testnet=0

# Run a regression test network
#regtest=0

# Connect via a SOCKS5 proxy
#proxy=127.0.0.1:9050

# Bind to given address and always listen on it. Use [host]:port notation for IPv6
#bind=<addr>

# Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
#whitebind=<addr>

##############################################################
## Quick Primer on addnode vs connect ##
## Let's say for instance you use addnode=4.2.2.4 ##
## addnode will connect you to and tell you about the ##
## nodes connected to 4.2.2.4. In addition it will tell ##
## the other nodes connected to it that you exist so ##
## they can connect to you. ##
## connect will not do the above when you 'connect' to it. ##
## It will *only* connect you to 4.2.2.4 and no one else.##
## ##
## So if you're behind a firewall, or have other problems ##
## finding nodes, add some using 'addnode'. ##
## ##
## If you want to stay private, use 'connect' to only ##
## connect to "trusted" nodes. ##
## ##
## If you run multiple nodes on a LAN, there's no need for ##
## all of them to open lots of connections. Instead ##
## 'connect' them all to one node that is port forwarded ##
## and has lots of connections. ##
## Thanks goes to [Noodle] on Freenode. ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Listening mode, enabled by default except when 'connect' is being used
#listen=1

# Maximum number of inbound+outbound connections.
#maxconnections=

#
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
#

# server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands
#server=0

# Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6.
# This option can be specified multiple times (default: bind to all interfaces)
#rpcbind=<addr>

# If no rpcpassword is set, rpc cookie auth is sought. The default `-rpccookiefile` name
# is .cookie and found in the `-datadir` being used for bitcoind. This option is typically used
# when the server and client are run as the same user.
#
# If not, you must set rpcuser and rpcpassword to secure the JSON-RPC api. The first
# method(DEPRECATED) is to set this pair for the server and client:
#rpcuser=Ulysseys
#rpcpassword=YourSuperGreatPasswordNumber_DO_NOT_USE_THIS_OR_YOU_WILL_GET_ROBBED_385593
#
# The second method `rpcauth` can be added to server startup argument. It is set at intialization time
# using the output from the script in share/rpcuser/rpcuser.py after providing a username:
#
# ./share/rpcuser/rpcuser.py alice
# String to be appended to bitcoin.conf:
# rpcauth=alice:f7efda5c189b999524f151318c0c86$d5b51b3beffbc02b724e5d095828e0bc8b2456e9ac8757ae3211a5d9b16a22ae
# Your password:
# DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=
#
# On client-side, you add the normal user/password pair to send commands:
#rpcuser=alice
#rpcpassword=DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=
#
# You can even add multiple entries of these to the server conf file, and client can use any of them:
# rpcauth=bob:b2dd077cb54591a2f3139e69a897ac$4e71f08d48b4347cf8eff3815c0e25ae2e9a4340474079f55705f40574f4ec99

# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established.
#rpcclienttimeout=30

# By default, only RPC connections from localhost are allowed.
# Specify as many rpcallowip= settings as you like to allow connections from other hosts,
# either as a single IPv4/IPv6 or with a subnet specification.

# NOTE: opening up the RPC port to hosts outside your local trusted network is NOT RECOMMENDED,
# because the rpcpassword is transmitted over the network unencrypted.

# server=1 tells Bitcoin-Qt to accept JSON-RPC commands.
# it is also read by bitcoind to determine if RPC should be enabled
#rpcallowip=10.1.1.34/255.255.255.0
#rpcallowip=1.2.3.4/24
#rpcallowip=2001:db8:85a3:0:0:8a2e:370:7334/96

# Listen for RPC connections on this TCP port:
#rpcport=8332

# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:
#rpcconnect=127.0.0.1

# Create transactions that have enough fees so they are likely to begin confirmation within n blocks (default: 6).
# This setting is over-ridden by the -paytxfee option.
#txconfirmtarget=n

# Miscellaneous options

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100

# Pay an optional transaction fee every time you send bitcoins. Transactions with fees
# are more likely than free transactions to be included in generated blocks, so may
# be validated sooner.
#paytxfee=0.00

# Enable pruning to reduce storage requirements by deleting old blocks.
# This mode is incompatible with -txindex and -rescan.
# 0 = default (no pruning).
# 1 = allows manual pruning via RPC.
# >=550 = target to stay under in MiB.
#prune=550

# User interface options

# Start Bitcoin minimized
#min=1

# Minimize to the system tray
#minimizetotray=1
</pre>

==Platforms==
===Windows===

====Start automatically====
To configure the Bitcoin client to start automatically:

You might use the configuration-file, or the GUI-Settings:

Settings -> Options

then mark the checkbox titled:
[X] Start Bitcoin on system startup

[[{{ns:file}}:Client_Settings_Options_windows.png]]

====Batch automation====
To work with batch, you have to start the daemon (bitcoind.exe). The bitcoin.exe run with option "-server" will respond with GUI-messages you are not able to process its answers.

===Mac===
[[{{ns:file}}:MacBitcoinStartOnLogin.png]]

===Linux===
[[{{ns:file}}:Client_Settings_Options.png]]

==See Also==

* [[Data directory]]

[[es:Ejecución de Bitcoin]]

[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Segwit

2017-05-14T17:07:18Z

JonathanCross: Redirect to Segregated_Witness

#REDIRECT [[Segregated_Witness]]

SegWit

2017-05-14T17:04:22Z

JonathanCross: Redirect to Segregated_Witness

#REDIRECT [[Segregated_Witness]]

Segregated Witness

2017-05-14T17:00:13Z

JonathanCross: Creating Segregated_Witness

{{stub}}

'''Segregated Witness''' (aka "SegWit") defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure.

==See Also==

* [[BIP_0141|BIP 141]] Segregated Witness (Consensus layer)
* [[BIP_0143|BIP 143]] Transaction Signature Verification for Version 0 Witness Program
* [[BIP_0144|BIP 144]] Segregated Witness (Peer Services)
* [[BIP_0145|BIP 145]] getblocktemplate Updates for Segregated Witness
* [[BIP_0147|BIP 147]] Dealing with dummy stack element malleability
* [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segregated Witness Benefits]

BIP 0142

2017-05-14T16:47:30Z

JonathanCross: Status: Draft => Deferred

{{bip}}

<pre>
BIP: 142
Title: Address Format for Segregated Witness
Authors: Johnson Lau <jl2012@xbt.hk>
Status: Deferred
Type: Standards Track
Created: 2015-12-24
</pre>

{{BipMoved|bip-0142.mediawiki}}

Softfork

2017-05-14T15:57:23Z

JonathanCross: /* Mechanism */ Fixing link to BIP_0012 and a typo with "its".

A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid.
Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible.
This kind of fork requires only a majority of the miners upgrading to enforce the new rules.

New transaction types can often be added as softforks, requiring only that the participants (sender and receiver) and miners understand the new transaction type.
This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules.
This is how [[P2SH]] was added to Bitcoin.

==Mechanism==

Given a set of valid blocks, you can take any subset of those blocks and that subset will also, of course, all be valid. A softfork changes the rules such that only a subset of blocks that were previously valid remain so. Often softforks make certain transactions invalid, for example a softfork could make any transaction that is more than 1KB invalid (not that that would necessarily be desirable).

Generally softforks accomplish something more useful, for example Pay-to-Script-Hash ([[P2SH]]) was a softfork. Originally the script <code>OP_HASH160 [20-byte-hash-value] OP_EQUAL</code> could be redeemed by simply pushing the preimage of the hashed value onto the stack. Now the value you push must be a script that evaluates to true. All new transactions with the script <code>OP_HASH160 [20-byte-hash-value] OP_EQUAL</code> weren't valid if they merely had a preimage of the hash pushed onto the stack, the preimage had to be a valid script. The requirement for the preimage being a valid script shrunk the set of valid transactions and added a feature at the same time.

In the P2SH example, two opcodes were redefined so they had a new function. You can also add new opcodes that originally didn't do anything. Because the new rules must cause the set of valid blocks to be a proper subset of the valid blocks with the old rules, you must ensure that adding this new opcode doesn't cause transactions that were once invalid to be valid. In [[BIP_0012|BIP12]] <code>OP_EVAL</code> was proposed. To softfork this new opcode in, the proposal stated an opcode that previously didn't have any effect would be replaced. The script would be evaluated twice, once with the opcode having the new <code>OP_EVAL</code> behavior and once with its old behavior of doing nothing. The script being run with the old behavior of doing nothing would ensure that the transaction was valid to old clients.

==Security==

In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners that accept the new rules, the more secure the network is post-fork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to [[Double-spending|doublespend]].

These attacks can be avoided by upgrading your client, however if the vast majority of miners (>95%) accept the new rules, the odds of an attacker being able to create many fake confirmations is low. Because miners want to make money, and without upgrading their blocks may be reorged out, there is an incentive for miners to upgrade and 100% acceptance of a fork should be achieved by miners quickly.

===2015 BIP66 Blockchain Fork===

After the deployment of the BIP66 softfork in 2015 95% of hash power stated that they accepted BIP66 by setting their block version to 3. In theory setting your block version to 3 is an agreement with the network to consider version 2 blocks invalid and only mine on valid forks. Being part of the 5% that hadn't updated and weren't creating version 3 blocks, BTCNuggets created a version 2 block which was invalid to all new clients (>=0.9.5) but valid to old clients. Antminer and F2Pool, comprising ~40% of the network at the time, were creating version 3 blocks, however neither miner validated previous blocks. This caused both Antminer and F2Pool to mine on top of BTCNuggets version 2 block and create an invalid fork. Over 40% of the hashpower was mining on this version 2 fork despite 95% having "agreed" to not do so. This led to a 6 block fork that was resolved after contacting the F2Pool and Antminer pool owners.

Any SPV clients or out of date clients were vulnerable to these fake confirmations and in theory there could have been a reversed 6 confirmation transaction. Fortunately there were zero doublespent confirmed transactions and the only money lost was mining revenue that these pools lost. F2Pool has continued mining without validating beforehand and SPV client as well as outdated full node clients are at an even higher risk as long as they do so.

==Implications==

Softforks don't require any nodes to upgrade to maintain consensus since all blocks with the new softforked in rules also follow the old rules, therefore old clients accept them. Softforks cannot be reversed without a hardfork since a softfork by definition only allows the set of valid blocks to be a proper subset of what was valid pre-fork.

If users upgrade to a post-softfork client and for some reason a majority of miners switch back to the pre-softfork client, the post-softfork client users would break consensus as soon as a block came along that didn't follow their clients new rules.

==See Also==
* [[Hardfork]]