Bitcoin Wiki - User contributions [en]

Bitcoin as an investment

2022-09-26T09:13:29Z

AllEd01: grammar, spelling

This page discusses the case for owning bitcoin as an investment and store of value.

==The case for investing==

# There is a [[Controlled supply|fixed supply]] of bitcoins. There will never be more than 21 million bitcoins.
# Because of bitcoin's [[Bitcoin as a medium of exchange|useful properties as a medium of exchange]], demand is growing or at least staying the same.
# Fixed supply and growing demand imply a growing price.

==Store of value==

Bitcoin has useful properties to make it a good store of value. It has been described as a "swiss bank account in your pocket"<ref>https://www.reddit.com/r/Bitcoin/comments/4a2l55/obama_meme_bitcoin_is_like_having_a_swissbank/</ref>.

* '''Cannot be debased.''' Limited to [[Controlled supply|21 million coins]] only.
* '''No storage cost.''' Bitcoins take up no physical space, [[Storing bitcoins|any amount can be stored]].
* '''Easy to hide.''' Can be stored encrypted on paper, on disk, or even [[Brainwallet|memorized in your brain]].
* '''Can be made [[Anonymity|anonymous]]''', meaning nobody would even know you own bitcoins or how many.
* '''Easy to protect.''' Can be made impossible to steal or seize by any thief, government or bank.
* '''Censorship resistant.''' The coins can be [[Bitcoin as a medium of exchange|sent anywhere in the world through the internet without being blocked]].
* '''No counterparty risk.''' Coins are in your possession, if you keep the [[private key]] of a bitcoin secret and the transaction has enough [[Confirmation|confirmations]], then nobody can take them from you no matter for what reason, no matter how good the excuse, no matter what.

Even if these properties are not useful to you, they may be useful to others which would benefit you by increasing the value of your held bitcoins.

==Useful notes==

===Difficulty with storing and theft===

Because bitcoin is a digital asset, it can be un-intuitive to store safely. Users should definitely [[Ways to store Bitcoins|read the guides]] for correctly storing bitcoins. Historically many people have lost their coins but with proper understanding, the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

===Preserving these properties===

Bitcoin is a software project. There's an obvious question of how its useful properties can be maintained. Couldn't some programmer simply edit the source code to create more than 21 million bitcoins? The answer turns out to be no. Bitcoin is secured by strong cryptography and game theory, and its properties are very hard or impossible to change.

See also:

* [[Myths#Miners, developers, or some other entity could change Bitcoin's properties to benefit themselves]]
* [[Principles of Bitcoin]]
* [[Economic majority]]

Some people say that although the supply of bitcoin is limited, an infinite amount of other cryptocurrencies (altcoins) can be created. This is fundamentally confused reasoning because bitcoin and altcoins are different currencies, as bitcoin wallets would reject altcoin payments and vis versa. Claiming altcoins dilute the supply of bitcoins is like saying hyperinflation of the Venezuelan currency dilutes the supply of US Dollars.

===Volatility===

Bitcoin is much more volatile than most other assets, including the most volatile commodities. This can be good when the price is rising but may hurt the dollar value of your holdings when the price is falling. One way to deal with this is to only hold a certain percentage of your savings in bitcoin and the rest in more stable assets but does not eliminate the risk altogether.

You could hedge yourself with Bitcoin futures or Bitcoin options, at the cost of accepting some counterparty risk. Most of the Bitcoin futures and options exchanges are centralized and you have to trust them with your coins. This however allows you to use your coins for payment and not worry about their dollar value. When using options, you also can enjoy the upside (at the cost of the option).

You could also deal with it by studying bitcoin's fundamentals deeply so that temporary price drops do not scare you into selling low. Investing with a dollar-cost-averaging strategy can also reduce the effects of volatility<ref>https://breadwallet.com/blog/how-invest-bitcoin-without-getting-hurt-volatility/</ref>. Also, over time, as your holdings grow, the impact of the new purchases is smaller and the volatility affects your increasing holdings.

===Uncorrelated asset===

Although bitcoin is volatile, it is mostly uncorrelated with any other asset classes<ref>http://www.signalplot.com/what-is-bitcoins-correlation-with-other-financial-assets/</ref>. This means bitcoin can reduce the overall volatility as part of a well-diversified portfolio.

==See also==
* [[Bitcoin as a medium of exchange]]
* [[Principles of Bitcoin]]
* [[Irreversible Transactions]]
* [[Controlled supply]]

==References==
<references />

[[Category:Economics]]

BIPS

2022-09-26T09:11:55Z

AllEd01: grammar

BIPS was a Payment Service Provider (PSP) specializing in the technical aspects of accepting cryptocurrencies - such as bitcoin.

==Bitcoin Payment Solutions==

Provided services for merchants in 204 countries.

==Merchant Tools==
For merchants using an eCommerce platform, choose between a wide range of bitcoin plugins. For merchants without an eCommerce solution, BIPS offered Hosted Invoices. Hosted Invoices could be used for both catalogue of items and a shopping cart with buttons and widgets per item. Also Hosted Invoices supported recurring billing in bitcoin, by emailing invoice links or using BIP70 Payment Requests.

===Point of Sale===
BIPS delivered near field communication (NFC) to "make secure payments fast and convenient by simply tapping the phone on any BIPS-enabled point of sale at checkout. And the possibility of sending payment information via sound based on Chirp".

BIPS POS NFC could be used with the following devices:

Phones

HTC One on Sprint
HTC One SV on Boost Mobile
HTC EVO 4G LTE on Sprint
LG Viper 4G LTE on Sprint
LG Viper 4G LTE on Zact Mobile
LG Optimus Elite on Sprint
LG Optimus Elite on Virgin Mobile
LG Optimus Elite on Zact Mobile
LG Nexus 4*
LG Nexus 5*
Motorola Moto X*
Samsung Galaxy Note II on Sprint
Samsung Galaxy Note II on US Cellular
Samsung Galaxy SIII on Sprint
Samsung Galaxy SIII on MetroPCS
Samsung Galaxy SIII on US Cellular
Samsung Galaxy SIII on Virgin Mobile
Samsung Galaxy SIII on Boost Mobile
Samsung Galaxy S4 on Sprint (model number must be SPH-L720)
Samsung Galaxy S4 on US Cellular
Samsung Galaxy S4 Google Play Edition*
Samsung Nexus S 4G on Sprint
Samsung Galaxy Nexus on Sprint
Samsung Galaxy Nexus*
Samsung Galaxy Victory 4G LTE on Sprint
Samsung Galaxy Victory 4G LTE on Virgin Mobile
Samsung Galaxy Axiom on US Cellular

Tablets

Asus Nexus 7
Samsung Nexus 10

===Former business model===

BIPS didn't charge merchants for accepting Bitcoin online or with the point of sale as payment for merchandise, but ran a 0% Payment Processing Fees, and planned to make money by the conversion spread.

===Settlement===

Exchanged bitcoins were sent to the customer's bank account in 1-5 business days. With the possibility of setting a % to be transferred, or simply keeping bitcoin.

Motto: sell for $100, see $100 deposited into your bank*

==Consumer Side==

===Buy Bitcoins===

BIPS provided a now defunct market to buy Bitcoins from any country in the world.

===Sell Bitcoins===

You could receive payouts to banks in any currency in any country.

==History==

With experience in Bitcoin since 2010, BIPS was founded in July 2011.

In 2013, the company lost 1,295 bitcoins (then worth around US$1 Million) in an online theft <ref name="Dead" />

After the heist company did not provide any refunds and never recovered.

==See Also==
* [[Bitcoin Ladder]]

==References==
<references>
<ref name="Dead">[http://mashable.com/2013/11/25/cyberattack-leads-to-heist-of-1-million-in-bitcoin/ Lorenzo Franceschi-Bicchierai (November 25, 2013). "Cyberattack Leads to $1 Million Bitcoin Heist". Mashable.]</ref>
</references>

[[Category:Defunct exchanges‏‎]]
[[Category:Clients‏‎]]
[[Category:ECommerce‏‎]]
[[Category:EWallets‏‎]]
[[Category:Economics‏‎]]
[[Category:Financial‏‎]]
[[Category:Shopping Cart Interfaces]]
[[Category:Payment Processors]]
[[Category:Bitcoin payment systems]]

BitcoinSentiment

2022-09-26T09:10:52Z

AllEd01: grammar, spelling

'''BitcoinSentiment''' is a non-profit, ad-free site tracking the voter's sentiment towards Bitcoin through the means of continuous polling. The idea is to provide the technical means required for tapping into the power of crowd-sourcing.

The quality of the data increases as the number of voters increases and you can contribute, by putting voting widgets on your site. To encourage the use of widgets, they are designed to be non-intrusive and to not "steal your visitors".

The data generated on the site is free for use and can be downloaded by anyone.

The site offers a variety of charts, with the purchasing power of Bitcoin plotted in terms of other asset classes such as gold and inflation-protected US Treasuries.

==External Links==
*[http://bitcoinsentiment.com/ BitcoinSentiment website]

[[Category:Trading]]
[[Category:Investing]]
[[Category:Economics]]

Bitcoin Hedge Fund

2022-09-26T09:07:17Z

AllEd01: punctuation, spelling

The first hedge fund to be exclusively financed with bitcoin (BTC). This fund is designed to give a return for people who want to use BTC as an investment tool while significantly mitigating the volatility of the value of BTC.

NOTE - The site does not list any address or list its location. The website domain is privacy protected and was registered just ten days before launch. The launch announcement was made by a forum member using an account that shows having joined the bitcoin forum community a few weeks prior. It isn't shown who will manage the fund. Proceed at your own risk.

Invests in a diversified group of exchange-traded funds (ETFs), domestic and international bonds, and derivatives (mainly stock options).

The purpose of the fund is the long-term capital appreciation that outpaces the S&P 500.

Bitcoins received by the fund are converted to USD.

To maintain stability and liquidity, initial deposits may not be withdrawn for a period ranging from 21 to 90 days, depending on how early the deposit was made. Withdrawals are in the form of BTCs and are sent to the bitcoin address associated with the account.

This site was launched on June 24, 2011<ref>[http://bitcointalk.org/index.php?topic=21799.0 Announcing the Bitcoin Hedge Fund]</ref>.

==Fees==

There will be no management fees through 2011. A small management fee may be initiated in 2012 (with prior notification) of up to 1%. There is no front-load fee, but there will be a back-load fee of 2%<ref>[http://bitcoinhedgefund.com/how-it-works How It Works]</ref>.

==External Links==

* [http://bitcoinhedgefund.com Bitcoin Hedge Fund] website

==References==
<references />

[[Category:Investing]]

Credit

2022-09-26T09:05:30Z

AllEd01: punctuation

You can use credit with Bitcoin for a variety of purposes, including making and accepting loans, establishing reputations, transferring value, and more.

There are two big reasons that borrowing or lending can be considered not very smart:

* Bitcoin is extremely volatile.
* Bitcoin is a bearer asset. "Not your keys not your coin."

==Bitcoin credit==

Any time a financial transaction takes place which leaves one party more obliged than the other, the obliged party is extending credit to the obliging party. This allows groups of people and organizations to cooperate even when their resources and needs are spread out over time and can be a highly valuable activity.

You can of course always lend or borrow Bitcoins casually with your friends, but when interacting with more distant social connections or for larger amounts, you may want to make use of a credit service. Such services can help you keep track of credit balances, interest rates, and amounts, and other figures, while providing many useful features such as credit score reports or even credit exchanges using Ripple routing.

[[Category:Credit]]
[[Category:Investing]]

Binary options

2022-09-26T08:59:17Z

AllEd01: punctuation, spelling

An option is a financial contract that gives the buyer the right to buy or sell an asset for a specified price (strike price) on or before a certain date (expiration date). A '''call''' option allows the holder to buy the underlying asset on or before the date. A '''put''' option allows the holder to sell the asset for that price on or before the due date. Options are valued according to the difference between the strike price and the current market price of the underlying asset.

Options are used widely in financial markets to hedge or speculate on the price of an underlying asset with a quantified risk. Complex financial instruments can be built using combinations of buying and selling call and put options with different strike prices and expiration dates.

A '''binary option''' is a simple type of option that is valued according to a true/false statement. For example, if the price of the underlying asset is above a certain level the call (long) option will pay 100, if it is below it will pay 0. For a put option, the reverse is true.

Binary options make for simple valuation and are therefore a good way for traders to avoid complicated valuation, which often works in favour of option issuers to the detriment of buyers.

Binary options have become a popular way to trade major financial markets online.

==Binary Options and Bitcoin==
With the popularity of Bitcoin and its acceptance as a currency binary options platforms began adding BTC as one of the currencies to trade. This has further helped the growth of binary platforms as well as mainstream recognition of Bitcoin as a currency. Most brokers only offer it as a currency pair versus the American Dollar.

==Bitcoin Binary Option Smart Contracts==

Bitcoin allows the creation of smart contracts for binary options. The [[contract]] itself holds the funds in escrow and on the expiry date pays all the funds to the Bitcoin address that was on the correct side of the true/false statement.

This allows the complete elimination of counterparty risk. The solvency of the option issuer is irrelevant if the funds are already locked in the contract itself. It is irrelevant if the company or party that issued the option disappears, defaults, or wants to change the terms of the contract. The elimination of counterparty risk allows long-term financial contracts in a trust-minimized way.

Smart contracts rely on an [[oracle]] to verify external conditions.

Example:

*Alice and Bob each send 1 BTC to the contract 2-of-3 [[multisignature]] address which is controlled by private keys K1, K2, K3.
*Alice holds K1
*Bob holds K2
*[[Oracle]] holds K3.
*On expiry if the condition is TRUE the [[oracle]] sends K3 to Alice. Alice withdraws 2 BTC.
*On expiry if the condition is FALSE [[oracle]] sends K3 to Bob. Bob withdraws 2 BTC.

The mechanism is very similar to an [[Contract|escrow]] contract but instead of a mediator holding the third key the [[oracle]] holds it and can resolve automatically based on simple true/false conditions. Ideally, to prevent it from being compromised or targeted, the [[oracle]] would be a simple automated system unaware of the information that it was sending. It would only know to send an encrypted e-mail to Alice if true, to Bob if false.

The example above is can be tried using a multi-signature wallet like [[GreenAddress]] and a simple oracle like [http://earlytemple.com/ Early Temple] or [https://www.realitykeys.com/ Reality Keys].

[https://www.realitykeys.com/developers/resources#bitcoin Reality Keys] details a slightly more complex way of doing this which allows funds to be sent to Alice or Bob depending on a conditional: Conditional payments using branching bitcoin transactions.

OP_IF
2 A-pub Yes-pub 2 OP_CHECKMULTISIG
OP_ELSE
2 B-pub No-pub 2 OP_CHECKMULTISIG
OP_ENDIF

==How To Trade==
Trades are placed by predicting the direction an asset will move during the specified time frame. The time that option ends is called an expiry time. Expiry times range anywhere from 30 seconds until months away. At the end of the time, if the direction you chose was correct, you win the trade. Winning trades pay out slightly less than 100% and typical payouts range between 80-85% depending on the broker.

Assets include
*Stocks
*Currencies
*Commodities
*Indices

[[Category:Gambling‏]] [[Category:Economics‏‏]] [[Category:Trading‏‏]]

Bitcoin Days Destroyed

2022-09-26T08:57:49Z

AllEd01: spelling, punctuation

Bitcoin Days Destroyed is a measure of the transaction volume of Bitcoin. <ref>[http://bitcointalk.org/index.php?topic=6172.msg90789#msg90789 ByteCoin's Proposal to use Bitcoin Days Destroyed as a measure of transaction volume]</ref> A bounty for a script to compute the Bitcoin Days Destroyed by the transactions in a block has been awarded. <ref>[http://bitcointalk.org/index.php?topic=9300.0 Bounty Award to develop a script to compute the BitcoinDays Destroyed by the transactions in a block.]</ref> [[Abe]] is a [[block chain browser]] that computes this statistic in real-time.

==Calculation==

Bitcoin days destroyed for any given transaction are calculated by taking the number of Bitcoins in a transaction and multiplying it by the number of days it has been since those coins were last spent.

===Example===

If someone has 100BTC that they received a week ago and they spend it then 700 bitcoin days have been destroyed. If they take those 100BTC and send them to several addresses and then spend them then although the total transaction volume could be arbitrarily large the number of bitcoindays destroyed is still 700.

==Graph of Percentage of Bitcoin Days Destroyed==

Percentage of Bitcoin Days destroyed vs block number, as of June 17th, 2011.
[[File:June-17th-days-destroyed.png]]

==See Also==

* [[Abe]] Alternate Block Explorer

==References==
<references/>

[[Category:Economics]]

Deflationary spiral

2022-09-26T08:57:02Z

AllEd01: grammar, spelling

'''Deflationary spiral''' is an economic argument that proposes that runaway deflation can eventually lead to the collapse of the currency given certain conditions and constraints. It is a common criticism made against the viability of [[Bitcoin]].
The ‘deflationary spiral’ is a real condition that affects the popular fractional reserve backing system. Bitcoin is not affected by this because it is fundamentally different from popular currency.

Deflation is a decline in the general price level. Deflation occurs when the price of goods and services, relative to a specific measure, declines. It is not necessarily that the value of the goods and services themselves declined, but can be because the value of the currency itself increased.

For example, let us consider an economy comprised entirely of beef and oranges where the medium of exchange is gold. Both beef and oranges can decay and are not consistent, and therefore cannot be used as a currency. In order to trade, people exchange gold for either beef or oranges. They see gold as a store of value that they can use to purchase beef or oranges in the future. What happens when the economy grows and we can produce more beef and more oranges? The price of both beef and oranges will decline. To the extent our productive capacity for both beef and oranges increased at the same pace, the exchange value between the two (the amount of beef for a given number of oranges) will likely stay the same; however, those who held gold as a store of value would now be able to purchase more beef and more oranges for a given amount of gold.

A deflationary spiral occurs when the value of a currency, relative to the goods in an economy, increases continually as a result of hoarding. As the value of the currency relative to the goods in the economy increase, people have the incentive to hoard the currency, because by merely holding it, they hope to be able to purchase more goods for less money in the future. A lack of currency available in the market causes the price of goods to further decrease, resulting in more hoarding.

In our economy of beef and oranges, it is easy to see how this could occur. First, people see a significant gain in productivity on the horizon; we will be able to produce more beef and oranges with the same effort in the future. The supply of gold, however, is fixed. As a result, people desire to hold gold, because they will be able to purchase more beef and oranges with their gold in the future than they can now. This will lead to a decline in the price of beef and oranges as measured by gold (an increase in the value of gold). Limiting the amount of currency in the market available for exchange can also make transactions more difficult. In a complex system where we do not only have beef, oranges, and gold, this can result in a deflationary spiral where no one wishes to spend their currency and the economy itself slows as a result of the limited number of transactions. Limited demand with fixed output results in a decline in prices, which further exacerbates the problem.

Alternative explanation:
A deflationary spiral occurs when the price of a traded article increases at some given rate, which causes people to hoard it. As people hoard the commodity, less and less of it is available thus causing the price to go up even more. In turn, even more, people hoard the commodity. Thus a feedback loop or spiral of deflation occurs. 

In practice, there is only a limited amount of 'value' that can be placed upon a good before it becomes too attractive to trade for other goods (thus ending the spiral). The only time that the 'Deflationary Spiral' can happen (to its conclusion) is when people can foresee a time when they are forced to use that particular traded article. See below for a dissenting argument on this topic.

==In The Popular Fractional Reserve Banking System==
The popular money that we trade consists of the principal of the loans of other people. All this money must be someday 'repaid.' When people save (pay back their loans), the total monetary supply contracts. When people spend (take out loans), the total monetary supply is increasing.

If you have people who are hoarding money, the principal still needs to be repaid. Hoarding will make it harder for other people in the economy to pay back their loans.

Because people foresee a time when they need to pay back their loans (a future fixed expense), when the value of the money starts to increase (deflation), those with loans will endeavor to pay back the loans quicker. This causes the money supply to reduce, reducing the total amount of money available for repayment of loans, again making it harder for people to pay back what they owe.

This Deflationary spiral diverts funds away from the legitimate economy, to the repayment of debt. Causing the economy to stagnate and stop.

==Bitcoin==
The key difference is that people don't foresee a fixed cost (unit amount) that they must pay with Bitcoin. If the value of the Bitcoins that they own increases, then any future cost will take a proportionally smaller amount of Bitcoins. There isn't any fixed incentive to holding Bitcoin other than speculation.

If the economy that uses Bitcoin grows, the per-unit value of Bitcoin proportionally increases also.

Everything is the opposite of the popular fractional reserve banking system (because Bitcoin isn't debt but an asset). Bitcoins '''only''' deflate in value when the Bitcoin Economy is '''growing'''.

Because the Deflationary spiral is a real problem in the traditional monetary system, doesn't necessarily mean that it will also be a problem in the Bitcoin economy.

<blockquote>
"Elaborate controls to make sure that currency is not produced in greater numbers is not something any other currency, like the dollar or the euro, has," says Russ Roberts, professor of economics at George Mason University. The consequence will likely be slow and steady deflation, as the growth in circulating bitcoins declines and their value rises.

"That is considered very destructive in today's economies, mostly because when it occurs, it is unexpected," says Roberts. But he thinks that won't apply in an economy where deflation is expected. "In a Bitcoin world, everyone would anticipate that, and they know what they got paid would buy more then than it would now."
</blockquote>
--MIT Technology Review: [http://www.technologyreview.com/computing/37619/page2/ What Bitcoin Is, and Why It Matters], May 25, 2011

==Alternative Argument==
A deflationary spiral occurs when there is an incentive to hoard because of declining prices, which results in even less available currency on the market, further perpetuating declining prices.

How could this occur in the Bitcoin market?

1. Limited price stability has a negative impact on the acceptance of a currency. Vendors do not wish to speculate on the price of currency when selling goods or services.

2. Once prices do stabilize in the future, there will always be the knowledge that the number of Bitcoins in the market is limited. As a result, to the extent the GDP of the Bitcoin economy increases (the total value of all Bitcoin transactions completed increases in "real" terms), there will continue to be price deflation. The expectation of future deflation means that there will be a discrepancy in perceived values between parties valuing bitcoin on longer or shorter time horizons.
The apparent over-pricing of bitcoin from the perspective of people engaging in short-term transactions will encourage the creation and adoption of competing systems.

While this is not a traditional deflationary spiral, the constraint on the actual money supply can produce the same result, which is a limit on the value of goods and services transacted using Bitcoins.

==See Also==

* [[Controlled inflation]]
* [[Bitcoin Days Destroyed]]
* [http://bitcoin.stackexchange.com/questions/408/does-hoarding-really-hurt-bitcoin Does hoarding really hurt bitcoin?] on stackexchange.com
* [http://www.jjgames.com/page/bitcoin-spending-during-deflation BitCoin Consumption Increases During Deflation ]

[[Category:Economics]]

Fractional Reserve Banking and Bitcoin

2022-09-26T08:55:14Z

AllEd01: spelling, grammar

While Fractional Reserve Banking with Bitcoin is possible, there is [https://bitcointalk.org/index.php?topic=51899.0 disagreement] over what it would entail. Much discussion occurred on the [[Talk:Myths#Fractional_reserve_banking_with_Bitcoin_is_fundamentally_different|Myths Talk Page]].

==Keynesian Viewpoint==
Fractional Reserve Banking with Bitcoin is possible and practical. It is already implemented with [https://coinlenders.com CoinLenders]. There is no fundamental difference between classical currencies and Bitcoin as it applies to banking. Banks will still be free to take in bitcoins and present them to customers as "available for withdrawal" while still lending most of those bitcoins to a different customer for a profit. Some of those bitcoins will be held in reserves in case of a bank run. It will be up to the bank to hold a sufficient supply of reserves in order to prevent insolvency in the event of a bank run. Central banks were established to enforce reserve requirements and so, with Bitcoin lacking a central bank, some banks will almost surely collapse, taking their customers' deposits with them. A large bitcoin exchange could tomorrow lend out 10,000 bitcoins to an individual to start a business. The [http://www.federalreserve.gov/faqs/money_12845.htm money supply] would thus increase by 10,000 and we would instantly have Fractional Reserve Banking. The same amount of bitcoins would still exist in the [[Block Chain]], but the body of people participating in the Bitcoin economy would have the perception that more bitcoins exist. If the value of a bitcoin is stable for a long period of time, then Fractional Reserve Banking is ''inevitable''. 

See [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional reserve banking].

The Monetary Base of Bitcoin is limited to 21 million. But because Fractional Reserve Banking is possible, the money supply of bitcoins (which includes demand deposits) can exceed 21 million by a factor of x where x is the [http://en.wikipedia.org/wiki/Money_multiplier Money Multiplier].

==Austrian Viewpoint==

According to the [http://wiki.mises.org/wiki/Fractional_reserve_banking Austrian viewpoint]:
<blockquote>Fractional-reserve banking (or FRB) is the widespread banking practice in which only a fraction of a bank's demand deposits are kept in reserve and available for immediate withdrawal (as cash and other highly liquid assets), whilst the remaining cash is lent out to borrowers (and so is never actually available for immediate withdrawal to legitimate deposit-holders).</blockquote>

In order for fractional reserve banking to affect the money supply, the debt instruments issued by the bank (for example, bank notes or demand deposits) must be accepted as if they were money proper, in other words, they must be money-substitutes. This is explained for example by [http://mises.org/rothbard/austrianmoneysupply.pdf Rothbard in Austrian Definitions of the Supply of Money]:

<blockquote>And so long as demand deposits are accepted as equivalent to standard money, they will function as part of the money supply.

It is important to recognize that demand deposits are not automatically part of the money supply by virtue of their very existence; they continue as equivalent to money only so long as the subjective estimates of the sellers of goods on the market think that they are so equivalent and accept them as such in exchange.</blockquote>

In the historical cases of money based on gold or government-issued fiat, the reason why money-substitutes are accepted as if they were money proper is that the money proper has in some circumstances high transaction costs (for example, gold might be too heavy to carry around, or the buyer and seller are not at the same location and want to perform the exchange electronically), or are not legally permitted (normal people are not allowed to obtain central bank reserves). This creates a demand for forms of money that have lower transaction costs. With gold/fiat, this requires the creation of debt instruments, which then, after being generally accepted in exchange, become money substitutes and a part of the money supply.

The situation with Bitcoin is different because other forms can be created without debt instruments, for example [[Casascius physical bitcoins]] or [[Bitbills]]. Bitcoin in its "classical" form is similar to the function of a bank account (allowing electronic transfers of balances) even though there is no debt instrument. Any object that can store 64 bytes of data (size of Bitcoin keypair) can, hypothetically, be used as a form of Bitcoin. In some cases, shorter forms than 64 bytes are possible too (for example, [[Mini_private_key_format|mini private key format]] used by Casascius physical bitcoins). Issuers of Bitcoin-based debt instruments, if they expect these instruments to be accepted in exchange, need to create demand for them as a method of payment outside of the Bitcoin network. This is difficult, because a transaction that occurs outside of the Bitcoin network is incompatible with it, so people equipped with software for handling only pure Bitcoin transactions cannot accept it. Furthermore, they also would need to compete against not only Bitcoin but other currencies, payment methods, and services.

Currently, Bitcoin-based debt instruments are restricted to a narrow field of uses. Exchanges allow these instruments to be traded against other currencies. E-wallets allow inter-wallet transfers. GLBSE allows the floating of shares or other contractual arrangements. However, these debt instruments are, in general, outside of these narrow fields, not accepted for exchange as if they were native Bitcoins. They rarely even circulate outside of the internal transactions of the providers of these services. There are very few exceptions, such as the redeemable Mt. Gox code. If the service provider attempted to conduct FRB by overissuing these instruments, they would be exposed to the risk of having them redeemed too quickly. One possible way of mitigating this risk is to institute a suspension of specie payments (for example, Mt. Gox. having a default withdrawal limit).

If in the future, P2P exchanges and distributed wallets are available (both have been suggested already at bitcointalk.org forums), this would decrease the demand for Bitcoin-based debt instruments even further.

Historically, in all known situations where an overissue of Bitcoin-based debt instruments was produced, this resulted either in a voluntary elimination of the excess instruments (Mt. Gox hack from June 2011), bankruptcy (the demise of mybitcoin), or a new investor bailout (the demise of bitomat.pl and subsequent takeover by Mt. Gox). Here we have empirical evidence that FRB with Bitcoin is possible.

Putting all this together, there are several steps that need to be addressed regarding Bitcoin-FRB and money supply:

# overissue of debt instruments (this would cause FRB)
# general acceptance of these instruments as a method of payment (this would mean the instruments need to be included in the money supply)
# market price of these instruments at a different rate than the reserve ratio of the issuer (this would cause inflation or deflation)

Even if we assume that an overissue is possible in long term, there are significant obstacles in phases 2 and 3, as elaborated above. It is therefore unlikely that even if Bitcoin-FRB became widespread, this would significantly affect the money supply of Bitcoins or inflation/deflation.
[[Category:Economics]]

Bitcoin Improvement Proposals

2022-09-26T08:53:14Z

AllEd01: spelling

A '''Bitcoin Improvement Proposal''' ('''BIP''') is a design document for introducing features or information to Bitcoin. This is the standard way of communicating ideas since Bitcoin has no formal structure.

The first BIP ([[BIP 0001]]) was submitted by Amir Taaki on 2011-08-19 and described what a BIP is.

== Types ==
There are three types of BIPs:
* '''Standards Track BIPs''' - Changes to the network protocol, block or transaction validation, or anything affecting interoperability.
* '''Informational BIPs''' - Design issues, general guidelines. This type of BIP is NOT for proposing new features and does not represent community consensus
* '''Process BIPs''' - Describes or proposes a change in process. Similar to Standards BIPs but apply outside the Bitcoin protocol.

== Layers ==
[[BIP 0123]] established four layers for Standards BIPs:
# '''Consensus'''<ref>Further divided into [[hardfork|hard]] and [[softfork]]s.</ref>
# '''Peer Services'''
# '''API/RPC'''
# '''Applications'''

== Workflow ==
As described in [[BIP 0001]] the workflow of a BIP is as follows:

[[File:BIP Workflow.png]]

== List of BIPs ==
{{BipMoved|README.mediawiki|README}}

== Notes ==
<references />

== See also ==
* [[Hardfork Wishlist]]
* [[Protocol documentation]]
* [[:Category:BIP]]

[[Category:BIP| ]]

[[es:Propuestas de mejora de Bitcoin]]

Debit cards

2022-09-26T08:49:23Z

AllEd01: grammar nd spelling

This page lists cryptocurrency-fueled debit cards.

Created: April 2020.
Last update: August 2020.

Sources include [https://docs.google.com/spreadsheets/d/1DRbTeMCzb4UeXI0YlAzBxMc2u2i0cN_17Ql6eMngK6E/edit#gid=0 this spreadsheet], this [https://www.cryptowisser.com/debit-cards/ simplistic table], this [https://bitcointalk.org/index.php?topic=5223719.0 Bitcointalk discussion] and others. '''Please contribute any edits here''', as those other sources are not actively maintained, are less trustworthy, and/or more superficial.

Whenever possible, link to the source. KYC requirements you've personally experienced may lack links, though links to screenshots ([https://imgur.com/a/vGFwSCj like this]) or forum/Reddit/etc posts would be helpful.

Legend / notes:
* ''DL'' = Driver License
* ''Est.'' = Established, (Mon) YYYY
* ''POA'' = Proof of Address. Some are strict, e.g. utility bills, others less strict, e.g. bank statements or government correspondence
* ''SoF'' = Source of Funds, requested by some companies before or during using the card
* ''tx'' = transaction
* HQ links may point to the contact page, to save space
* Card cost may include issuance and shipping/delivery cost; add links for details
* Maintenance fees are independent of withdrawals or purchases; they are required to keep the card active
* "Fee structure" should '''link''' to a page detailing the maintenance (though usually 0), [https://wirexapp.com/fees-and-limits deposit, transfer, exchange, transaction, and/or issuance fees], though due to the volatility of crypto, they're rather meaningless. The issuance fee/cost can also be explicitly stated in the "Card cost" column.
* Limits indicate withdrawal, maximum balance, or other limits. Always link to the source.
* non-custodial = you hold your funds, not the card company
* Given the fluctuations of crypto, rewards are generally insignificant, so there's no column for them. Link to the rewards page in the "Notes" if you want.
* All KYC requires at least an identification document (Passport, Driver's License, Identity Card), so only ''other'' KYC measures will be mentioned in the KYC column. They can be more or less invasive (e.g. live video verification w/ ID, vs. just a selfie).

{| class="wikitable sortable"
|- style="text-align: center; background-color: #f0f0ff;"
! Company
! Status
! HQ
! Est.
! Available to residents of
! KYC process
! Card cost
! Coins accepted
! Fee structure
! Limits
! Physical card?
! Virtual card?
! Web app?
! Notes
|-
! {{rh}} | [http://advcash.com AdvCash]
| {{Yes|active}}
| [https://advcash.gi/en/contacts/ GI]
|  [https://bitcointalk.org/index.php?topic=1011381.0 2015]
|  EU, Turkey, Israel. Upcoming [https://bitcointalk.org/index.php?topic=1011381.msg54232912#msg54232912 Russia] + World, [US](https://advcash.gi/en/faq/) currently banned.
|  ID, address, phone number
|  [https://advcash.gi/en/solutions/card $/€7.99 virtual, $/€14.99 physical]
|  [https://advcash.gi/en/fees/ BTC, ETH, LTC, BCH, XRP, ZEC, TRX?]
|  Free maintenance, [https://advcash.gi/en/fees/ fees for deposit & withdrawal]
|  [https://advcash.gi/en/faq/ Verified]: $50k/day, $300k/mo
|  {{Yes}}
|  {{Yes}}
|  {{Yes}}
|  Cards available only to verified users. [https://bitcointalk.org/index.php?topic=1011381.0 Extensive Bitcointalk thread]. Possible KYC [https://advcash.gi/en/faq/ even for non-verified operations].
|-
! {{rh}} | [https://bitpay.com/card/ BitPay]
|  {{Yes}}
|  ?
|  2011
|  [https://support.bitpay.com/hc/en-us/articles/115005033763-Where-is-the-BitPay-Card-available- USA only] [https://support.bitpay.com/hc/en-us/articles/115003003743-Where-can-I-use-my-BitPay-Card- can't be used in some countries]
|  {{No|[https://support.bitpay.com/hc/en-us/articles/115003003463-What-kind-of-information-will-you-need-from-me-for-a-BitPay-Card-order- SSN]}}, SMS verification [https://support.bitpay.com/hc/en-us/articles/115003014446-Is-a-Credit-Check-Required-for-Me-to-Obtain-a-Card- no credit check], DL photo files from app [https://support.bitpay.com/hc/en-us/articles/360037486651-How-do-I-complete-the-BitPay-ID-process- separate BitPay ID] for [https://bitcointalk.org/index.php?topic=5173083.0 larger tx]
|  $10
|  BTC, BCH, ETH, XRP; [https://support.bitpay.com/hc/en-us/articles/115003028206-How-do-I-add-funds-to-my-BitPay-Card- ACH, direct deposit]
|  [https://support.bitpay.com/hc/en-us/articles/115002990663-What-fees-will-I-pay-to-use-the-BitPay-Card- 3% currency conversion]
|  [https://support.bitpay.com/hc/en-us/articles/115003013586-What-are-the-ATM-withdrawal-limits-on-my-Card- $1500/day ATM], [https://support.bitpay.com/hc/en-us/articles/115003014306-How-Much-Money-Can-I-Load-onto-My-Card-What-Is-My-Daily-Spending-Limit- $10k/day, max $25k balance]
|  {{Yes|Mastercard}} issued by Metropolitan Commercial Bank
|  {{Yes|After KYC, before activating physical card}}
|  {{Yes|[https://support.bitpay.com/hc/en-us/articles/115003013546-How-can-I-check-my-BitPay-Card-balance-and-review-transactions- Yes]}}, [https://support.bitpay.com/hc/en-us/articles/360031288111-How-to-Navigate-in-the-BitPay-Dashboard Dashboard]
|  [https://bitcointalk.org/index.php?topic=4355205.0 Antibitpay]. The wallet app can hold stablecoins: PAX, USDC, USDG, BUSD.
|-
! {{rh}} | [https://card.binance.com/en/ Binance]
|  {{No}}
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
| 
|-
! {{rh}} | [https://www.bitsacard.com Bitsa]
| {{Yes|active}}
| [https://bitsa.zendesk.com/hc/en-150/articles/360005955378-Where-will-my-money-be-is-it-safe- ES?]
|  [https://bitcointalk.org/index.php?topic=5211795.0 Dec 2019]
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005955038-In-which-countries-is-Bitsa-card-available- EU countries] / [https://bitsa.zendesk.com/hc/en-150/articles/360005965177-Which-are-the-requirements-to-open-a-Bitsa-account- SEPA zone]
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005965477-How-do-I-perform-the-identity-verification- ID] + selfie w/ ID
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005955278-How-much-does-it-cost-to-have-a-Bitsa-account- 0]
|  "Top it up by card, transfer, cash or blockchain tokens."
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005963558-What-is-the-maintenance-fee- 0 maint. fee]
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005968837-How-much-can-I-withdraw-in-cash- 450€/day, 2500-5000€/mo]
|  {{Yes|[https://bitsa.zendesk.com/hc/en-150/articles/360005965677-How-do-I-add-physical-card-to-my-account- Yes]}}
|  {{Yes|[https://bitsa.zendesk.com/hc/en-150/articles/360005965677-How-do-I-add-physical-card-to-my-account- Yes]}}
|  {{No|[https://bitsa.zendesk.com/hc/en-150/articles/360005954998-Can-I-login-to-my-Bitsa-account-from-a-computer- Not yet]}}
|  [https://bitsa.zendesk.com/hc/en-150/articles/360005967758-Does-my-card-have-associated-a-wallet-to-reload-it-with-cryptocurrencies- Non-custodial funds]. [https://bitcointalk.org/index.php?topic=5211795.0 Minimal Bitcointalk presence]. [https://bitsa.zendesk.com/hc/en-150/articles/360005975877-Can-I-make-a-transfer-to-top-up-my-Bitsa-from-the-account-of-a-family-member-or-friend- Odd English].
|-
! {{rh}} | [https://www.bitwala.com/card/ Bitwala]
|  {{Yes}}
|  Germany
|  [https://support.bitwala.com/hc/en-gb/articles/360000382040-When-was-Bitwala-founded- 2015]
|  [https://support.bitwala.com/hc/en-gb/articles/360000650360-Who-can-open-a-Bitwala-account- EEA, .ch] [https://support.bitwala.com/hc/en-gb/articles/360000377840 no US persons]
|  {{No|[https://support.bitwala.com/hc/en-gb/articles/360002220519-What-is-a-Proof-of-Address-POA-document- POA] during [https://support.bitwala.com/hc/en-gb/articles/360010537939-Why-is-video-identification-necessary- video call] with [https://support.bitwala.com/hc/en-gb/articles/360000377980-What-is-IDnow- IDnow], [https://support.bitwala.com/hc/en-gb/articles/360010427400-Why-do-we-check-transactions-and-ask-for-the-source-of-funds- SoF and routine checks], [https://support.bitwala.com/hc/en-gb/articles/360010427560-Why-has-my-account-been-closed- unexplained terminations]}}
|  [https://support.bitwala.com/hc/en-gb/articles/360000609180-What-are-the-Bitwala-account-fees- 0]
|  [https://support.bitwala.com/hc/en-gb/articles/360001489000-How-to-top-up-my-account- Bitcoin, SEPA]
|  [https://www.bitwala.com/pricing/ 1% crypto]
|  [https://support.bitwala.com/hc/en-gb/articles/360000670079-What-is-the-maximum-purchase-amount- €15k/tx], [https://support.bitwala.com/hc/en-gb/articles/360000658660-What-are-the-trading-limits- €30k/wk]
|  {{Yes|[https://support.bitwala.com/hc/en-gb/articles/360000872680-What-is-the-Bitwala-debit-card- Mastercard]}}
|  {{No|[https://support.bitwala.com/hc/en-gb/articles/360000381720-Do-you-offer-virtual-cards- No]}}
|  ?
| 
|-
! {{rh}} | [https://crypto.com Crypto.com]
|  {{Yes}}
|  ?
|  ?
|  [https://help.crypto.com/en/articles/1341663-when-will-i-get-my-mco-visa-card USA, Singapore, APAC, EU]
|  ?
|  ?
|  ?
|  ?
|  ?
|  {{Yes|5 MCO VISA cards}}
|  ?
|  {{No}}
| 
|-
! {{rh}} | [https://www.jubiter.com/card Jubiter]
|  {{No|[https://bitcointalk.org/index.php?topic{{urlencode:=}}5223719.msg54333083#msg54333083 Likely KYC scam]}}
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  [https://bitcointalk.org/index.php?topic=5223719.msg54333083#msg54333083 Possible scam] asking for KYC documentation, then claiming they've just stopped offering cards. [https://bitcointalk.org/index.php?topic=6047196 Doesn't support bech32 withdrawals].
|-
! {{rh}} | [https://monolith.xyz Monolith]
| {{Yes|active}}
|  UK
|  ?
|  [https://support.monolith.xyz/hc/en-us/articles/360007239698-Which-countries-are-supported-by-Monolith- EEA], AFTA, special member territories
|  ID photo, [https://imgur.com/a/vGFwSCj POA photo], selfie
|  [https://support.monolith.xyz/hc/en-us/articles/360001403598-What-are-the-fees-associated-with-Monolith-Visa-Debit-Card- 0]
|  ETH
|  [https://support.monolith.xyz/hc/en-us/articles/360001403598-What-are-the-fees-associated-with-Monolith-Visa-Debit-Card- Fees]
|  ?
|  {{Yes|[https://support.monolith.xyz/hc/en-us/articles/360001345338-What-is-the-Monolith-Visa-Debit-Card- VISA]}}
|  ?
|  {{No}}
|  Non-custodial wallet. Formerly "TokenCard". [https://github.com/tokencard/contracts Open source]. Sleek website. The app needs minimal permissions.
|-
! {{rh}} | [https://wirexapp.com Wirex]
| {{Yes|active}}
|  UK
|  [https://bitcointalk.org/index.php?topic=1392468.0 May 2016]
|  [https://wirexapp.com/help/article/the-list-of-supported-countries-0027 EEA, APAC etc, no USA]
|  {{No|[https://wirexapp.com/help/article/why-you-need-to-verify-your-source-of-funds-and-how-to-do-it-0013 Verify source of funds, random re-verification]}}
|  [https://wirexapp.com/fees-and-limits 0], except APAC
|  ?
|  [https://wirexapp.com/fees-and-limits Fees]
|  [https://wirexapp.com/fees-and-limits Limits]
|  {{Yes|VISA by Contis}}
|  ?
|  {{Yes|[https://wirexapp.com/help/article/how-do-i-order-a-wirex-card-0028 Yes]}}
|  [https://wirexapp.com/fees-and-limits Rewards]. [https://bitcointalk.org/index.php?topic=1392468.0 Extensive Bitcointalk thread].
|-
! Company !! Status !! HQ !! Established || Available to residents of !! KYC process !! Card cost !! Coins accepted !! Fee structure !! Limits !! Physical card? || Virtual card? || Web app? || Notes
|}

To add a card, copy the section below at the bottom of the table above the last (footer) row. Whenever possible, link to references.

<pre>
|-
! {{rh}} | [https://... Company name]
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
|  ?
| 
</pre>

Miner fees

2022-09-26T08:46:46Z

AllEd01: spelling and grammar

'''Miner fees''' are a fee that spenders may include in any Bitcoin on-chain [[transaction]]. The fee may be collected by the miner who includes the [[transaction]] in a [[block]].

== Overview ==

Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).

Bitcoin's design makes it easy and efficient for the spender to specify how much fee to pay, whereas it would be harder and less efficient for the recipient to specify the fee, so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees.

When a miner creates a [[block proposal]], the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the [[best block chain]], the fee income will be sent to the specified recipient. If a valid block does not collect all available fees, the amount not collected is permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017,<ref>[https://medium.com/@alcio/how-to-destroy-bitcoins-255bb6f2142e How to Destroy Bitcoins] by Antoine Le Calvez, Medium.com, retrieved 2018-01-03</ref><ref>[https://twitter.com/random_walker/status/948590112576868354 "Looks like back in 2012, when tx fees started becoming common, some miners were claiming the standard 50 BTC and leaving all tx fees unclaimed."], Arvind Narayanan, Twitter.com, posted 2018-01-03, retrieved 2018-01-03</ref> with decreasing frequency over time.

==The market for block space==

[[File:fee.png|thumb|Receiving the fees from hundreds of transactions (0.44 BTC)]]

The minimum fee necessary for a transaction to confirm varies over time and arises from the intersection of supply and demand in Bitcoin's free market for block space.<ref>[https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb Bram Cohen blog post with helpful background to the market for block space]</ref> On the supply size, Bitcoin has a [[maximum block size]] (currently one million vbytes) that limits the maximum amount of transaction data that can be added to a block.

However, Bitcoin blocks are not produced on a fixed schedule—the system targets an average of one block every 10 minutes over long periods of time but, over short periods of time, a new block can arrive in less than a second or more than an hour after the previous block. As the number of blocks received in a period of time varies, so does the effective maximum block size. For example, in the illustration below we see the average time between blocks based on the time they were received by a node during a one-day period (left axis) and the corresponding effective maximum block size implied by that block production rate (right axis, in million [[vbytes]]):

[[File:Time-between-blocks.png|center]]

During periods of higher effective maximum block sizes, this natural and unpredictable variability means that transactions with lower fees have a higher than normal chance of getting confirmed—and during periods of lower effective maximum block sizes, low-fee transactions have a lower than normal chance of getting confirmed.

On the demand side of Bitcoin's free market for block space, each spender is under unique constraints when it comes to spending their bitcoins. Some are willing to pay high fees; some are not. Some desire fast confirmation; some are content with waiting a while. Some use wallets with excellent dynamic fee estimation; some do not. In addition, demand varies according to certain patterns, with perhaps the most recognizable being the weekly cycle where fees increase during weekdays and decrease on the weekend:

[[File:Block-fees-dow.png|center]]

Another less recognizable cycle is the intra-day cycle where fees wax and wane during the day:

[[File:Block-fees-hod.png|center]]

These variations in supply and demand create a market for block space that allows users to make a trade-off between confirmation time and cost. Users with high time requirements may pay a higher than average transaction fee to be confirmed quickly, while users under less time pressure can save money by being prepared to wait longer for either a natural (but unpredictable) increase in supply or a (somewhat predictable) decrease in demand.

It is envisioned that over time the cumulative effect of collecting transaction fees will allow those creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks as the creation of new bitcoins from the mining activity goes towards [[Controlled supply|zero in the future]].<ref>[https://bitcoincore.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash], section 6: Incentive, Satoshi Nakamoto, 2008-11-01, retrieved 2018-01-22</ref>

== Feerates ==

Perhaps the most important factor affecting how fast a transaction gets confirmed is its fee rate (often spelled feerate). This section describes why feerates are important and how to calculate a transaction's feerate.

Bitcoin transactions vary in size for a variety of reasons. We can easily visualize that by drawing four transactions side-by-side based on their size (length) with each of
our examples larger than the previous one:

[[File:Feerate1.png|400px|center]]

This method of illustrating length makes it easy to also visualize an example maximum block size limit that constrains how much transaction data a miner can add to an individual block:

[[File:Feerate2.png|400px|center]]

Since Bitcoin only allows whole transactions to be added to a particular block, at least one of the transactions in the example above can't be added to the next block. So how does a miner select which transactions to include? There's no required selection method (called ''policy'') and no known way to make any particular policy required, but one strategy popular among miners is for each individual miner to attempt to maximize the amount of fee income they can collect from the transactions they include in their blocks.

We can add a visualization of available fees to our previous illustration by keeping the length of each transaction the same but making the area of the transaction equal to its fee. This makes the height of each transaction equal to the fee divided by the size, which is called the ''feerate:''

[[File:Feerate3.png|400px|center]]

Although long (wide) transactions may contain more total fees, the high-feerate (tall) transactions are the most profitable to mine because their area is greatest compared to the amount of space (length) they take up in a block. For example, compare transaction B to transaction D in the illustration above. This means that miners attempting to maximize fee income can get good results by simply sorting by fee rate and including as many transactions as possible in a block:

[[File:Feerate4.png|400px|center]]

Because only complete transactions can be added to a block, sometimes (as in the example above) the inability to include the incomplete transaction near the end of the block frees up space for one or smaller and lower-feerate transactions, so when a block gets near full, a profit-maximizing miner will often ignore all remaining transactions that are too large to fit and include the smaller transactions that do fit (still in highest-feerate order):

[[File:Feerate5.png|400px|center]]

Excluding some rare and rarely-significant edge cases, the feerate sorting described above maximizes miner revenue for any given block size as long as none of the transactions depend on any of the other transactions being included in the same block (see the next section, ''feerates for dependent transactions,'' for more information about that).

To calculate the feerate for your transaction, take the fee the transaction pays and divide that by the size of the transaction (currently based on [[weight units]] or [[vbytes]] but no longer based on [[bytes]]). For example, if a transaction pays a fee of 2,250 nanobitcoins and is 225 vbytes in size, its feerate is 2,250 divided by 225, which is 10 nanobitcoins per vbyte (this happens to be the minimum fee [[Bitcoin Core]] Wallet will pay by default).

When comparing to the feerate between several transactions, ensure that the units used for all of the measurements are the same. For example, some tools calculate size in weight units and others use vbytes; some tools also display fees in a variety of [[Units|denominations]].

== Feerates for dependent transactions (child-pays-for-parent) ==

Bitcoin transactions can depend on the inclusion of other transactions in the same block, which complicates the feerate-based transaction selection described above. This section describes the rules of that dependency system, how miners can maximize revenue while managing those dependencies, and how bitcoin spenders can use the dependency system to effectively increase the feerate of unconfirmed transactions.

Each transaction in a block has a sequential order, one transaction after another. Each block in the block chain also has a sequential order, one block after another. This means that there's a single sequential order to every transaction in the [[best block chain]].

[[File:Ancestor-feerate1.png|center]]

One of Bitcoin's [[consensus rules]] is that the transaction where you receive bitcoins must appear earlier in this sequence than the transaction where you spend those bitcoins. For example, if Alice pays Bob in transaction A and Bob uses those same bitcoins to pay Charlie in transaction B, transaction A must appear earlier in the sequence of transactions than transaction B. Often this is easy to accomplish because transaction A appears in an earlier block than transaction B:

[[File:Ancestor-feerate2.png|center]]

But if transaction A and B both appear in the same block, the rule still applies: transaction A must appear earlier in the block than transaction B.

This complicates the task of maximizing fee revenue for miners. Normally, miners would prefer to simply sort transactions by feerate as described in the ''feerate'' section above. But if both transaction A and B are unconfirmed, the miner cannot include B earlier in the block than A even if B pays a higher feerate. This can make sorting by feerate alone less profitable than expected, so a more complex algorithm is needed. Happily, it's only slightly more complex.

For example, consider the following four transactions that are similar to those analyzed in the preceding ''feerate'' section:

[[File:Ancestor-feerate3.png|center]]

To maximize revenue, miners need a way to compare groups of related transactions to each other as well as to individual transactions that have no unconfirmed dependencies. To do that, every transaction available for inclusion in the next block has its feerate calculated for it and all of its unconfirmed ancestors. In the example, this means that transaction B is now considered as a combination of transaction B plus transaction A:

[[File:Ancestor-feerate4.png|center]]

Note that this means that unconfirmed ancestor transactions will be considered twice or more, as in the case of transaction A in our example which is considered once as part of the transaction B+A group and once on its own. We'll deal with this complication in a moment.

These transaction groups are then sorted in feerate order as described in the previous ''feerate'' section:

[[File:Ancestor-feerate5.png|center]]

Any individual transaction that appears twice or more in the sorted list has its redundant copies removed. In the example case, we remove the standalone version of transaction A since it's already part of the
transaction B+A group:

[[File:Ancestor-feerate6.png|center]]

Finally, we see if we can squeeze in some smaller transactions into the end of the block to avoid wasting space as described in the previous ''feerate'' section. In this case, we can't, so no changes are made.

Except for some edge cases that are rare and rarely have a significant impact on revenue, this simple and efficient transaction sorting algorithm maximizes miner feerate revenue after factoring in transaction dependencies.

Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.

For spenders, miner use of transaction grouping means that if you're waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it ''child pays for parent (CPFP)'' because child transaction B helps pay for parent transaction A.

To calculate the feerate for a transaction group, sum the fees paid by all the the group's unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in [[weight units]] or [[vbytes]]). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.

The idea behind ancestor feerate grouping goes back to at least 2013 and saw several different proposals to add it to Bitcoin Core, with it finally becoming available for production with the August 2016 release of Bitcoin Core 0.13.0.<ref>[https://bitcoincore.org/en/2016/08/23/release-0.13.0/#more-intelligent-transaction-selection-for-mining More intelligent transaction selection for mining], Bitcoin Core 0.13.0 release notes, BitcoinCore.org, 2016-08-23, retrieved 2017-01-14</ref>

==Reference Implementation==

The following sections describe the behavior of the [[Original Bitcoin client|reference implementation]] as of version 0.12.0. Earlier versions treated fees differently, as do other popular implementations (including possible later versions).

===Sending===

Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>`
(or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin
Core to use floating fees. By default, Bitcoin Core will use floating
fees.

Based on past transaction data, floating fees approximate the fees
required to get into the `m`th block from now. This is configurable
with `-txconfirmtarget=<m>` (default: `2`).

Sometimes, it is not possible to give good estimates, or an estimate
at all. Therefore, a fallback value can be set with `-fallbackfee=<f>`
(default: `0.0002` BTC/kB).

At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default:
0.10) BTC.
Furthermore, Bitcoin Core will never create transactions smaller than
the current minimum relay fee.
Finally, a user can set the minimum fee rate for all transactions with
`-mintxfee=<<nowiki>i</nowiki>>`, which defaults to 1000 satoshis per kB.

Note that a typical transaction is 500 bytes.

===Including in Blocks===

This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.

Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.

The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough.

For Bitcoin Core 0.12.0 zero bytes<ref>https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#relay-and-mining-priority-transactions</ref> in the block are set aside for the highest-[[Transaction_fees#Priority_transactions|priority transactions]]. Transactions are added highest-priority-first to this section of the block.

===Relaying===

The reference implementation's rules for relaying transactions across the peer-to-peer network are very similar to the rules for sending transactions, as a value of 0.00001 BTC is used to determine whether or not a transaction is considered "Free". However, the rule that all outputs must be 0.01 BTC or larger does not apply. To prevent "penny-flooding" denial-of-service attacks on the network, the reference implementation caps the number of free transactions it will relay to other nodes to (by default) 15 thousand bytes per minute.

===Settings===

{| class="wikitable"
|-
! Setting !! Default Value (units)
|-
| txconfirmtarget || 2 (blocks)
|-
| paytxfee || 0 (BTC/kB)
|-
| mintxfee || 0.00001 (BTC/kB)
|-
| limitfreerelay || 15 (thousand bytes per minute)
|-
| minrelaytxfee || 0.00001 (BTC/kB)
|-
| blockmaxsize || 750000 (bytes)
|-
| blockminsize || 0 (bytes)
|-
| blockprioritysize || 0 (bytes)
|}

==Fee Plotting Sites==

As of May 2016, the following sites seem to plot the required fee, in satoshi per (kilo)byte, required to get a transaction mined in a certain number of blocks. Note that all these algorithms work in terms of probabilities.

* https://bitcoinfees.21.co/
* https://bitcoinfees.github.io/
* https://statoshi.info/dashboard/db/fee-estimates
* http://p2sh.info/dashboard/db/fee-estimation
* https://www.bitcoinqueue.com/2d.html
* https://bitcoinfees.net/

=== Other Useful Sites ===

* https://anduck.net/bitcoin/fees/ - Shows what kind of fees filled up recent blocks
* https://btc.com/stats/unconfirmed-tx - the state of the website's mempool broken down by fee rate
* https://jochen-hoenicke.de/queue/#1w - another mempool broken down by fee rate site
* https://esotericnonsense.com/ - yet another mempool site, also very good
* https://estimatefee.com/ - You can click any of the transactions in that graph to get more info (like its "effective fee rate" which uses recursive ancestors/descendants for CPFP) and an estimated amount of blocks it'll take to confirm. It works with any transaction in the top 100MB of the bitcoin mempool. And you can enter in any transaction txid for info when you're wondering why it doesn't confirm.
* https://mempool.space/ - Shows how the next few blocks are shaping up and the range of fees per block. Helps estimate the low-end fee to use to get into the next block.
* https://whatthefee.io/ - Shows the probability of a particular fee rate being confirmed within a particular timeframe.

==Priority transactions==

Historically it was not required to include a fee for every transaction. A large portion of miners would mine transactions with no fee given that they had enough "priority". Today, low priority is mostly used as an indicator for spam transactions and almost all miners expect every transaction to include a fee. Today miners choose which transactions to mine only based on fee-rate.

Transaction priority was calculated as a value-weighted sum of input age, divided by transaction size in bytes:
priority = sum(input_value_in_base_units * input_age)/size_in_bytes
Transactions needed to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold was written in the code as COIN * 144 / 250, suggesting that the threshold represents a one-day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

So, for example, a transaction that has 2 inputs, one of 5 btc with 10 confirmations, and one of 2 btc with 3 confirmations, and has a size of 500bytes, will have a priority of
(500000000 * 10 + 200000000 * 3) / 500 = 11,200,000

===Historic rules for free transactions===
A transaction was safe to send without fees if these conditions were met:

* It is smaller than 1,000 bytes.
* All outputs are 0.01 BTC or larger.
* Its priority is large enough (see above)

==See Also==

* [[Techniques to reduce transaction fees]]
* [[Free transaction relay policy]]
* [[Fee bumping]]
* [[Replace by fee]]
* [http://bitcoinexchangerate.org/fees Unconfirmed transactions fee chart]
* [https://jochen-hoenicke.de/queue/ historic fees and mempools]

==References==
<references />

[[Category:Technical]]
[[Category:Vocabulary]]
[[Category:Mining]]
[[de:Transaktionsgebühren]]

{{Bitcoin Core documentation}}

Privacy

2022-09-26T08:42:34Z

AllEd01: spelling, grammar

While Bitcoin can support strong '''privacy''', many ways of using it are usually not very private. With a 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 from them is spent.
* 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 that 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].

See also [[#Examples_and_case_studies|the privacy examples]] for real-life case-studies.

== Introduction ==

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

Bitcoin records [[transactions]] on the [[block chain]] which is visible to all and so creates the most serious damage to privacy. Bitcoins move between [[address]]es; sender [[address]]es are known, receiver [[address]]es are known, and amounts are known. Only the identity of each [[address]] is not known (see first image).

The linkages between addresses made by transactions are 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 identification 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, 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|fungibility]] in Bitcoin: if you can meaningfully distinguish one coin from another, then their [[Fungibility|fungibility]] is weak. If our [[Fungibility|fungibility]] is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won't accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we'd all not like to get stuck with bad coins. This adds friction, transactional costs and allows the blacklist provider to engage in censorship, and so makes Bitcoin less valuable as a money.

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

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 those wallets could automatically detect when a payment address has been used before (perhaps by asking the user) and then use a reused address as their change address; so both outputs would be reused addresses.

Also, most reused addresses are mentioned on the internet, forums, social networks like Facebook, Reddit, Stackoverflow...etc. These addresses you can find and check on https://checkbitcoinaddress.com/ site. It's like a little bit de-anonymization of pseudo-anonymized blockchain.

==== 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 --> B1 --> 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, reducing the payment amount instead of change (in a receiver-pays-for-fee model), or replacing both addresses in each RBF transaction (this would require obtaining multiple payment addresses from the receiver).

==== 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 heuristic ===

As described in the introduction, [[address]]es are connected together by [[transaction]]s on the [[block chain]]. The mathematical concept of a [https://en.wikipedia.org/wiki/Graph_(discrete_mathematics) graph] can be used to describe the structure where addresses are connected with transactions. [[Address]]es are vertices while [[transaction]]s are edges in this transaction graph.

This is called a heuristic because [[transaction]]s on the [[block chain]] do not necessarily correspond to real economic transactions. For example the [[transaction]] may represent someone sending bitcoins to themselves. Also, real economic transactions may not appear on the [[block chain]] but be [[Off-Chain Transactions|off-chain]]; either via a custodial entity like an exchange, or non-custodial off-chain like [[Lightning Network]].

==== 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 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 payments|mystery shopper payment]] is when an adversary pays bitcoin to a target in order to obtain privacy-relevant information. It will work even if [[address reuse]] is avoided. For example, if the target is an online merchant then the adversary could buy a small item. On the payment interface they would be shown one of the merchant's bitcoin [[address]]es. The adversary now knows that this [[address]] belongs to the merchant and by watching the blockchain for later [[transaction]]s other information would be revealed, which when combined with other techniques could reveal a lot of data about the merchant. The [[common-input-ownership heuristic]] and change address detection could reveal other addresses belonging to the merchant (assuming countermeasures like [[CoinJoin]] are not used) and could give a lower-bound for the sales volume. This works because anybody on the entire internet can request one of the merchant's [[address]]es.

=== Forced address reuse ===

'''Forced [[address reuse]]''' is when an adversary pays an (often small) amount of bitcoin to [[address]]es that have already been used on the [[block chain]]. The adversary hopes that users or their wallet software will use these ''forced payments'' as inputs to a larger transaction which will reveal other addresses via the the [[common-input-ownership heuristic]] and thereby leak more privacy-relevant information. These payments can be understood as a way to coerce the address owner into unintentional [[address reuse]]<ref>https://www.reddit.com/r/Bitcoin/comments/3a1hte/psa_dust_being_sent_to_your_addresses_might_help/</ref><ref>https://www.reddit.com/r/Bitcoin/comments/9r9qud/if_you_have_recently_received_a_very_small_amount/</ref>.

This attack is sometimes incorrectly called a '''dust attack'''<ref>https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/471#issuecomment-565857814</ref>.

If the forced-payment coins have landed on already-used ''empty'' addresses, then the correct behaviour by wallets is to not spend those coins ever. If the coins have landed on addresses which are not empty, then the correct behaviour by wallets is to fully-spend all the coins on that address in the same transaction.

=== 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 government, ISP, Wifi provider or VPN provider) can see data sent and received by your node. This would reveal that you are a bitcoin user. Even if a connection is encrypted the adversary could still see the timings and sizes of data packets. A block being mined results in a largely synchronized burst of identically-sized traffic for every bitcoin node, because of this bitcoin nodes are very vulnerable to traffic analysis revealing the fact that bitcoin is being used.

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

Another option is to spend the coins individual directly to miner fees. Here are instructions for how to do this with Electrum or Bitcoin Core: https://gist.github.com/ncstdc/90fe6209a0b3ae815a6eaa2aef53524c

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_payments|mystery shopper payments]]; an adversary can donate some bitcoins and watch on the blockchain to see where they go afterwards, using heuristics like the [[common-input-ownership heuristic]] to obtain more information such as donation volume and final destination of funds.

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 ====
{{Main|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 ===
{{Main|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.

In of February 2022, '''MercuryWallet''' was the first implementation has been deployed<ref>[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility]</ref><ref>[https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964 Coinswap design document]</ref>. In June 2020, the [https://en.wikipedia.org/wiki/Human_Rights_Foundation Human Rights Foundation] (a New York-based nonprofit that promotes and protects human rights globally) granted $50,000 to [https://en.bitcoin.it/wiki/User:Belcher Chris Belcher] (one of the main contributors to this very page) to work on the project.<ref>[https://bitcoinmagazine.com/articles/the-human-rights-foundation-is-now-funding-bitcoin-privacy-development-starting-with-coinswap The Human Rights Foundation Is Now Funding Bitcoin Privacy Development, Starting With CoinSwap]</ref>

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

==== StateChains ====

[[StateChain]]s are a cryptographic structure that consists of a chain of digital signatures transfering ownership of a specific statecoin (a bitcoin UTO) between owners. Similar to a blockchain or sidechain, the statechain acts as immutable cryptographic proof of ownership and a proof that a statecoin(bitcoin UTXO) has not been double spent.

=== Confidential transactions ===
{{Main|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.

=== 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>Lightning in Scriptless Scripts Andrew Poelstra 20 Mar 2017 https://lists.launchpad.net/mimblewimble/msg00086.html</ref><ref>L2 Summit Hosted by MIT DCI and Fidelity Labs, Boston 2018, Andrew Poelstra talk on Scriptless Scripts http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</ref>.

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 an open-source, non-custodial, '''privacy-focused''' Bitcoin wallet for Desktop, that implements trustless '''[[CoinJoin]]'''. The CoinJoin coordinator (run by zkSNACKs Ltd., the company that is sponsoring the development of Wasabi) cannot steal from, nor breach the privacy of the participants.

The package includes built-in [[Tor]] and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and privacy of the users is respected. Under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays, significantly decreasing the network attack surface.

Wasabi also includes all standard privacy tech like a Hierarchical [[Deterministic wallet]] and [[address reuse]] avoidance, as well as mandatory coin control and labeling. The wallet uses BIP-158 [[Client-side block filtering]] to obtain its own transaction history in a private way and it has a one-click partial full node integration as it ships with Bitcoin Knots.
If the user already has a Bitcoin full node on a local or remote device, then it is possible to specify the IP address and port, or the Tor onion service, and Wasabi will use it to verify and enforce rules of Bitcoin.

In addition to this, it has advanced cutting-edges features like:
* Opt-in [[PayJoin]]
* Dust attack protections
* Custom change address
* Anti wallet fingerprinting

Wasabi also has a [https://docs.wasabiwallet.io/ complete and detailed documentation] containing explanations on the architecture of the program, on its functioning and tutorials on how to use it.

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]]. StonewallX2 is a scheme that creates transactions that are identical to Stonewall but involve two participants, making it an actual [[CoinJoin]] transaction. PayNyms are an implementation of [[ECDH address]]es. The wallet also has a feature called like-type change outputs where it generates a [[change]] address which is of the same type as the payment address; this avoids [[#Wallet_fingerprinting|wallet fingerprinting]] using address types which leads to change address detection.

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

=== Mercury Wallet ===

'''Mercury''' is a new Bitcoin layer-2 scaling technology, based on the concept of statechains, that enables private keys for BTC deposits (UTXOs) to be transfered securely between owners without requiring an on-chain transaction.

This enables users to transfer full custody of an amount of BTC to anyone almost instantly, with increased privacy, and without having to pay miner fees. Mercury also supports the first production '''[[CoinSwap]]''' implementation.

Main article: [[MercuryWallet]]

== 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_payments|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_payments|mystery shopper payments]] can be used to spy on people, even then they avoid [[address reuse]]. Be mindful of what is being revealed with the [[common-input-ownership heuristic]].

=== 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.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 payments|mystery shopper payment]].
# The malware author sends all their received stolen coins 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_payments|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.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_payments|mystery shopper payments]], sending 0.001 BTC to ransomware addresses and watching where that coin is sent to. Two ransomware operators (Cerber and Locky) took the bait but one operator (Sage) did not and so his cluster was never found.
# 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]]

ASICMiner

2022-09-26T08:39:17Z

AllEd01: added a bit more information and the reference text used for this.

{{Infobox company|name=ASICMiner|native_name=烤猫矿机|image=[[{{ns:file}}:Logo-asicminer-en.png|270x64px]]|website=[http://iasicminer.com/ iasicminer.com]|twitter=ASICMinerANN|weibo=5195261989}}
The ASIC (Application-Specific Integrated Circuit) miner is a computer device that is specifically used for the main purpose of mining digital currency. It does not need any additional hardware.<ref>https://www.ionos.com/digitalguide/server/know-how/cryptomining/</ref>
== See Also ==
* [https://bitcointalk.org/index.php?topic=99497.0 Official Announcement/Shareholder Thread]
* [http://www.weibo.com/u/5195261989 Official Microblogging]

Changelog

2022-09-26T07:58:33Z

AllEd01: grammar, spelling

This page aggregates the changelogs that have been posted on the forum for the Bitcoin releases.
Note that some download links are no longer valid as highly insecure versions may have been deleted, or links may have changed.

This page hasn't been updated for a while. Changelogs for newer versions as well as historical release notes can be found at bitcoin.org: https://bitcoin.org/en/version-history and/or through github: https://github.com/bitcoin/bitcoin/tree/master/doc/release-notes

=Changelogs=

https://bitcoin.org/en/release/v0.7.1
==0.7.X==

===0.7.1<ref>[https://bitcoin.org/en/release/v0.7.1 0.7.1 release announcement]</ref>===

New features:

* Added a boolean argument to the RPC stop command, if true sets -detachdb to create standalone database .dat files before shutting down.

* -salvagewallet command-line option, which moves any existing wallet.dat to wallet.{timestamp}.dat and then attempts to salvage public/private keys and master encryption keys (if the wallet is encrypted) into a new wallet.dat. This should only be used if your wallet becomes corrupted, and is not intended to replace regular wallet backups.

* Import $DataDir/bootstrap.dat automatically, if it exists.

==0.6.X==
After 0.6.3, all subsequent releases are stable maintenance releases, 0.7.0 is based on 0.6.3.

===0.6.3<ref>[https://bitcointalk.org/index.php?topic=89877.0 0.6.3 release announcement]</ref>===
Bitcoin version 0.6.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.3/

This is a bug-fix release, with no new features.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

CHANGE SUMMARY

Fixed a serious denial-of-service attack that could cause the
bitcoin process to become unresponsive. Thanks to Sergio Lerner
for finding and responsibly reporting the problem. (CVE-2012-3789)

Optimized the process of checking transaction signatures, to
speed up the processing of new block messages and make propagating
blocks across the network faster.

Fixed an obscure bug that could cause the bitcoin process to get
stuck on an invalid block-chain, if the invalid chain was
hundreds of blocks long.

Bitcoin-Qt no longer automatically selects the first address
in the address book (Issue #1384).

Fixed minimize-to-dock behavior of Bitcoin-Qt on the Mac.

Added a blocking checkpoint at block 185,333 to speed up initial
blockchain download.

===0.6.2<ref>[https://bitcointalk.org/index.php?topic=80187.0 0.6.2 release announcement]</ref>===
Bitcoin version 0.6.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/

This is a bug-fix and code-cleanup release, with no major new features.

Please report bugs using the GitHub issue tracker at:
https://github.com/bitcoin/bitcoin/issues

NOTABLE CHANGES

Much faster shutdowns. However, the blkindex.dat file is no longer
portable to different data directories by default. If you need a
portable blkindex.dat file then run with the new -detachdb=1 option
or the "Detach databases at shutdown" GUI preference.

Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that
could cause long-running nodes to crash.

Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
binaries are dynamically linked to the version of OpenSSL on the system).

CHANGE SUMMARY

Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.

Source codebase changes:
- Many source code cleanups and warnings fixes. Close to building with -Wall
- Locking overhaul, and several minor locking fixes
- Several source code portability fixes, e.g. FreeBSD

JSON-RPC interface changes:
- addmultisigaddress enabled for mainnet (previously only enabled for testnet)

Network protocol changes:
- protocol version 60001
- added nonce value to "ping" message (BIP 31)
- added new "pong" message (BIP 31)

Backend storage changes:
- Less redundant database flushing, especially during initial block download
- Shutdown improvements (see above)

Qt user interface:
- minor URI handling improvements
- progressbar improvements
- error handling improvements (show message box rather than console exception,
etc.)
- by popular request, make the 4th bar of the connection icon green

===0.6.1===
Never released

===0.6.0<ref>[https://bitcointalk.org/index.php?topic=74737.0 0.6.0 release announcement]</ref>===
Bitcoin version 0.6.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

This release includes more than 20 language localizations.
More translations are welcome; join the
project at Transifex to help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
https://github.com/bitcoin/bitcoin/tarball/v0.6.0 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.6.0 # .zip

For Ubuntu users, there is a ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

KNOWN ISSUES

Shutting down while synchronizing with the network
(downloading the blockchain) can take more than a minute,
because database writes are queued to speed up download
time.

NEW FEATURES SINCE BITCOIN VERSION 0.5

Initial network synchronization should be much faster
(one or two hours on a typical machine instead of ten or more
hours).

Backup Wallet menu option.

Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

New wallets created with this version will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are already supported
by the network but wallet.dat files containing
short keys are not compatible with earlier
versions of Bitcoin-Qt/bitcoind.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

New command-line argument -splash=0 to disable
Bitcoin-Qt's initial splash screen

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
pubkey : hexadecimal public key
iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command (getmininginfo) for getting
extra information related to mining. The getinfo
JSON-RPC command no longer includes mining-related
information (generate/genproclimit/hashespersec).

NOTABLE CHANGES

BIP30 implemented (security fix for an attack involving
duplicate "coinbase transactions").

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options were renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.

Three fill-up-available-memory denial-of-service
attacks were fixed.

NOT YET IMPLEMENTED FEATURES

Support for clicking on bitcoin: URIs and
opening/launching Bitcoin-Qt is available only on Linux,
and only if you configure your desktop to launch
Bitcoin-Qt. All platforms support dragging and dropping
bitcoin: URIs onto the Bitcoin-Qt window to start
payment.

PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, the creation, and testing of multi-signature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 13 and BIP 16.

==0.5.X==
After 0.5.1, all subsequent releases are stable maintenance releases, 0.6.0 is based on 0.5.1.

===0.5.5<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify the status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show a green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of the last block for "up to date" status from 30 to 90 minutes
Show a message box when a runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in the tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around an issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.5.4<ref>[https://bitcointalk.org/index.php?topic=76808.0 0.5.4 release announcement]</ref>===
Bitcoin version 0.5.4 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.

This is a bugfix-only release in the 0.5.x series, plus a few protocol updates.

Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz

PROTOCOL UPDATES

BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
Support for validating message signatures produced with compressed public keys.

BUG FIXES

Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
Fix broken testnet mining.
Stop excess inventory relay during initial block download.
When disconnecting a node, clear the received buffer so that we do not process any already received messages.
Yet another attempt at implementing "minimize to tray" that works on all operating systems.
Fix Bitcoin-Qt notifications under Growl 1.3.
Increase the required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
Implemented missing verifications that led to crashes on entering some wrong passphrases for encrypted wallets.
Fix default filename suffixes in GNOME save dialog.
Make the "Send coins" tab use the configured unit type, even on the first attempt.
Print detailed wallet loading errors to debug.log when it is corrupt.
Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
Workaround for an improbable memory access violation.
Check wallet's minimum version before trying to load it.
Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
Detail reorganization information is better in debug log.
Use a messagebox to display the error when -server is provided without configuring a RPC password.
Testing suite build now honours provided CXXFLAGS.
Removed an extraneous line-break in mature transaction tooltips.
Fix some grammatical errors in the translation process documentation.

===0.5.3<ref>[https://bitcointalk.org/index.php?topic=68895.0 0.5.3 release announcement]</ref>===
Bitcoin version 0.5.3 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the blockchain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets
(issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Skip splash screen when -min is used, and fix Minimize to Tray function.
Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
Correct various labels and messages.
Various memory leaks and potential null pointer deferences have been fixed.
Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
Several shutdown issues have been fixed.
Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
Check that keys stored in the wallet are valid at startup, and if not, report corruption.
Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
Show a message box for --help on Windows, for Bitcoin-Qt.
Add missing "About Qt" menu option to show built-in Qt About dialog.
Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.5.2<ref>[https://bitcointalk.org/index.php?topic=60146.0 0.5.2 release announcement]</ref>===
Bitcoin version 0.5.2 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/

This is a bugfix-only release based on 0.5.1.

Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz

BUG FIXES

Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download).
Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download; this was
not a security vulnerability).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Don't show "IP" for transactions which are not necessarily IP transactions.
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.5.1<ref>[https://bitcointalk.org/index.php?topic=54717.0 0.5.1 release announcement]</ref>===
Bitcoin version 0.5.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukrainian, Portuguese (Brazilian), and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at GitHub; we are no longer
distributing .tar.gz files here, you can get them
directly from GitHub:
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date. Just type
sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===0.5.0<ref>[https://bitcointalk.org/index.php?topic=52480.0 0.5.0 release announcement]</ref>===
Bitcoin version 0.5.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/

The major change for this release is a completely new graphical interface that uses the Qt user interface toolkit.

This release includes German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help:
https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at GitHub:
https://github.com/bitcoin/bitcoin/issues

For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
Bitcoin-Qt: Address Book, then New Address...
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then back up the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

MAJOR GUI CHANGES

"Splash" graphics at startup that show address/wallet/blockchain loading progress.

"Synchronizing with network" progress bar to show the block-chain download progress.

Icons at the bottom of the window show how well connected you are to the network, with tooltips to display details.

Drag and drop support for bitcoin: URIs on web pages.

Export transactions as a .csv file.

Many other GUI improvements, large and small.

RPC CHANGES

getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution

listsinceblock : new RPC command, list transactions since the given block

signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message is signed by the private key is associated with a bitcoin address.

GENERAL CHANGES

Faster initial block download.

==0.4.X==
After 0.4.0, all subsequent releases are stable maintenance releases, 0.5.0 is based on 0.4.0.

===0.4.6<ref>[https://bitcointalk.org/index.php?topic=79651 0.4.6/0.5.5 release announcement]</ref>===
bitcoind version 0.4.6 is now available for download at:
Windows: installer | zip (sig)
Source: tar.gz
bitcoind and Bitcoin-Qt version 0.6.0.7 are also tagged in git, but it is recommended to upgrade to 0.6.1.

These are bugfix-only releases.

Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

BUG FIXES

Version 0.6.0 allowed importing invalid "private keys", which would be unspendable; 0.6.0.7 will now verify the private key is valid, and refuse to import an invalid one
Verify the status of encrypt/decrypt calls to detect failed padding
Check blocks for duplicate transactions earlier. Fixes #1167
Upgrade Windows builds to OpenSSL 1.0.1b
Set label when selecting an address that already has a label. Fixes #1080 (Bitcoin-Qt)
JSON-RPC listtransactions's from/count handling is now fixed
Optimize and fix multithreaded access, when checking whether we already know about transactions
Fix potential networking deadlock
Proper support for Growl 1.3 notifications
Display an error, rather than crashing, if encoding a QR Code failed (0.6.0.7)
Don't erroneously set "Display addresses" for users who haven't explicitly enabled it (Bitcoin-Qt)
Some non-ASCII input in JSON-RPC expecting hexadecimal may have been misinterpreted rather than rejected
Missing error condition checking added
Do not show a green tick unless all known blocks are downloaded. Fixes #921 (Bitcoin-Qt)
Increase time ago of the last block for "up to date" status from 30 to 90 minutes
Show a message box when a runaway exception happens (Bitcoin-Qt)
Use a messagebox to display the error when -server is provided without providing a rpc password
Show error message instead of exception crash when unable to bind RPC port (Bitcoin-Qt)
Correct sign message bitcoin address tooltip. Fixes #1050 (Bitcoin-Qt)
Removed "(no label)" from QR Code dialog titlebar if we have no label (0.6.0.7)
Removed an ugly line break in tooltip for mature transactions (0.6.0.7)
Add missing tooltip and key shortcut in settings dialog (part of #1088) (Bitcoin-Qt)
Work around an issue in boost::program_options that prevents from compiling in clang
Fixed bugs occurring only on platforms with unsigned characters (such as ARM).
Rename make_windows_icon.py to .sh as it is a shell script. Fixes #1099 (Bitcoin-Qt)
Various trivial internal corrections to types used for counting/size loops and warnings

===0.4.5===
(No known forum post.)

===0.4.4<ref>[https://bitcointalk.org/index.php?topic=70566.0 0.4.4 release announcement]</ref>===
Bitcoin version 0.4.4 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at GitHub:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz

BUG FIXES

Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922).
Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
Various memory leaks and potential null pointer deferences have been
fixed.
Several shutdown issues have been fixed.
Check that keys stored in the wallet are valid at startup, and if not,
report corruption.
Various build fixes.
If no password is specified to bitcoind, recommend a secure password.
Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
Add checkpoint at block 168,000.

===0.4.3<ref>[https://bitcointalk.org/index.php?topic=57734.0 0.4.3 release announcement]</ref>===
bitcoind version 0.4.3 is now available for download at:
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge)

This is a bugfix-only release based on 0.4.0.

Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr.

Please report bugs for the daemon only using the issue tracker at GitHub:
https://github.com/bitcoin/bitcoin/issues

Stable source code is hosted at Gitorious:
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz

BUG FIXES

Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticeable during initial blockchain download).
Fixed some address-handling deadlocks (client freezes).
No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).

===0.4.2===
(No known forum post.)

===0.4.1<ref>[https://bitcointalk.org/index.php?topic=52503.0 0.4.1 release announcement]</ref>===
Bitcoin version 0.4.1 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/

This is a bugfix only release based on 0.4.0.

Please report bugs by replying to this forum thread.

MAJOR BUG FIX (CVE-2011-4447)

The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who
managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the
associated coins.

If you have a previously encrypted wallet.dat, the first time you run wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will
shut down, and you will be prompted to restart it to run with the new, properly encrypted file.

If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public
location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses.

Wallets encrypted with this version of Bitcoin are written properly.

Technical note: the encrypted wallet's 'keypool' will be regenerated the first time you request a new bitcoin address; to be certain that the
new private keys are properly backed up you should:

1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
wxBitcoin: new address visible on main window
bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up.

"Security in depth" is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins.

Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.

===0.4.0<ref>[https://bitcointalk.org/index.php?topic=45410.0 0.4 release announcement]</ref>===
Bitcoin version 0.4.0 is now available for download at:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)

Wallet Encryption

Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu. You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins. If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet. This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet. To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP). Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet. Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

==0.3.X==

===0.3.24<ref>[https://bitcointalk.org/index.php?topic=27187.0 0.3.24 release announcement]</ref>===
Bitcoin v0.3.24 is now available for download at
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/

This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed -- most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4.

Notable fixes in v0.3.24, and the main reasons for this release:

F1) Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits.

F2) Fix crash caused by loss/lack of network connection.

Notable changes in v0.3.24:

C1) DNS seeding enabled by default.

C2) UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of "-upnp" to help the network!)

C3) Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome.

C4) Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4's wallet encryption.

===0.3.23<ref>[https://bitcointalk.org/index.php?topic=16553.0 0.3.23 release announcement]</ref>===
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/

This is another quick bugfix release, trying to deal with the influx of new bitcoin users.

Main items of note:

* P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better "leaf node" logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network.
* Transaction fee reduced to 0.0005 for new transactions
* Client will relay transactions with fees as low as 0.0001 BTC

===0.3.22<ref>[https://bitcointalk.org/index.php?topic=12269.0 0.3.22 release announcement]</ref>===
Download URL: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

Notable changes:
* Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)
* Non-standard transactions accepted on testnet
* Source code tree reorganized (prep for autotools build)
* Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.
* IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99
* DNS names now may be used with -addnode, -connect (requires -dns to enable)

RPC changes:
* 'listtransactions' adds 'from' param, for range queries
* 'move' may take account balances negative
* 'settxfee' added, to manually set TX fee

===0.3.21<ref>[https://bitcointalk.org/index.php?topic=6642.0 0.3.21 release announcement]</ref>===
Binaries for Bitcoin version 0.3.21 are available at:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features from the 0.3.20 release include:

* Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box.

* Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001).

* A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable.

For developers, changes to bitcoin's remote-procedure-call API:

* New rpc command "sendmany" to send bitcoins to more than one address in a single transaction.

* Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

* -logtimestamps option, to add a timestamp to each line in debug.log.

* Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions.

===0.3.20.2<ref>[https://bitcointalk.org/index.php?topic=4167.0 0.3.20.2 release announcement]</ref>===
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.

The Amazon Machine Images I used to do the builds are available:

ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64

(mac build will be done soon)

If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:

maxsendbuffer=10000
maxreceivebuffer=10000

... or download the new version.

===0.3.20.1===
(No known forum post.)

===0.3.20<ref>[https://bitcointalk.org/index.php?topic=2953.0 0.3.20 release announcement]</ref>===
Please checkout the git integration branch from:

https://github.com/bitcoin/bitcoin

... and help test. The new features that need testing are:

* -nolisten : https://github.com/bitcoin/bitcoin/pull/11
* -rescan : scan block chain for missing wallet transactions
* -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
* RPC gettransaction details : https://github.com/bitcoin/bitcoin/pull/24
* listtransactions new features : https://github.com/bitcoin/bitcoin/pull/10

Bug fixes that also need testing:

* -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
* RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
* RPC move, add time to output : https://github.com/bitcoin/bitcoin/pull/21
* ...and several improvements to --help output.

This needs more testing on Windows! Please drop me a quick private message, email, or IRC message if you are able to do some testing. If you find bugs, please open an issue at:

https://github.com/bitcoin/bitcoin/issues

===0.3.19<ref>[https://bitcointalk.org/index.php?topic=2228.0 0.3.19 release announcement]</ref>===
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

===0.3.18<ref>[https://bitcointalk.org/index.php?topic=2162.0 0.3.18 release announcement]</ref>===

Changes:
* Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
* IsStandard() check to only include known transaction types in blocks
* Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at https://bitcointalk.org/index.php?topic=1886.0).
* getaccountaddress
* sendfrom
* move
* getbalance
* listtransactions

===0.3.17<ref>[https://bitcointalk.org/index.php?topic=1946.0 0.3.17 release announcement]</ref>===

Version 0.3.17 is now available.

Changes:
* new getwork, thanks m0mchil
* added transaction fee setting in UI options menu
* free transaction limits
* sendtoaddress returns transaction id instead of "sent"
* getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

===0.3.16===

Never released.

===0.3.15<ref>[https://bitcointalk.org/index.php?topic=1780.0 0.3.15 release announcement]</ref>===

* paytxfee switch is now per KB, so it adds the correct fee for large transactions
* sending avoids using coins with less than 6 confirmations if it can
* BitcoinMiner processes transactions in priority order based on age of dependencies
* make sure generation doesn't start before block 74000 downloaded
* bugfixes by Dean Gores
* testnet, keypoololdest and paytxfee added to getinfo

===0.3.14<ref>[https://bitcointalk.org/index.php?topic=1528.0 0.3.14 release announcement]</ref>===

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
* Key pool feature for safer wallet backup
Gavin Andresen:
* TEST network mode with switch -testnet
* Option to use SSL for JSON-RPC connections on unix/osx
* validateaddress RPC command
eurekafag:
* Russian translation

===0.3.13<ref>[https://bitcointalk.org/index.php?topic=1327.0 0.3.13 release announcement]</ref>===

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
* Don't count or spend payments until they have 1 confirmation.
* Internal version number from 312 to 31300.
* Only accept transactions sent by IP address if -allowreceivebyip is specified.
* Dropped DB_PRIVATE Berkeley DB flag.
* Fix problem sending the last cent with sub-cent fractional change.
* Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
* Option -rpcallowip= to accept json-rpc connections from another machine.
* Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

===0.3.12<ref>[https://bitcointalk.org/index.php?topic=999.0 0.3.12 release announcement]</ref>===

Version 0.3.12 is now available.

Features:
* json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
* json-rpc command line returns exit codes.
* json-rpc "backupwallet" command.
* Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
https://bitcointalk.org/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

=References=
<references/>

Enabling SSL on original client daemon

2022-09-26T07:51:49Z

AllEd01: spelling, grammar

SSL for RPC in Bitcoin Core client, was '''removed and is no longer available''' (as of 2019.03) apparently in commit 40b556d374 .

Even before its removal, it was criticized for some time.

=== Historical comments ===

(this no longer applies as RPC SSL was removed).

JSON-RPC over [https://en.wikipedia.org/wiki/Secure_Sockets_Layer SSL] is strongly discouraged

"The RPC interface isn't designed to be used in any scenario which would require SSL, which would be accessed over the internet or other untrusted networks. It doesn't have the necessary denial of service protections or review to make it safe for use this way, and so letting potentially malicious clients connect to it would be incredibly unwise. If you need to talk to a remote bitcoind instance you are better off tunneling with SSH or stunnel which will provide a secure, authenticated path without exposing the socket any further than localhost."

-[https://bitcoin.stackexchange.com/questions/39117/why-is-json-rpc-over-ssl-strongly-discouraged Bitcoin(StackExchange, August 17th, 2015)]

Bitcoin Core

2022-09-26T07:50:32Z

AllEd01: grammar, spelling

'''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
* Bitcoin Core uses OpenTimestamps.org to timestamp merge commits.<ref>{{cite web|url=https://github.com/bitcoin/bitcoin/blob/ebd786b72a2a15143d7ef4ea2229fef121bd8f12/contrib/devtools/README.md#create-and-verify-timestamps-of-merge-commits|title=Bitcoin Core devtools README - Create and verify timestamps of merge commits|date=|website=GitHub|archive-url=|archive-date=|accessdate=May 5, 2018}}</ref>
* Checkpoints that have been hard coded into the client are used only to prevent Denial of Service attacks against nodes that are initially syncing the chain. For this reason, the checkpoints included are only as of several years ago.<ref name="check">{{cite web |url=https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp |title=checkpoints.cpp |work=Repository source code |publisher=GitHub, Inc. |accessdate=13 November 2016 }}</ref><ref>{{cite web |title=bitcoin/chainparams.cpp |url=https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp |website=GitHub |accessdate=21 October 2018}}</ref>
* A network alert system was included by Satoshi Nakamoto as a way of informing users of important news regarding bitcoin.<ref name="asr">{{cite web |url=https://bitcoin.org/en/alert/2016-11-01-alert-retirement |title=Alert System Retirement |date=1 November 2016 |publisher=Bitcoin Project |accessdate=16 November 2016 }}</ref> In November 2016 it was retired. It had become obsolete as news on bitcoin is now widely disseminated.

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

==Development==
The original creator of the bitcoin client has described their approach to the software's authorship as it being written first to prove to themselves that the concept of purely peer-to-peer electronic cash was valid and that a paper with solutions could be written. The lead developer is Wladimir J. van der Laan, who took over the role on 8 April 2014.<ref name="hunt"/> [[Gavin Andresen]] was the former lead maintainer for the software client. Andresen left the role of lead developer for bitcoin to work on the strategic development of its technology.<ref name="hunt">Bitcoin: The Hunt of Satoshi Nakamoto, Alex Preukschat, Josep Busquet, 2015, Europe Comics, ISBN 9791032800201, page 87 [https://play.google.com/store/books/details?id=438FCwAAQBAJ]</ref> Bitcoin Core developers have been in charge of bitcoin's development since [[Satoshi Nakamoto]] left the project.<ref name="wtbf">{{Cite news |url=https://www.forbes.com/sites/laurashin/2017/10/23/will-this-battle-for-the-soul-of-bitcoin-destroy-it/#62d19db23d3c |title=Will This Battle For The Soul Of Bitcoin Destroy It? |author=Laura Shin |accessdate=14 April 2018 |date=23 October 2017 |work=Forbes }}</ref> Bitcoin Core in 2015 was central to a dispute with [[Bitcoin XT]], a competing client that sought to increase the blocksize.<ref name="NewYorker">{{Cite news |url=https://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future
|title=Inside the Fight Over Bitcoin’s Future |author=Maria Bustillos |accessdate=29 June 2020 |date=25 August 2015 |work=New Yorker}}</ref> Over a dozen different companies and industry groups fund the development of Bitcoin Core.<ref>{{cite web|url=https://blog.bitmex.com/who-funds-bitcoin-development/|title=Who Funds Bitcoin Development?|date=2020-03-28|publisher=BitMex Research|access-date=2020-06-30}}</ref>

[https://www.youtube.com/watch?v=FIt7GLxxIpY Visualization of code changes during 2015]

==Version history==
Bitcoin 0.1 was released on 9 January 2009 by Satoshi Nakamoto with only Windows supported. This was followed by some minor bug-fixing versions. On 16 December 2009 Bitcoin 0.2 was released. It included a Linux version for the first time and made use of multi-core processors for mining. In version 0.3.2 Nakamoto included checkpoints as a safeguard. After the release of version 0.3.9, Satoshi Nakamoto left the project and shortly after stopped communicating on online forums.

Between 2011 and 2013 new versions of the software were released at Bitcoin.org.<ref name="abo">{{cite web |url=https://bitcoin.org/en/about-us#sponsorship |title=About bitcoin.org |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Developers wanted to differentiate themselves as creators of software rather than advocates for bitcoin and so now maintain bitcoincore.org for just the software.

Bitcoin-Qt version 0.5.0 was released on 1 November 2011. It introduced a front end that uses the Qt user interface toolkit.<ref name="bqt">{{cite web |url=https://bitcoin.org/en/release/v0.5.0 |title=Bitcoin-Qt version 0.5.0 released |date=1 November 2011 |publisher=Bitcoin Project |accessdate=13 November 2016 }}</ref> The software previously used Berkeley DB for database management. Developers switched to LevelDB in release 0.8 in order to reduce blockchain synchronization time ([[initial block download]], beware, a misnomer). The update to this release resulted in a minor blockchain fork on the 11 March 2013. The fork was resolved shortly afterward. Seeding nodes through Internet Relay Chat was discontinued in version 0.8.2. From version 0.9.0 the software was renamed Bitcoin Core. Transaction fees were reduced again by a factor of ten as a means to encourage microtransactions. Although Bitcoin Core does not use OpenSSL for the operation of the network, the software did use OpenSSL for remote procedure calls. Version 0.9.1 was released to remove the network's vulnerability to the Heartbleed bug.

Release 0.10 was made public on 16 February 2015. It introduced a consensus library which gave programmers easy access to the rules governing consensus on the network. In version 0.11.2 developers added a new feature which allowed transactions to be made unspendable until a specific time in the future.<ref name="v0.11.2">{{cite web |url=https://bitcoin.org/en/release/v0.11.2 |title=Bitcoin Core version 0.11.2 released |date=13 November 2015 |publisher=Bitcoin Project |accessdate=14 November 2016 }}</ref> Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently.<ref name="0.12.1rel">{{Cite news |url=http://www.nasdaq.com/article/bitcoin-core-0121-released-major-step-forward-for-scalability-cm607209 |title=Bitcoin Core 0.12.1 Released, Major Step Forward for Scalability |author=Kyle Torpey |accessdate=7 November 2016 |date=15 April 2016 |work=Bitcoin Magazine |publisher=NASDAQ.com }}</ref> Around 100 contributors worked on Bitcoin Core 0.13.0 which was released on 23 August 2016.

In July 2016, the CheckSequenceVerify soft fork was activated.<ref>Mastering Bitcoin: Programming the Open Blockchain. Quote "BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to the consensus rules."</ref>

In October 2016, Bitcoin Core’s 0.13.1 release featured the "[[Segwit]]" soft fork that included a scaling improvement aiming to optimize the bitcoin block size. The patch was originally finalized in April and 35 developers were engaged to deploy it. This release featured Segregated Witness ([[SegWit]]) which aimed to place downward pressure on transaction fees as well as increase the maximum transaction capacity of the network.<ref name="rel13.1">{{cite web |url=https://bitcoincore.org/en/releases/0.13.1/ |title=Bitcoin Core 0.13.1 |publisher=Bitcoin Core |accessdate=25 October 2016 }}</ref> The 0.13.1 release endured extensive testing and research leading to some delays in its release date. SegWit prevents various forms of transaction malleability.<ref name="swb">{{cite web|url=https://bitcoincore.org/en/2016/01/26/segwit-benefits/|title=Segregated Witness Benefits|last=|first=|date=January 26, 2016|work=Bitcoin Core|archive-url=|archive-date=|accessdate=October 20, 2018}}</ref>

In September 2018, a Bitcoin Cash developer discovered the vulnerability CVE 2018-17144 in the Bitcoin Core software that could allow an attacker to crash vulnerable Bitcoin Core nodes and exceed the 21 million coin limit.<ref>{{Cite news|url=https://bitcoincore.org/en/2018/09/20/notice/|title=CVE-2018-17144 Full Disclosure|work=Bitcoin Core|access-date=2018-09-23|language=en}}</ref>

==Bitcoin Improvement Proposals==
A [[Bitcoin Improvement Proposal]] (BIP) is a design document, typically describing a new feature for Bitcoin with a concise technical specification of the feature and the rationale for it. Bitcoin Core implements some of these design documents.

==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}}

Contingency plans

2022-09-26T07:44:18Z

AllEd01: spelling, grammar

The purpose of this page is to create plans for the first few days after a catastrophic failure of the network in order to save time should any such failure actually occur.

Only failures that would not allow much time for discussion will be covered here. ''Preventing'' future problems will not be discussed.

Once the plans themselves are well-accepted, code implementing the plans can be written and tested in case the code is ever required.

==Getting the word out==

===Alerts===
These people have [[alerts|alert keys]] and should be contacted ASAP in case of emergencies:
* Satoshi
* Gavin
* theymos
Email Satoshi, even though he is believed to be gone. A serious issue may "bring him out of retirement", which would be helpful.

Because alerts are known to be very secure, all information related to an emergency should be sent with alerts. For example, hashes of new releases should be included in alerts.

The most important part of alert messages should be put at the front since the remaining text might get cut off. A good way to begin would be: "EMERGENCY: DO NOT ACCEPT OR SEND PAYMENTS".

===Pools===
The owners of all pools must be contacted, as changes will be required of them.

===IRC===
The relevant [[IRC_channels]] should have their topics updated to spread info about the emergency.

===Forum===
A topic should be posted in "development and technical discussion", and a sticky locked topic pointing to the main topic should be created in all other sections. The main topic should not be sticky, as this makes it more difficult to see and it will be bumped to the top constantly, anyway.

===Sites===
The owners of all big sites, especially exchanges and banks, should be contacted.

===Stock message===
Here is a message that could be used to spread the word. Preferably it would be updated to reflect specifics and signed by some trusted people.

A critical bug has been discovered in Bitcoin. Transactions must be considered REVERSIBLE for the time being. Do not send payments, and do not trust the payments that you receive.

If you run a Bitcoin-related site, shut down the site and replace it with this message.

[Note: The following paragraph only applies to certain attacks and may need to be removed.]

If you are solo mining or running a pool, you must stop mining until you upgrade to the latest version (which may not be released quite yet). If you are mining in a pool, shut down your miner until your pool upgrades. If you continue mining, any blocks you solve will end up being rejected eventually, and you will be working against the legitimate chain.

Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty. The most trustworthy source of information is the text that appears at the bottom of the graphical Bitcoin client.

==Coordination==

During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is, therefore, best if general discussion about the emergency takes place there.

Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with [[gribble]] if possible. Mode +m may also need to be set if there is too much spam.

===Backup communication methods===
It is not impossible for an attacker to make #bitcoin-dev unusable, either through abuse or denial-of-service attacks. There must be several backup methods of communication.

====IRC====

If #bitcoin-dev becomes unusable due to flooding or other abuse that the Freenode IRC operators are unable/unwilling to handle, then moving #bitcoin-dev to irc.lfnet.org will be useful. The operators of LFnet are Bitcoin users who will be very helpful in fighting abuse.

If Freenode is taken down by a denial-of-service attack, #bitcoin-dev can be moved to one of the larger networks, which will (presumably) be more resistant to attacks.

So if the regular #bitcoin-dev is broken, try #bitcoin-dev on these networks:
* LFnet
* IRCnet
* EFnet
* Undernet
* Any other IRC networks you know of

Gribble can be moved to any network in order to facilitate GPG identification.

====Other real-time chat====

In case all IRC networks are made unusable, Google+ multi-user chat might work well, and it is unlikely to be brought down by denial-of-service attacks.

(A distributed chat network where every participant needs to send his message directly to all other participants would be best, as this would be difficult to attack. Does something like this exist?)

====Non-realtime communication====

The SourceForge mailing list can be used for non-real-time communication. In case this list is brought down, participants can send emails manually to a list of people.

===Issuing statements===
When it has been decided by the developers that action is required by Bitcoin users, a statement will be issued. All statements should contain text encouraging people to distribute the statement. Statements should be numbered sequentially from the start of the incident.

Statements should be PGP signed by a few people present at the time and then emailed to owners of big sites and posted on bitcoin.org and the forums.

An alert summarizing the statement will probably need to be issued, as well.

===Emergency versions===
Emergency versions of Bitcoin should preferably be based on the latest stable versions instead of the very latest code in order to avoid introducing new bugs.

Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases built using the standard [[release process]] (instead of using binaries provided by third parties).

==Contingencies==
===Many historical blocks replaced===

Situation: 6+ historical blocks have been replaced by new versions all at once, allowing confirmed transactions to be invalidated.

====Impact====

* People who have received payments from the attacker might have these payments reversed.
* The double-spent versions of these transactions might immediately get 6+ confirmations. So people receiving the attacker's stolen coins might accept them.
* Other transactions may become unconfirmed again.

====Response====

* Alert users to stop accepting payments, as an attacker clearly has too much control over the network. The network will be unusable for weeks or more while the issue is straightened out.

If more than a few BTC was stolen by the attacker, then the transaction order may need to be manually modified. This is done by adding new block checkpoints and/or hardcoding transaction ordering [note: code should be prepared for hardcoded transaction ordering].

A lot of time should be taken to decide whether and how to re-order the transactions. It may be a very complex issue, as restoring the original versions of transactions could cause damage many times larger than the original transaction reversal. The network will need to be offline for a week or more after an incident of this scale, anyway.

===SHA-256 is broken===
Situation: Severe, 0-day failure of SHA-256. First/second preimage resistance or collision resistance can be defeated with only a few days of work.

====Impact====

* Attacker may be able to defeat OP_CHECKSIG, which hashes transactions before signing.
* Attacker may be able to split the network by creating identical transactions or blocks with the same hashes.
* Attacker may be able to create blocks very quickly.
* The alert system may be compromised.

====Response====

* Users will be notified to shut down their clients. Note that the attacker may be able to send valid alerts, which could disrupt notification efforts.
* OP_CHECKSIG will be changed to use some other hash outside of old blocks.
* All addresses in the version-1 chain that have a known public key and at least one unspent output will have their public keys hardcoded into the client. When a version-2 transaction spends one of these version-1 outputs, the hardcoded public key will be used instead of the hash.
* The version-1 chain will be securely hashed into a hash tree. At least the root of the version-1 tree will be hardcoded into the client.
* All hashing Bitcoin does will use the new hashing algorithm.

[Code for all of this should be prepared.]

===ECDSA is broken===
Situation: an attacker can sign for a public key that he does not own the private key for in only a few days of work.

====Impact====
* Attacker can spend money that is not his in a large number of cases. Transactions to addresses that have never been used before may be protected if SHA-256 and RIPEMD-160 are still strong.
* Alert system may be compromised.

====Response====

If the attacker can't get the private key from the public key easily and a stronger algorithm that can use ECDSA keys is available:
* Switch to the stronger algorithm.
* Get users to update. Alerts will be compromised.

Otherwise:
* OP_CHECKSIG should use some other signing algorithm.
* As soon as the new version of Bitcoin is run, it should automatically send all old transactions somewhere else using the new algorithm.
* Get users to update immediately. Alerts will be compromised.

[Code for all of this should be prepared.]

===Remote attacker can execute arbitrary code===
Situation: Due to a bug in Bitcoin, a remote attacker is able to run arbitrary code on the machines of some/all Bitcoin users.

====Impact====
* Attacker can install malware, which could be used to steal private keys from wallets that are decrypted while the malware is installed.

====Response====
* Issue an alert telling people to shut down their clients immediately and look for updates elsewhere. Put special effort into alerting people through other means.
* Remove critical powers (git push, bitcoin.org update, IRC op, etc.) from people who do not need them, as all Bitcoin users are at a high risk of having their passwords compromised. Trust GPG signatures a bit less than usual.

Stock alert message: "EMERGENCY: SHUT DOWN YOUR CLIENT RIGHT NOW! Look for updates on popular Bitcoin sites. A bug has been discovered that can allow a remote attacker to install malware on your computer through Bitcoin."

Stock statement:

A bug has been discovered in Bitcoin that can allow a remote attacker to execute arbitrary code. The attacker could install malware onto your computer, which could steal your wallet. Shut down Bitcoin now. Under no circumstances should you enter your wallet passphrase until this incident is resolved and you have made absolutely sure that there is no malware on your computer. If possible, carefully copy your wallet to some offline safe location and then securely delete the copy on your computer.

Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty.

===Emergency rule change===
Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the [[Incidents#CVE-2010-5139|overflow incident]].

====Response====
* Issue an alert. Tell people to stop mining.
* After the issue is fixed, get people to update.

It is preferable to make a rule more restrictive than to relax a rule. In the former case, only miners need an update.

BTCrow

2022-09-26T07:42:38Z

AllEd01: grammar, spelling

An escrow-like service that allows safer payment by securely holding a buyer's coins in escrow until the terms of the sale are met.

Warning: Please be careful with your money. When sending money to an escrow partner you are trusting that the operator will not abscond with your funds and that the operator maintains secure systems that protect against theft -- internal or external. It is recommended that you obtain the real-world identity of the operator and ensure that sufficient recourse is available. Exchanging or storing significant amounts of funds for others is not recommended.

==Fees==

The service charges a 1% escrow fee which includes potential dispute resolution.

==Dispute Resolution==

# Buyer and Seller Agree to Terms
#* After Creating the bitcoin escrow at BTCrow.com, both parties agree to the terms of the transaction, which include a description of the merchandise, sale price, and method of escrow.
# Buyer Pays BTCrow.com
#* The Buyer submits funds to BTCrow. BTCrow.com verifies the payment with network confirmations. Processing time varies depending if the transaction takes time to be included in a block.
# Seller Ships Merchandise
#* Upon payment verification, the Seller is authorized to ship the merchandise and submit tracking information.
# Buyer Accepts the Merchandise
#* The Buyer accepts or refuses the merchandise. In case of refusal, the buyer initiates a dispute.
# BTCrow.com Pays the Seller
#* BTCrow.com pays the Seller in bitcoin for the amount agreed at point no 1. The transaction is complete.

It is strongly recommended to sellers to have proof of item(s) delivery or proof that the service(s) was completed in order for the escrow service to manage disputes.

==History==

The site was launched on June 23rd, 2011<ref>[http://bitcointalk.org/index.php?topic=21544.0 BTCrow.com - New Bitcoin Escrow Service]</ref>.

In March, 2012 the service had gone offline, reportedly due to an extended distributed denial-of-service (DDoS) attack<ref>[http://bitcointalk.org/index.php?topic=21544.msg926817#msg926817 Site back online after DDoS]</ref>.

On May 28th, 2012 the operator announced a partnership with another service, [[BitcoinOPX]], and provided identity information<ref>[http://bitcointalk.org/index.php?topic=84092.0 Trade Bitcoin Options - BitcoinOPX.com]</ref>.

In December 2015 the service was listed for sale, [http://cointelegraph.com/news/115957/the-first-and-most-reputable-btc-escrow-is-for-sale Article]

As of 2016, the site is closed and coming back soon
==See Also==

* [[Secure Trading]]

==External Links==

* [http://BTCrow.com BTCrow] web site

==References==
<references />

[[Category:Escrow services]]

Proof of Stake

2022-09-26T07:40:51Z

AllEd01: spelling, grammar

Proof of Stake is a proposed alternative to [[Proof of Work]]. Like proof of work, proof of stake attempts to provide consensus and [[Double-spending|doublespend]] prevention (see [https://bitcointalk.org/index.php?topic=68213.0 "main" bitcointalk thread], and a [https://bitcointalk.org/index.php?topic=96854.0 Bounty Thread]). Because creating forks is costless when you aren't burning an external resource Proof of Stake alone is considered to an unworkable consensus mechanism.<ref>https://download.wpsoftware.net/bitcoin/pos.pdf</ref>

It was probably first proposed [https://bitcointalk.org/index.php?topic=27787.0 here] by a member named [https://bitcointalk.org/index.php?action=profile;u=241 QuantumMechanic]. With Proof of Work, the probability of mining a block depends on the work done by the miner (e.g. CPU/GPU cycles spent checking hashes). With Proof of Stake, the resource that's compared is the amount of Bitcoin a miner holds - someone holding 1% of the Bitcoin can mine 1% of the "Proof of Stake blocks".

Some argue that methods based on Proof of Work alone might lead to a low network security in a cryptocurrency with block incentives that decline over time (like bitcoin) due to [[Tragedy of the Commons]], and Proof of Stake is one way of changing the miner's incentives in favor of higher network security.

= Motivation For Proof of Stake =

* A proof-of-stake system might provide increased protection from a malicious attack on the network. Additional protection comes from two sources:
*# Executing an attack would be much more expensive.
*# Reduced incentives for attack. The attacker would need to own a near majority of all bitcoin. Therefore, the attacker suffer severely from his own attack.

* When block rewards are produced through txn fees, a proof of stake system would result in lower equilibrium txn fees. Lower long-run fees would increase the competitiveness of bitcoin relative to alternative payments systems. Intuitively reduced fees are due to vast reductions in the scale of wastage of resources.
== The Monopoly Problem ==

If a single entity (hereafter a monopolist) took control of the majority of txn verification resources, he could use these resources to impose conditions on the rest of the network. Potentially, the monopolist could choose to do this in malicious ways, such as double spending or denying service. If the monopolist chose a malicious strategy and maintained his control for a long period, confidence in bitcoin would be undermined and bitcoin purchasing power would collapse. Alternatively, the monopolist could choose to act benevolently. A benevolent monopolist would exclude all other txn verifiers from fee collection and currency generation, but would not try to exploit currency holders in any way. In order to maintain a good reputation, he would refrain from double spends and maintain service provision. In this case, confidence in Bitcoin could be maintained under monopoly since all of its basic functionality would not be affected.

Both benevolent and malevolent monopoly are potentially profitable, so there are reasons to suspect that an entrepreneurial miner might attempt to become a monopolist at some point. Due to the [[Tragedy of the Commons]] effect, attempts at monopoly become increasingly likely over time.

== How Proof of Stake Addresses Monopoly Problems ==

Monopoly is still possible under proof-of-stake. However, proof-of-stake would be more secure against malicious attacks for two reasons.

Firstly, proof-of-stake makes establishing a verification monopoly more difficult. At the time of writing, an entrepreneur could achieve monopoly over proof-of-work by investing at most 10 million USD in computing hardware. The actual investment necessary might be less than this because other miners will exit as difficulty increases, but it is difficult to predict exactly how much exit will occur. If the price remained constant in the face of extremely large purchases (unlikely), such an entrepreneur would need to invest at least 20 million USD to obtain monopoly under proof-of-stake. Since such a large purchase would dramatically increase the bitcoin price, the entrepreneur would likely need to invest several times this amount. Thus, even now proof-of-stake monopoly would be several-fold more costly to achieve than proof-of-work monopoly. Over time the comparison of monopoly costs will become more and more dramatic. The ratio of bitcoin's mining rewards to market value is programmed to decline exponentially. As this happens, proof-of-work monopoly will become easier and easier to obtain, whereas obtaining proof-of-stake monopoly will become progressively more difficult as more of the total money supply is released into circulation.

Secondly, and perhaps more importantly, a proof-of-stake monopolist is more likely to behave benevolently exactly because of his stake in Bitcoin. In a benevolent monopoly, the currency txn continues as usual, but the monopolist earns all txn fees and coin generations. Other txn verifiers are shut out of the system, however. Since mining is not source of demand for bitcoin, bitcoin might retain most of its value in the event of a benevolent attack. Earnings from a benevolent attack are similar regardless of whether the attack occurs under proof-of-stake or proof-of-work. In a malicious attack, the attacker has some outside opportunity that allows profit from bitcoin's destruction (simple double-spends are not a plausible motivation; ownership of a competing payment platform is). At the same time, the attacker faces costs related to losses on bitcoin-specific investments which are necessary for the attack. It can be assumed that a malicious attack causes the purchasing power of bitcoin to fall to zero. Under such an attack, the proof-of-stake monopolist will lose his entire investment. By contrast, a malicious proof-of-work monopolist will be able to recover much of their hardware investment through resale. Recall also, that the necessary proof-of-work investment is much smaller than the proof-of-stake investment. Thus, the costs of a malicious attack are several-fold lower under proof-of-work. The low costs associated with malicious attack make a malicious attack more likely to occur.

== Why Proof of Stake Would Likely Decrease Long-run Txn Fees Considerably ==
In a competitive market equilibrium, the total volume of txn fees must be equal to opportunity cost of all resources used to verify txns. Under proof-of-work mining, opportunity cost can be calculated as the total sum spent on mining electricity, mining equipment depreciation, mining labor, and a market rate of return on mining capital. Electricity costs, returns on mining equipment, and equipment depreciation costs are likely to dominate here. If these costs are not substantial, then it will be exceptionally easy to monopolize the mining network. The fees necessary to prevent monopolization will be onerous, possibly in excess of the 3% fee currently charged for credit card purchases. Under pure proof-of-stake, opportunity cost can be calculated as the total sum spent on mining labor and the market interest rate for risk-free bitcoin lending (hardware-related costs will be negligible). Since bitcoins are designed to appreciate over time due to hard-coded supply limitations, interest rates on risk-free bitcoin-denominated loans are likely to be negligible. Therefore, the total volume of txn fees under pure proof-of-stake will just need to be just sufficient to compensate labor involved in maintaining bandwidth and storage space. The associated txn fees will be exceptionally low. Despite these exceptionally low fees, a proof-of-stake network will be many times more costly to exploit than the proof-of-work network. Approximately, a proof-of-work network can be exploited using expenditure equal to about one years worth of currency generation and txn fees. By contrast, exploitation of a proof-of-stake network requires the purchase of a majority or near majority of all extant coins.

= Implementation =
There are currently a few distinct proposals on how to implement PoS

== Cunicula's Implementation of Mixed Proof-of-Work and Proof-of-Stake ==

This suggestion is of a mixed Proof-of-Work / Proof-of-Stake system.

=== Cunicula's Note ===
Check the page history for the older implementation. I am replacing my description with a new system which I believe to be much more secure. The new system is a greatly improved version of Coblee's Proof of Activity [https://bitcointalk.org/index.php?topic=102355.0 proposal]. It provides extremely strong protection against PoW attacks, both double-spends, and denials of service. It is not vulnerable even if PoW attackers also have a substantial (but non majority) stake. It provides strong incentives to maintain full nodes. The system is supported through taxes on coin owners who fail to maintain full nodes. Tax revenue is redistributed to coin owners who maintain full nodes. The maintenance of full nodes is the key element providing security in the system.

The discussion focuses on the long-term maintenance of the system. Initial distribution of coins could occur through PoW mining, an IPO mechanism, or a more complex scheme that allows initial coins to be distributed to both PoW miners and businesses voted for by coin owners. The issue of initial distribution is separate from long-term maintenance and it is confusing to discuss the two together.

=== Glossary ===
Voluntary Signatures - Voluntary signatures result from random auditing processes. As blocks are mined, keys are selected for auditing based on random selection. The signatures provide public evidence that a public key owner is running a full node. Passing the audit allows a private key to remaining active.

Active Keys - By default, public keys that appear in the blockchain are active if they have a balance of at least one full coin. Public keys that provide voluntary signatures when randomly audited remain active. Active public keys are eligible to participate in lotteries to sign PoW blocks and mine PoS blocks. This is remunerative. Public keys that fail to provide signatures become dead private keys.

Dead Keys - Keys that have failed to provide signatures lose lottery eligibility. Keys that have balances of less than 1 coin are considered dead by default. Dead keys can no longer mine PoS blocks. However, these dead keys can still be used to generate txns. Network maintenance is supported primarily through mandatory fees levied on coins sent by dead keys. After coins are sent using a dead key, the key becomes active provided that it retains a balance of at least 1 coin.

Mandatory Signature Sequence - In order for a PoW block to be valid and enter the blockchain, it must be signed by a sequence of 5 randomly selected active keys. The fifth signatory in the sequence mines a PoS block.

PoS block - The fifth signatory of a PoW block must mint his own block without any PoW submission at all. This block is called a PoS block.

Coin-age - Coin age refers to the age of txn inputs. Coin age is equal to the number of coins sent times the average age on these coins. Age is measured in blocks. Age is reset to 1 block whenever a coin is sent AND whenever a coin provides a signature (both mandatory and voluntary signatures count). Coin-age is used to calculate mandatory fees.

Demurrage Fee - Chain Security is supported primarily through a demurrage tax on sent inputs. This tax is proportional to the average input age as measured in coin-years. I suggest 5% per coin-year as a reasonable fee. Active keys can avoid demurrage fees simply by remaining active. Thus the actual fee generation will be much lower than 5% per year. Dead keys must pay demurrage. The opportunity to evade demurrage motivates activity.

Optional Fee - Fees are used to ration block space. Blocks select prioritize txns with high fees. If demurrage fees alone are insufficient to motivate txn inclusion, the user can add an optional fee to his txn.

Fee Fund - Both optional fees and demurrage fees enter a fund, rather than being distributed directly to miners. Fees are added to the fund immediately, so there is a weak incentive to include high fee txns in blocks. The PoW miner receives a distribution equal to 0.01% of the accumulated fund. The first four mandatory signatories also receive 0.1% each. The PoS block miner receives 0.1% as well, but his takings will differ slightly because the fund is updated based on txns included in his block. Use of a fund reduces volatility in mining rewards.

Root Private Key - The root private key has full spending and signing authority. When significant balances are held, this key should be kept as an offline backup to guard against theft.

Stake Signing Key - Private Key can delegate signing and sending authority to one other private key. The delegated key can sign blocks and has limited authority to send coins. The authority to send coins is determined by two positive constants, t and k. The following txn rule limits the stake signing keys' spending authority:

Change Returned to Public Key >= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)}
k=9 and t=1/12 are suggested as possible parameters. These parameters allow the stake signing key to spending up to 10% of the total key balance per month. The max value at risk in event of theft of
this key is 10%. Holders of large balances 'zero-out' their coin-age frequently via mining and face less theft risk. If this occurs once per week, for example, the large balance holder will only
risk being able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once the theft is detected, all remaining coins can be moved to a secure computer using the
root private key.

=== Mining Process ===

1) Block meeting work difficulty target is mined. Difficulty target is periodically adjusted so that 1 PoW block arrives every 10 minutes.

2) Work submission is hashed 10 times consecutively. Each consecutive hash maps to an individual unspent output in the blockchain. This is essentially a lottery drawing two sets of five winners. The first five hashes map to mandatory signatures, the final five hashses map to voluntary signatures.

3) If the mandatory signatures map to active public keys [see glossary], the block can potentially be valid. Otherwise, the block is invalid and must be discarded.

4) If PoW miner finds a potentially valid block, he transmits the following hash to the network: {work submission;hash(his block, the previous valid block)}

5) If the work submission meets the difficulty target and maps to active signatories, then the block is relayed through the network. Otherwise, the message is dropped as spam.

5) The first five selected signatories sequentially sign this hash and transmit it onwards as {work submission; hash; sig 1; sig 2; sig 3; sig 4; sig 5}

6) After the mandatory signature sequence is complete, the final signatory publishes the PoW block and also his own PoS block.

7) The final five hashes map to voluntary signatures. These voluntary signatures can be inserted into any block within the next 6 blocks as special txns. These txns do not require fees.

9) Go to step 1

Note: This process is simultaneous so that multiple block hashes can circulate in the network attempting to collect five signatures and generate PoW/PoS block pairs. Block pairs that lose this race
are orphaned.

=== Infeasability of standard attack vectors ===

Unless attackers own a large share of stake, all types of PoW attacks are computationally infeasible. I think there are two types of known attacks: 1) Double-Spend 2) Denial of Service
I consider the approximations below. The numbers are so favorable that consideration of exact statistics is not particularly interesting.

1) Double Spend.

Double spends rely on secrecy. In order to mine blocks in secret a PoW miner must select his 5 of his own public keys in the lottery. If the PoW miner owns a share 0<s<1 of all coins,
the probability of doing that a block meeting the difficulty target will select the miner's coins is (1/s)^5. For s=0.01, 1 out of 10 billion blocks will satisfy this criterion.
Even for extremely small hash aggregate rates, it is not practical to privately mine at a rate 10 billion times faster than all other miners combined. For s=0.1, 1 out of 100,000 blocks will
satisfy this criteria. (i.e. the attack still requires approximately 99.999% of all hashing power). For s=0.5, the attacker will succeed if he controls 51% of the aggregate hash rate.

2) Denial of Service

An attacker who mines publicly could simply produce empty PoW blocks. However, this would fail to deny service. 50% of all blocks are randomly mined via PoS. The attacker cannot
force the PoS miners to produce empty blocks. Therefore he cannot deny service regardless of how much hash rate he controls.

=== Long-term Chain Evaluation ===
1) Comparison of two long chains is based on a simple sum of block difficulty, just as in bitcoin.

2) A criticism of PoS is that there is no reason not to sign attack chains. However, in a long secret chain, many stakeholders will have dead signatures. These dead stakeholders will not be able to sign the main chain, but not the attack chain. They will have a strong incentive to make sure the main chain wins because the attack chain will impose demurrage fees on them.

=== Incentives to maintain full nodes ===

This system introduces powerful incentives to maintain full nodes. Many people argue that the lack of an incentive to maintain a full node is a problem in the bitcoin system.

1) a steady flow of txns will generate some fees even if all public keys remain active. Active keys must be maintaining full nodes. Otherwise, they could not provide the voluntary signatures which prove their activity. Even very weak incentives are sufficient in this case. If almost all keys are associated with active nodes, then it is not necessary to motivate additional participation.

2) Some public keys may decide to become inactive. This is costly for them. They will suffer a loss of 5% of their balance per year for as long as they remain inactive.

3) The active public keys constantly capture revenue from inactive public keys. This means that the incentives to remain increase dramatically as participation falls. Suppose that 50% of public keys maintain full nodes, then this 50% will capture 2.5% of coins per annum. This is equal to an annual of return of 2.0%. The alternative, inactivity, yields an annual return of -5.0% as discussed in point 2. I consider this a reasonable incentive level and participation rate. Suppose that I am wrong, and only 10% of public keys maintain full nodes. Then these 10% will capture 4.5% of all extant coins per annum. This implies an annual return on participation equal to 45% per annum. This is a very strong incentive and is almost certain to be sufficient, even if nodes are quite costly to maintain. If only 1% of coins participate, then 4.95% of all extant coins will be distributed to this 1% each year. This implies a weekly return on the participation of 3%, a pirate ponzi scheme level return. If these incentive are inadequate to support a healthy network of full nodes (which seems unlikely to me), then the levy on dead coins could be increased to exceed 5% per annum.

4) Many people will not have enough coins to justify running their own node. Such individuals will likely use an online banking service that could store their limited spend key. The service could return interest to users in exchange for managing their keys.

5) Other individuals may prefer the privacy associated with dropping out of participation. These individuals are still welcome to use the network, but must face a wealth tax of 5% per annum to compensate for the security risk created by their behavior.

=== Storage of Blockchain Metadata ===
To facilitate the system, data should be extracted from the blockchain in a readily accessible database that is updated with each block. The database only needs to incorporate
public keys which control at least 1 coin. Keys with balances less than 1 coin are considered dead by default. These low-value public keys
are not allowed to create limited stake public keys. If a public key balance drops below 1 coin, the limited stake public key associated with the root key is invalidated.

The database would look like this:

{| class="wikitable"
|-
! Public Key (ordered list) !! Linked Stake Public key (if any) !! Balance !! Cumulative Balance !! Active? !! Coin-age (in years)
|-
| A || As || 1 || 1 || 1 || 0.03
|-
| B || Bs || 2.5 || 3.5 || 0 || 0.1
|-
| C || Cs || 3 || 6.5 || 1 || 0.2
|-
| ... || ... || ... || ... || ... || ...
|}
The block chain must maintain records of links between public keys and delegated limited stake public keys. These should be put in a simple database for easy access.

Cumulative balance can be used to determine the winners of the lottery. (i.e. the lottery is a uniform draw on the support [0,total issued coins]) This indicates a unique lottery winner,
whose chance of winning is proportional to his ownership share.

Coin-age is updated as follows.
If no send, Coin-age_t = Coin-age_t-1 + 1.
If send, Coin_age_t = 1.
If send and receipt of coins, Coin_age_t = 1.
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)

Coin-age is necessary to determine mandatory demurrage fees and to calculate spending limits for limited stake public keys.

Active is 1 by default and becomes 0 if a key fails to provide a requested voluntary signature. 0 is an absorbing state.

=== Beneficiaries and Lossers from Txn Fees ===
The total amount of demurrage fees collected annually varies between 0% and 5% of the total money supply.

The most burdensome fee in the system is the fee paid to PoW miners. This fee imposes a demurrage tax of between 0% and 0.1% per annum on all users of the system. In addition to the demurrage tax, PoW miners receive a 2% share of any optional fees paid to access scarce block space. All coin owners are net losers as a result of PoW mining fees. To minimize costs to coin owners, PoW fee payments are kept as low as possible. Since large hash rates play only a tiny role in security, larger fees for PoW miners are unnecessary.

Other demurrage fees are transfers of revenue from one private key to another. Some keys are net beneficiaries of these transfers, while other keys are net losers. Collectively, these fees do not make coin owners better or worse off. Their effects are neutral. However, individually, the fees do create winners and losers. ''Active'' users that spend infrequently gain from the system. An ''active'' user with average spend frequency is likely to gain from the system as well, but only by a small amount. An ''active'' user that spends very frequently will probably lose from the system. ''Dead'' users will certainly lose from the system. This loss serves as a punishment for failure to maintain an ''active'' node.

== Meni's implementation ==
This proposal is for a proof-of-work (PoW) skeleton on which occasional checkpoints set by stakeholders are placed. In one variant, double-spending is prevented by waiting for a transaction to be included in a checkpoint; the variant described here uses cementing to prevent double-spending, and checkpoints to resolve cementing conflicts.

=== Proof of work ===
Miners use their hashrate to find blocks and build the blockchain exactly as with the pure PoW system. They receive any new generated coins from the block; there will be two kinds of transaction fees, one of which is a mining fee given to the miner who finds the block, just like the PoW transaction fees.

=== Signatures ===
One block every 100 blocks (a different number can be used instead) is a signature block. When a signature block is found and confirmed with several subsequent blocks, stakeholders (people who have bitcoins) are expected to sign it by using a private key associated with their address which contains coins to sign the block hash. If there are several blocks of the same height, an address should not sign more than one of them. The signatures are broadcast on the network and included in a future block. For every candidate block, the total weight of all signatures is tallied (the weight of an address is determined mostly by the number of coins in it, as of the last signature block). Stakeholders will be able to collect signature fees when providing a signature, proportionally to their weight.

At the basic level, there are no rules to choosing which of several conflicting blocks to sign, stakeholders should just choose one.

=== Cementing ===
Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.

In a pure PoW system this is problematic to do because a node could be stuck on "the wrong version" - if an attacker isolates the node and feeds him bogus data, it will not embrace the true, longer chain when he learns of it. However, using PoS to have the final say in such situations makes this possible.

=== Branch selection ===
When a node needs to select which of several branches is valid, it chooses one based on the following criteria in increasing importance (each one is overridden by the next):

#Branch length (total difficulty of all blocks), as in a PoW system.
#Cementing - an already cemented block will not be replaced by a longer branch.
#Signatures - even a cemented block will be overridden by a signature block with signature weight more than half the total possible weight by some margin.

If the conflict is so long that it contains more than one spot for a signature block, the conflicting signature blocks will be traversed earliest to latest, each time choosing the branch with the majority vote. After the newest uncontested signature block it proceeds to use cementing and branch length.

A signature block with no clear majority will be considered tied, and will not override the other criteria. Signature fees will not be given out but instead carried over to the next signature spot, to encourage stakeholders to participate then.

=== [[Double-spending]] prevention ===
A good level of security can be achieved by waiting for a block to be cemented. By that time it is safe to assume that the network recognizes this block and will not easily switch to a different block, even if a longer branch is presented.

A more authoritative confirmation is enabled by waiting for a signature block. Once a block achieves a majority (and some more time is allowed for this majority to spread in the network), it is extremely unlikely that the network will ever switch away from this block.

=== Weights ===
The weight of every address starts at 0. When an address provides a signature, its weight increases so that after several signatures, the weight approaches the number of coins in the address as of the last signature block. For example,
New weight = 0.9 * Old weight + 0.1 * Balance
If a signature is not provided by the address in a signature block, its weight decreases:
New weight = 0.9 * Old weight
This way, addresses whose owners do not wish to participate in signing do not hamper the ability to reach a majority.

If an address signs two conflicting blocks, its weight is reset to 0. This is to limit the power of malicious stakeholders.

If coins move to a new address, weight is proportionally taken away from the addressed, but is not transferred to the new address. The new stakeholder will have to build up his weight.

=== Malicious stakeholders ===
The system is resilient against stakeholders who misuse their signature power, even if they have a majority of the bitcoins. Since their only obligation is to not sign conflicting blocks, the only way they could double-spend is if they first sign one block so it achieves a majority, then sign a different one so that it achieves a bigger majority. Generally this will not work. A short while after a majority is achieved, most of the network will be aware of the relevant signatures. If a different signature is broadcast, the conflict will be detected and both signatures will be ignored. This will cause the current majority block to become tied, but the network is already cemented on it and will vote for this branch in the next signature block. The weight of the attacker will by then reduce to 0 so he will be unable to create more disruption.

Another attack is refusing to sign blocks to keep them tied. Since this causes a decay of the weight, they can only stand in the way of a majority for a short time.

=== Denial of service ===
The method as described does not solve a denial of service scenario. A majority miner could create only blocks with no transactions (or with many transactions missing) and reject all other blocks.

This may be solvable by adding some measure of the transaction in a block to the selection criteria, such as Bitcoin days destroyed.

Also, proposals to replace the block chain with a directed acyclic graph have been made, and could be used to make it easier to include transactions.

== Key difference between the two proposals ==
In Cunicula's system, voting power is determined by combining (multiplicatively) your hashrate and stake. This would be problematic if small players could not compete effectively with large players. Though we are waiting on a formal mathematical proof, evidence to date suggests that small and large players would have an equal competitive footing. Simulations described in this thread [https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253] indicate that small players are competitive with large players because the multiplicative combination of hashrate and stake exhibits constant returns. Evidence in the thread suggests that these simulation results are accepted by both Cunicula and Meni.)

In Meni's, there's a skeleton based purely on hashrate, and superimposed on it are occasional checkpoints set by stakeholders. You can contribute PoW without having stake, and you can contribute PoS without having work, and in both cases your voting power and reward is linearly proportional to the resources you have.

= Delegated Proof of Stake =

The [[Delegated proof of stake]] closely resembles pooling of stakes in a manner, similar to PoW [[mining]]. According to the proof of share principle, instead of computing powers, the partaking users are pooling their stakes, certain amounts of money, blocked on their wallets and delegated to the pool’s staking balance.

The network periodically selects a pre-defined number of top staking pools (usually between 20 and 100), based on their staking balances, and allows them to validate transactions in order to get a reward. The rewards are then shared with the delegators, according to their stakes with the pool.

This principle allows increasing the decentralization, and minimizing the possibility of attaining of 51% of staking power by any of the pools, as such pool will be considered insecure by the users, and they would withdraw their stakes.

= See also =
*[[Proof_of_work|Proof of work]]
*[[Proof_of_burn|Proof of burn]]
*[http://www.reddit.com/r/reddCoin/comments/249dnl/major_announcement_reddcoin_to_implement_new/ Proof of Stake Velocity by Reddcoin]

[[category:mining]]
[[category:Proof-of-x]]

BIP 0038

2022-09-26T07:32:10Z

AllEd01: shortened sentences, grammar, spelling

{{bip}}
{{BipMoved|bip-0038.mediawiki}}

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

==Abstract==
A method is proposed for encrypting and encoding a passphrase-protected Bitcoin private key record in the form of a 58-character Base58Check-encoded printable string. Encrypted private key records are intended for use on paper wallets and physical Bitcoins. Each record string contains all the information needed to reconstitute the private key except for a passphrase, and the methodology uses salting and ''scrypt'' to resist brute-force attacks.

The method provides two encoding methodologies - one permitting any known private key to be encrypted with any passphrase, and another permitting a shared private key generation scheme where the party generating the final key string and its associated Bitcoin address (such as a physical bitcoin manufacturer) knows only a string derived from the original passphrase, and where the original passphrase is needed in order to actually redeem funds sent to the associated Bitcoin address.

A 32-bit hash of the resulting Bitcoin address is encoded in plaintext within each encrypted key, so it can be correlated to a Bitcoin address with reasonable probability by someone not knowing the passphrase. The complete Bitcoin address can be derived through successful decryption of the key record.

==Motivation==
The motivation to make this proposal stems from observations of the way physical bitcoins and paper wallets are used.

An issuer of physical bitcoins must be trustworthy and trusted. Even if trustworthy, users are rightful to be skeptical about a third party with theoretical access to take their funds. A physical bitcoin that cannot be compromised by its issuer is always more intrinsically valuable than one that can.

A two-factor physical bitcoin solution is highly useful to individuals and organizations wishing to securely own bitcoins without any risk of electronic theft and without the responsibility of climbing the technological learning curve necessary to produce such an environment themselves. Two-factor physical bitcoins allow a secure storage solution to be put in a box and sold on the open market, greatly enlarging the number of people who are able to securely store bitcoins.

Existing methodologies for creating two-factor physical bitcoins are limited and cumbersome. At the time of this proposal, a user could create their own private key, submit the public key to the physical bitcoin issuer. Then you receive a physical bitcoin that must be kept together with some sort of record of the user-generated private key, and finally, must be redeemed through a tool. The fact that the physical bitcoin must be kept together with a user-produced private key negates much of the benefit of the physical bitcoin — the user may as well just print and maintain a private key.

A standardized password-protected private key format makes acquiring and redeeming two-factor physical bitcoins simpler for the user. Instead of maintaining a private key that cannot be memorized, the user may choose a passphrase of their choice. The passphrase may be much shorter than the length of a typical private key, short enough that they could use a label or engraver to permanently commit their passphrase to their physical Bitcoin piece once they have received it. By adopting a standard way to encrypt a private key, we maximize the possibility that they'll be able to redeem their funds in the venue of their choice. Rather than relying on an executable redemption tool, they may not wish to download.

Password and passphrase-protected private keys enable new practical use cases for sending bitcoins from person to person. Someone wanting to send bitcoins through postal mail could send a password-protected paper wallet and give the recipient the passphrase over the phone or e-mail, making the transfer safe from interception of either channel. A user of paper wallets or Bitcoin banknote-style vouchers ("cash") could carry funded encrypted private keys, while leaving a copy at home as an element of protection against accidental loss or theft. A user of paper wallets who leaves bitcoins in a bank vault or safety deposit box could keep the password at home or share it with trusted associates as protection against someone at the bank gaining access to the paper wallets and spending from them. The foreseeable and unforeseeable use cases for password-protected private keys are numerous.

==Copyright==
This proposal is hereby placed in the public domain.

==Rationale==
:'''''User story:''' As a Bitcoin user who uses paper wallets, I would like the ability to add encryption, so that my Bitcoin paper storage can be two factors: something I have plus something I know.''
:'''''User story:''' As a Bitcoin user who would like to pay a person or a company with a private key, I do not want to worry that any part of the communication path may result in the interception of the key and theft of my funds. I would prefer to offer an encrypted private key, and then follow it up with the password using a different communication channel (e.g. a phone call or SMS).''
:'''''User story:''' (EC-multiplied keys) As a user of physical bitcoins, I would like a third party to be able to create password-protected Bitcoin private keys for me, without them knowing the password, so I can benefit from the physical bitcoin without the issuer having access to the private key. I would like to be able to choose a password whose minimum length and required format does not preclude me from memorizing it or engraving it on my physical bitcoin, without exposing me to an undue risk of password cracking and/or theft by the manufacturer of the item.''
:'''''User story:''' (EC multiplied keys) As a user of paper wallets, I would like the ability to generate a large number of Bitcoin addresses protected by the same password, while enjoying a high degree of security (highly expensive scrypt parameters), but without having to incur the scrypt delay for each address I generate.

==Specification==
This proposal makes use of the following functions and definitions:

*'''AES256Encrypt, AES256Decrypt''': the simple form of the well-known AES block cipher without consideration for initialization vectors or block chaining. Each of these functions takes a 256-bit key and 16 bytes of input, and deterministically yields 16 bytes of output.
*'''SHA256''', a well-known hashing algorithm that takes an arbitrary number of bytes as input and deterministically yields a 32-byte hash.
*'''scrypt''': A well-known key derivation algorithm. It takes the following parameters: (string) password, (string) salt, (int) n, (int) r, (int) p, (int) length, and deterministically yields an array of bytes whose length is equal to the length parameter.
*'''ECMultiply''': Multiplication of an elliptic curve point by a scalar integer with respect to the [[secp256k1]] elliptic curve.
*'''G, N''': Constants defined as part of the [[secp256k1]] elliptic curve. G is an elliptic curve point, and N is a large positive integer.
*'''[[Base58Check]]''': a method for encoding arrays of bytes using 58 alphanumeric characters commonly used in the Bitcoin ecosystem.

===Prefix===
It is proposed that the resulting Base58Check-encoded string starts with a '6'. The number '6' is intended to represent, from the perspective of the user, "a private key that needs something else to be usable" - an umbrella definition that could be understood in the future to include keys participating in multisig transactions, and was chosen with deference to the existing prefix '5' most commonly observed in [[Wallet Import Format]] which denotes an unencrypted private key.

It is proposed that the second character ought to give a hint as to what is needed as a second factor, and for an encrypted key requiring a passphrase, the uppercase letter P is proposed.

To keep the size of the encrypted key down, no initialization vectors (IVs) are used in the AES encryption. Rather, suitable values for IV-like use are derived using scrypt from the passphrase and from using a 32-bit hash of the resulting Bitcoin address as salt.

===Proposed specification===

* Object identifier prefix: 0x0142 (non-EC-multiplied) or 0x0143 (EC-multiplied). These are constant bytes that appear at the beginning of the Base58Check-encoded record, and their presence causes the resulting string to have a predictable prefix.
* How the user sees it: 58 characters always starting with '6P'
** Visual cues are present in the third character for visually identifying the EC-multiply and compress flag.
* Count of payload bytes (beyond prefix): 37
** 1 byte (''flagbyte''):
*** the most significant two bits are set as follows to preserve the visibility of the compression flag in the prefix, as well as to keep the payload within the range of allowable values that keep the "6P" prefix intact. For non-EC-multiplied keys, the bits are 11. For EC-multiplied keys, the bits are 00.
*** the bit with value 0x20 when set indicates the key should be converted to a base58check encoded P2PKH bitcoin address using the DER compressed public key format. When not set, it should be a base58check encoded P2PKH bitcoin address using the DER uncompressed public key format.
*** the bits with values 0x10 and 0x08 are reserved for a future specification that contemplates using multisig as a way to combine the factors such that parties in possession of the separate factors can independently sign a proposed transaction without requiring that any party possess both factors. These bits must be 0 to comply with this version of the specification.
*** the bit with value 0x04 indicates whether a lot and sequence number are encoded into the first factor, and activates special behavior for including them in the decryption process. This applies to EC-multiplied keys only. Must be 0 for non-EC-multiplied keys.
*** remaining bits are reserved for future use and must all be 0 to comply with this version of the specification.
** 4 bytes: SHA256(SHA256(expected_bitcoin_address))[0...3], used both for typo checking and as salt
**16 bytes: Contents depend on whether EC multiplication is used.
**16 bytes: lasthalf: An AES-encrypted key material record (contents depend on whether EC multiplication is used)
* Range in base58check encoding for non-EC-multiplied keys without compression (prefix 6PR):
** Minimum value: 6PRHv1jg1ytiE4kT2QtrUz8gEjMQghZDWg1FuxjdYDzjUkcJeGdFj9q9Vi (based on 01 42 C0 plus thirty-six 00's)
** Maximum value: 6PRWdmoT1ZursVcr5NiD14p5bHrKVGPG7yeEoEeRb8FVaqYSHnZTLEbYsU (based on 01 42 C0 plus thirty-six FF's)
* Range in base58check encoding for non-EC-multiplied keys with compression (prefix 6PY):
** Minimum value: 6PYJxKpVnkXUsnZAfD2B5ZsZafJYNp4ezQQeCjs39494qUUXLnXijLx6LG (based on 01 42 E0 plus thirty-six 00's)
** Maximum value: 6PYXg5tGnLYdXDRZiAqXbeYxwDoTBNthbi3d61mqBxPpwZQezJTvQHsCnk (based on 01 42 E0 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys without compression (prefix 6Pf):
** Minimum value: 6PfKzduKZXAFXWMtJ19Vg9cSvbFg4va6U8p2VWzSjtHQCCLk3JSBpUvfpf (based on 01 43 00 plus thirty-six 00's)
** Maximum value: 6PfYiPy6Z7BQAwEHLxxrCEHrH9kasVQ95ST1NnuEnnYAJHGsgpNPQ9dTHc (based on 01 43 00 plus thirty-six FF's)
* Range in base58check encoding for EC-multiplied keys with compression (prefix 6Pn):
** Minimum value: 6PnM2wz9LHo2BEAbvoGpGjMLGXCom35XwsDQnJ7rLiRjYvCxjpLenmoBsR (based on 01 43 20 plus thirty-six 00's)
** Maximum value: 6PnZki3vKspApf2zym6Anp2jd5hiZbuaZArPfa2ePcgVf196PLGrQNyVUh (based on 01 43 20 plus thirty-six FF's)

====Encryption when EC multiply flag is not used====
Encrypting a private key without the EC multiplication offers the advantage that any known private key can be encrypted. The party performing the encryption must know the passphrase.

Encryption steps:
# Compute the Bitcoin address (ASCII), and take the first four bytes of SHA256(SHA256()) of it. Let's call this "addresshash".
# Derive a key from the passphrase using scrypt
#*Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''addresshash'' from the earlier step, n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)
#*Let's split the resulting 64 bytes in half, and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(block = bitcoinprivkey[0...15] xor derivedhalf1[0...15], key = derivedhalf2), call the 16-byte result ''encryptedhalf1''
# Do AES256Encrypt(block = bitcoinprivkey[16...31] xor derivedhalf1[16...31], key = derivedhalf2), call the 16-byte result ''encryptedhalf2''

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x42 + ''flagbyte'' + ''salt'' + ''encryptedhalf1'' + ''encryptedhalf2''

Decryption steps:
# Collect encrypted private key and passphrase from user.
# Derive ''derivedhalf1'' and ''derivedhalf2'' by passing the passphrase and ''addresshash'' into scrypt function.
# Decrypt ''encryptedhalf1'' and ''encryptedhalf2'' using AES256Decrypt, merge them to form the encrypted private key.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in ''flagbyte'' of the encrypted key record.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

====Encryption when EC multiply mode is used====
Encrypting a private key with EC multiplication offers the ability for someone to generate encrypted keys knowing only an EC point derived from the original passphrase and some salt generated by the passphrase's owner, and without knowing the passphrase itself. Only the person who knows the original passphrase can decrypt the private key. A code known as an ''intermediate code'' conveys the information needed to generate such a key without knowledge of the passphrase.

This methodology does not offer the ability to encrypt a known private key - this means that the process of creating encrypted keys is also the process of generating new addresses. On the other hand, this serves a security benefit for someone possessing an address generated this way: if the address can be recreated by decrypting its private key with a passphrase, and it's a strong passphrase one can be certain only he knows himself, then he can safely conclude that nobody could know the private key to that address.

The person who knows the passphrase and who is the intended beneficiary of the private keys is called the ''owner''. He will generate one or more "intermediate codes", which are the first factor of a two-factor redemption system, and will give them to someone else we'll call ''printer'', who generates a key pair with an intermediate code can know the address and encrypted private key, but cannot decrypt the private key without the original passphrase.

An intermediate code should but is not required to, embed a printable "lot" and "sequence" number for the benefit of the user. The proposal forces these lot and sequence numbers to be included in any valid private keys generated from them. An owner who has requested multiple private keys to be generated for him will be advised by applications to ensure that each private key has a unique lot and sequence number consistent with the intermediate codes he generated. These mainly help protect ''owner'' from potential mistakes and/or attacks that could be made by ''printer''.

The "lot" and "sequence" number are combined into a single 32 bit number. 20 bits are used for the lot number and 12 bits are used for the sequence number, such that the lot number can be any decimal number between 0 and 1048575, and the sequence number can be any decimal number between 0 and 4095. For programs that generate batches of intermediate codes for an ''owner'', it is recommended that lot numbers be chosen at random within the range 100000-999999 and that sequence numbers are assigned starting with 1.

Steps performed by ''owner'' to generate a single intermediate code, if lot and sequence numbers are being included:
# Generate 4 random bytes, call them ''ownersalt''.
# Encode the lot and sequence numbers as a 4 byte quantity (big-endian): lotnumber * 4096 + sequencenumber. Call these four bytes ''lotsequence''.
# Concatenate ''ownersalt'' + ''lotsequence'' and call this ''ownerentropy''.
# Derive a key from the passphrase using scrypt
#* Parameters: ''passphrase'' is the passphrase itself encoded in UTF-8 and normalized using Unicode Normalization Form C (NFC). salt is ''ownersalt''. n=16384, r=8, p=8, length=32.
#* Call the resulting 32 bytes ''prefactor''.
#* Take SHA256(SHA256(''prefactor'' + ''ownerentropy'')) and call this ''passfactor''. The "+" operator is concatenation.
# Compute the elliptic curve point G * ''passfactor'', and convert the result to compressed notation (33 bytes). Call this ''passpoint''. Compressed notation is used for this purpose regardless of whether the intent is to create Bitcoin addresses with or without compressed public keys.
# Convey ''ownersalt'' and ''passpoint'' to the party generating the keys, along with a checksum to ensure integrity.
#* The following Base58Check-encoded format is recommended for this purpose: magic bytes "2C E9 B3 E1 FF 39 E2 51" followed by ''ownerentropy'', and then ''passpoint''. The resulting string will start with the word "passphrase" due to the constant bytes, will be 72 characters in length, and encodes 49 bytes (8 bytes constant + 8 bytes ''ownerentropy'' + 33 bytes ''passpoint''). The checksum is handled in the Base58Check encoding. The resulting string is called ''intermediate_passphrase_string''.

If lot and sequence numbers are not being included, then follow the same procedure with the following changes:
* ''ownersalt'' is 8 random bytes instead of 4, and ''lotsequence'' is omitted. ''ownerentropy'' becomes an alias for ''ownersalt''.
* The SHA256 conversion of ''prefactor'' to ''passfactor'' is omitted. Instead, the output of scrypt is used directly as ''passfactor''.
* The magic bytes are "2C E9 B3 E1 FF 39 E2 53" instead (the last byte is 0x53 instead of 0x51).

Steps to create new encrypted private keys given ''intermediate_passphrase_string'' from ''owner'' (so we have ''ownerentropy'', and ''passpoint'', but we do not have ''passfactor'' or the passphrase):
# Set ''flagbyte''.
#* Turn on bit 0x20 if the Bitcoin address will be formed by hashing the compressed public key (optional, saves space, but many Bitcoin implementations aren't compatible with it)
#* Turn on bit 0x04 if ''ownerentropy'' contains a value for ''lotsequence''. (While it has no effect on the keypair generation process, the decryption process needs this flag to know how to process ''ownerentropy'')
# Generate 24 random bytes, call this ''seedb''. Take SHA256(SHA256(''seedb'')) to yield 32 bytes, call this ''factorb''.
# ECMultiply ''passpoint'' by ''factorb''. Use the resulting EC point as a public key and hash it into a Bitcoin address using either compressed or uncompressed public key methodology (specify which methodology is used inside ''flagbyte''). This is the generated Bitcoin address, call it ''generatedaddress''.
# Take the first four bytes of SHA256(SHA256(''generatedaddress'')) and call it ''addresshash''.
# Now we will encrypt ''seedb''. Derive a second key from ''passpoint'' using scrypt
#*Parameters: ''passphrase'' is ''passpoint'' provided from the first party (expressed in binary as 33 bytes). ''salt'' is ''addresshash'' + ''ownerentropy'', n=1024, r=1, p=1, length=64. The "+" operator is concatenation.
#*Split the result into two 32-byte halves and call them ''derivedhalf1'' and ''derivedhalf2''.
# Do AES256Encrypt(block = (seedb[0...15] xor derivedhalf1[0...15]), key = derivedhalf2), call the 16-byte result ''encryptedpart1''
# Do AES256Encrypt(block = ((encryptedpart1[8...15] + seedb[16...23]) xor derivedhalf1[16...31]), key = derivedhalf2), call the 16-byte result ''encryptedpart2''. The "+" operator is concatenation.

The encrypted private key is the Base58Check-encoded concatenation of the following, which totals 39 bytes without Base58 checksum:
* 0x01 0x43 + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpart1''[0...7] + ''encryptedpart2''

=====Confirmation code=====
The party generating the Bitcoin address has the option to return a ''confirmation code'' back to ''owner'' which allows ''owner'' to independently verify that he has been given a Bitcoin address that actually depends on his passphrase, and to confirm the lot and sequence numbers (if applicable). This protects ''owner'' from being given a Bitcoin address by the second party that is unrelated to the key derivation and possibly spendable by the second party. If a Bitcoin address given to ''owner'' can be successfully regenerated through the confirmation process, ''owner'' can be reasonably assured that any spending without the passphrase is infeasible. This confirmation code is 75 characters starting with "cfrm38".

To generate it, we need ''flagbyte'', ''ownerentropy'', ''factorb'', ''derivedhalf1'' and ''derivedhalf2'' from the original encryption operation.
# ECMultiply ''factorb'' by G, call the result ''pointb''. The result is 33 bytes.
# The first byte is 0x02 or 0x03. XOR it by (derivedhalf2[31] & 0x01), call the resulting byte ''pointbprefix''.
# Do AES256Encrypt(block = (pointb[1...16] xor derivedhalf1[0...15]), key = derivedhalf2) and call the result ''pointbx1''.
# Do AES256Encrypt(block = (pointb[17...32] xor derivedhalf1[16...31]), key = derivedhalf2) and call the result ''pointbx2''.
# Concatenate ''pointbprefix'' + ''pointbx1'' + ''pointbx2'' (total 33 bytes) and call the result ''encryptedpointb''.

The result is a Base58Check-encoded concatenation of the following:
* 0x64 0x3B 0xF6 0xA8 0x9A + ''flagbyte'' + ''addresshash'' + ''ownerentropy'' + ''encryptedpointb''

A confirmation tool, given a passphrase and a confirmation code, can recalculate the address, verify the address hash, and then assert the following: "It is confirmed that Bitcoin address ''address'' depends on this passphrase". If applicable: "The lot number is ''lotnumber'' and the sequence number is ''sequencenumber''."

To recalculate the address:
# Derive ''passfactor'' using scrypt with ''ownerentropy'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''pointb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''
# Decrypt ''encryptedpointb'' to yield ''pointb''
# ECMultiply ''pointb'' by ''passfactor''. Use the resulting EC point as a public key and hash it into ''address'' using either compressed or uncompressed public key methodology as specifid in ''flagbyte''.

=====Decryption=====
# Collect encrypted private key and passphrase from user.
# Derive ''passfactor'' using scrypt with ''ownersalt'' and the user's passphrase and use it to recompute ''passpoint''
# Derive decryption key for ''seedb'' using scrypt with ''passpoint'', ''addresshash'', and ''ownerentropy''
# Decrypt ''encryptedpart2'' using AES256Decrypt to yield the last 8 bytes of ''seedb'' and the last 8 bytes of ''encryptedpart1''.
# Decrypt ''encryptedpart1'' to yield the remainder of ''seedb''.
# Use ''seedb'' to compute ''factorb''.
# Multiply ''passfactor'' by ''factorb'' mod N to yield the private key associated with ''generatedaddress''.
# Convert that private key into a Bitcoin address, honoring the compression preference specified in the encrypted key.
# Hash the Bitcoin address, and verify that ''addresshash'' from the encrypted private key record matches the hash. If not, report that the passphrase entry was incorrect.

==Backwards compatibility==
Backwards compatibility is minimally applicable since this is a new standard that at most extends [[Wallet Import Format]]. It is assumed that an entry point for private key data may also accept existing formats of private keys (such as hexadecimal and [[Wallet Import Format]]); this draft uses a key format that cannot be mistaken for any existing one and preserves auto-detection capabilities.

==Suggestions for implementers of the proposal with alt-chains==
If this proposal is accepted into alt-chains, it is requested that the unused flag bytes not be used for denoting that the key belongs to an alt-chain.

Alt-chain implementers should exploit the address hash for this purpose. Since each operation in this proposal involves hashing a text representation of a coin address which (for Bitcoin) includes the leading '1', an alt-chain can easily be denoted simply by using the alt-chain's preferred format for representing an address. Alt-chain implementers may also change the prefix such that encrypted addresses do not start with "6P".

==Discussion item: scrypt parameters==
This proposal leaves the scrypt parameters up in the air. The following items are proposed for consideration:

The main goal of scrypt is to reduce the feasibility of brute force attacks. It must be assumed that an attacker will be able to use an efficient implementation of scrypt. The parameters should force a highly efficient implementation of scrypt to wait a decent amount of time to slow attacks.

On the other hand, an unavoidably likely place where scrypt will be implemented is using slow-interpreted languages such as javascript. What might take milliseconds on an efficient scrypt implementation may take seconds in javascript.

It is believed, however, that someone using a javascript implementation is probably dealing with codes by hand, one at a time, rather than generating or processing large batches of codes. Thus, a wait time of several seconds is acceptable to a user.

A private key redemption process that forces a server to consume several seconds of CPU time would discourage implementation by the server owner, because they would be opening up a denial of service avenue by inviting users to make numerous attempts to invoke the redemption process. However, it's also feasible for the server owner to implement his redemption process in such a way that the decryption is done by the user's browser, offloading the task from his own server (and providing another reason why the chosen scrypt parameters should be tolerant of javascript-based decryptors).

The preliminary values of 16384, 8, and 8 are hoped to offer the following properties:
* Encryption/decryption in javascript requiring several seconds per operation
* Use of the parallelization parameter provides a modest opportunity for speedups in environments where concurrent threading is available - such environments would be selected for processes that must handle bulk quantities of encryption/decryption operations. The estimated time for an operation is in the tens or hundreds of milliseconds.

==Reference implementation==
Added to alpha version of Casascius Bitcoin Address Utility for Windows available at:

* via https: https://casascius.com/btcaddress-alpha.zip
* at github: https://github.com/casascius/Bitcoin-Address-Utility

Click "Tools" then "PPEC Keygen" (provisional name)

==Other implementations==
* Javascript - https://github.com/bitcoinjs/bip38

==Test vectors==

===No compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg
*Unencrypted (WIF): 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PRNFFkZc2NZ6dJqFfhRoFNMR9Lnyj7dYGrzdgXXVMXcxoKTePPX1dWByq
*Unencrypted (WIF): 5HtasZ6ofTHP6HCwTqTkLDuLQisYPah7aUnSKfC7h4hMUVw2gi5
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

Test 3:
*Passphrase ϓ␀𐐀💩 (<tt>\u03D2\u0301\u0000\U00010400\U0001F4A9</tt>; [http://codepoints.net/U+03D2 GREEK UPSILON WITH HOOK], [http://codepoints.net/U+0301 COMBINING ACUTE ACCENT], [http://codepoints.net/U+0000 NULL], [http://codepoints.net/U+10400 DESERET CAPITAL LETTER LONG I], [http://codepoints.net/U+1F4A9 PILE OF POO])
*Encrypted key: 6PRW5o9FLp4gJDDVqJQKJFTpMvdsSGJxMYHtHaQBF3ooa8mwD69bapcDQn
*Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF
*Unencrypted private key (WIF): 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4
* ''Note:'' The non-standard UTF-8 characters in this passphrase should be NFC normalized to result in a passphrase of <tt>0xcf9300f0909080f09f92a9</tt> before further processing

===Compression, no EC multiply===

Test 1:
*Passphrase: TestingOneTwoThree
*Encrypted: 6PYNKZ1EAgYgmQfmNVamxyXVWHzK5s6DGhwP4J5o44cvXdoY7sRzhtpUeo
*Unencrypted (WIF): L44B5gGEpqEDRS9vVPz7QT35jcBG2r3CZwSwQ4fCewXAhAhqGVpP
*Unencrypted (hex): CBF4B9F70470856BB4F40F80B87EDB90865997FFEE6DF315AB166D713AF433A5

Test 2:
*Passphrase: Satoshi
*Encrypted: 6PYLtMnXvfG3oJde97zRyLYFZCYizPU5T3LwgdYJz1fRhh16bU7u6PPmY7
*Unencrypted (WIF): KwYgW8gcxj1JWJXhPSu4Fqwzfhp5Yfi42mdYmMa4XqK7NJxXUSK7
*Unencrypted (hex): 09C2686880095B1A4C249EE3AC4EEA8A014F11E6F986D0B5025AC1F39AFBD9AE

===EC multiply, no compression, no lot/sequence numbers===

Test 1:
*Passphrase: TestingOneTwoThree
*Passphrase code: passphrasepxFy57B9v8HtUsszJYKReoNDV6VHjUSGt8EVJmux9n1J3Ltf1gRxyDGXqnf9qm
*Encrypted key: 6PfQu77ygVyJLZjfvMLyhLMQbYnu5uguoJJ4kMCLqWwPEdfpwANVS76gTX
*Bitcoin address: 1PE6TQi6HTVNz5DLwB1LcpMBALubfuN2z2
*Unencrypted private key (WIF): 5K4caxezwjGCGfnoPTZ8tMcJBLB7Jvyjv4xxeacadhq8nLisLR2
*Unencrypted private key (hex): A43A940577F4E97F5C4D39EB14FF083A98187C64EA7C99EF7CE460833959A519

Test 2:
*Passphrase: Satoshi
*Passphrase code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
*Encrypted key: 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd
*Bitcoin address: 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V
*Unencrypted private key (WIF): 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH
*Unencrypted private key (hex): C2C8036DF268F498099350718C4A3EF3984D2BE84618C2650F5171DCC5EB660A

===EC multiply, no compression, lot/sequence numbers===

Test 1:
*Passphrase: MOLON LABE
*Passphrase code: passphraseaB8feaLQDENqCgr4gKZpmf4VoaT6qdjJNJiv7fsKvjqavcJxvuR1hy25aTu5sX
*Encrypted key: 6PgNBNNzDkKdhkT6uJntUXwwzQV8Rr2tZcbkDcuC9DZRsS6AtHts4Ypo1j
*Bitcoin address: 1Jscj8ALrYu2y9TD8NrpvDBugPedmbj4Yh
*Unencrypted private key (WIF): 5JLdxTtcTHcfYcmJsNVy1v2PMDx432JPoYcBTVVRHpPaxUrdtf8
*Unencrypted private key (hex): 44EA95AFBF138356A05EA32110DFD627232D0F2991AD221187BE356F19FA8190
*Confirmation code: cfrm38V8aXBn7JWA1ESmFMUn6erxeBGZGAxJPY4e36S9QWkzZKtaVqLNMgnifETYw7BPwWC9aPD
*Lot/Sequence: 263183/1

Test 2:
*Passphrase (all letters are Greek - test UTF-8 compatibility with this): ΜΟΛΩΝ ΛΑΒΕ
*Passphrase code: passphrased3z9rQJHSyBkNBwTRPkUGNVEVrUAcfAXDyRU1V28ie6hNFbqDwbFBvsTK7yWVK
*Encrypted private key: 6PgGWtx25kUg8QWvwuJAgorN6k9FbE25rv5dMRwu5SKMnfpfVe5mar2ngH
*Bitcoin address: 1Lurmih3KruL4xDB5FmHof38yawNtP9oGf
*Unencrypted private key (WIF): 5KMKKuUmAkiNbA3DazMQiLfDq47qs8MAEThm4yL8R2PhV1ov33D
*Unencrypted private key (hex): CA2759AA4ADB0F96C414F36ABEB8DB59342985BE9FA50FAAC228C8E7D90E3006
*Confirmation code: cfrm38V8G4qq2ywYEFfWLD5Cc6msj9UwsG2Mj4Z6QdGJAFQpdatZLavkgRd1i4iBMdRngDqDs51
*Lot/Sequence: 806938/1

Mining

2022-06-30T14:15:25Z

AllEd01: /* Introduction */ corrected spelling

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "[[Mining rig|mining rig]]"]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "[[Mining rig|mining rig]]" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining".
This ledger of past transactions calls itself the [[blockchain]] as it is a chain of [[block|blocks]].
The blockchain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the blockchain to distinguish legitimate Bitcoin transactions from attempts to re-spend coins that have already been spent elsewhere.

Mining is intentionally designed to be resource-intensive and difficult so that the number of blocks found each day by miners remains steady. Individual [[blocks]] must contain a [[proof of work|proof of work]] to be considered valid. This proof of work is verified by other Bitcoin nodes each time they receive a block. Bitcoin uses the [[hashcash]] proof-of-work function.

The primary purpose of mining is to set the history of [[transactions]] in a way that is [[Irreversible Transactions|computationally impractical to modify by any one entity]]. By downloading and verifying the blockchain, bitcoin [[full node|nodes]] are able to reach a consensus about the ordering of events in bitcoin.

Mining is also the mechanism used to [[Controlled supply|introduce Bitcoins]] into the system:
Miners are paid any [[transaction fees]] as well as a "subsidy" of newly created coins.
This both serves the purpose of disseminating new coins in a decentralized manner as well as motivating people to provide security for the system.

Bitcoin mining is so-called because it resembles the mining of other commodities:
it requires exertion and it slowly makes new units available to anybody who wishes to take part. An important difference is that the [[Controlled supply|supply]] does not depend on the amount of mining. In general changing total miner hashpower does not change how many bitcoins are created over the long term.

== Difficulty ==
=== The Computationally-Difficult Problem ===
Mining a block is difficult because the SHA-256 hash of a block's header must be lower than or equal to the [[Target|target]] in order for the block to be accepted by the network. This problem can be simplified for explanation purposes: The hash of a block must start with a certain number of zeros. The probability of calculating a hash that starts with many zeros is very low, therefore many attempts must be made. In order to generate a new hash each round, a [[Nonce|nonce]] is incremented. See [[Proof of work]] for more information.

=== The Difficulty Metric ===
The [[Difficulty|difficulty]] is the measure of how difficult it is to find a new block compared to the easiest it can ever be. The rate is recalculated every 2,016 blocks to a value such that the previous 2,016 blocks would have been generated in exactly one fortnight (two weeks) had everyone been mining at this difficulty. This is expected yield, on average, one block every ten minutes.

As more miners join, the rate of block creation increases. As the rate of block generation increases, the difficulty rises to compensate, which has a balancing of effect due to reducing the rate of block-creation. Any blocks released by malicious miners that do not meet the required [[Target|difficulty target]] will simply be rejected by the other participants in the network.

=== Reward ===
When a block is discovered, the discoverer may award themselves a certain number of bitcoins, which is agreed-upon by everyone in the network. Currently this bounty is 6.25 bitcoins; this value will halve every 210,000 blocks. See [[Controlled Currency Supply]].

Additionally, the miner is awarded the fees paid by users sending transactions. The fee is an incentive for the miner to include the transaction in their block. In the future, as the number of new bitcoins miners are allowed to create in each block dwindles, the fees will make up a much more important percentage of mining income.

== The mining ecosystem ==

=== Hardware ===
[[File:Usb-fpga module 1.15x-hs-800.jpg|thumb|right|FPGA Module]]
Users have used various types of hardware over time to mine blocks. Hardware specifications and performance statistics are detailed on the [[Mining Hardware Comparison]] page.
==== CPU Mining ====
Early Bitcoin client versions allowed users to use their CPUs to mine. The advent of GPU mining made CPU mining financially unwise as the hashrate of the network grew to such a degree that the amount of bitcoins produced by CPU mining became lower than the cost of power to operate a CPU. The option was therefore removed from the core Bitcoin client's user interface.

==== GPU Mining ====
GPU Mining is drastically faster and more efficient than CPU mining. See the main article: [[Why a GPU mines faster than a CPU]]. A variety of popular [[Mining rig|mining rigs]] have been documented.
==== FPGA Mining ====
FPGA mining is a very efficient and fast way to mine, comparable to GPU mining and drastically outperforming CPU mining. FPGAs typically consume very small amounts of power with relatively high hash ratings, making them more viable and efficient than GPU mining. See [[Mining Hardware Comparison]] for FPGA hardware specifications and statistics.
==== ASIC Mining ====
An application-specific integrated circuit, or ''ASIC'', is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly faster than all previous technologies and already have made GPU mining financially.

==== Mining services (Cloud mining) ====
[[:Category:Mining_contractors|Mining contractors]] provide mining services with performance specified by contract, often referred to as a "Mining Contract." They may, for example, rent out a specific level of mining capacity for a set price at a specific duration.

=== Pools ===
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. This made mining something of a gamble. To address the variance in their income miners started organizing themselves into [[Pooled mining|pools]] so that they could share rewards more evenly. See [[Pooled mining]] and [[Comparison of mining pools]].

=== History ===
Bitcoin's public ledger (the "block chain") was started on January 3rd, 2009 at 18:15 UTC presumably by [[Satoshi Nakamoto]]. The first block is known as the [[genesis block]]. The first transaction recorded in the first block was a single transaction paying the reward of 50 new bitcoins to its creator.

== Staking ==

Staking is a concept in the [[Delegated proof of stake]] coins, closely resembling pooled mining of proof of work coins. According to the [[Proof of Stake|proof of share]] principle, instead of computing powers, the partaking users are pooling their ''stakes'', certain amounts of money, blocked on their wallets and delegated to the pool’s staking balance.

The network periodically selects a pre-defined number of top staking pools (usually between 20 and 100), based on their staking balances, and allows them to validate transactions in order to get a reward. The rewards are then shared with the delegators, according to their stakes with the pool.

Although staking doesn’t require lots of computing power as mining, it still needs very stable and fast Internet connection in order to collect, verify and sign all transactions in the queue within a small timespan, which can be as short as one second. If a pool fails to do so, it doesn’t get the reward, and it may be shared with the next pool in order.

A lot of [[altcoin]]s are using staking. Staking is often marketed as a much more efficient alternative. Unfortunately staking has the potential to not be much different than politics. A good example is that it's easy for a big actor to take over the network by simply buying enough coins. This actually happened in 2020 when TRON's Justin Sun took over the Steem "forum" network and then did some things that made some people unhappy.

==See Also==

* [https://99bitcoins.com/beginners-guide-to-mining/ Beginner's Guide to Bitcoin Mining]
* [https://www.zpool.ca Bitcoin Multipool]
* [https://www.bitcoinmining.com Bitcoin Mining]
* [http://codinginmysleep.com/bitcoin-mining-in-plain-english Bitcoin Mining in Plain English] by David Perry
* [https://www.weusecoins.com/en/mining-guide/ Getting Started With Bitcoin Mining]
* [[Automatically mine when computer is locked|Tutorial to automatically start mining when you lock your computer]]. (Windows 7)
* [http://bitcoinminer.com Bitcoin Miner]
* [http://www.bitcongress.org/bitcoin/best-bitcoin-mining-hardware/ Bitcoin Mining Hardware Comparison]
* [http://www.reddit.com/r/Bitcoin/comments/18q2jx/eli5_bitcoin_mining_xpost_in_eli5/ Simplified Explanation of Bitcoin Mining] by reddit user [http://www.reddit.com/user/azotic azotic]
* [https://bitcoinchain.com/pools Bitcoin Mining Pools Comparison]
* [http://www.bitcoinmining.com/best-bitcoin-cloud-mining-contract-reviews/ Research, Review and Compare Cloud Mining Contracts]
* [https://www.youtube.com/watch?v=GmOzih6I1zs Video: What is Bitcoin Mining?]
* [http://yogh.io/#mine:last Mining Simulator] ([https://github.com/JornC/bitcoin-transaction-explorer GitHub source])
* [http://bitcoindaily.org/bitcoin-guides/what-is-bitcoin-mining/ Bitcoin Mining Explained]
[[ru:Mining]]
[[Category:Mining]][[Category:Vocabulary]]

Satoshi (unit)

2022-06-30T14:07:36Z

AllEd01: spelling corrected

[[File:SatoshiUsage.png|thumb|The term "satoshi" in use on a message board]]The '''satoshi''' is currently the smallest unit of the bitcoin currency recorded on the [[block chain]].<ref name="se">[http://bitcoin.stackexchange.com/questions/114/what-is-a-satoshi What is a 'Satoshi'? - Bitcoin Stack Exchange]</ref> It is a one hundred millionth of a single bitcoin (0.00000001 BTC).<ref name="se"/> The unit has been named in collective homage to the original creator of Bitcoin, [[Satoshi Nakamoto]].<ref name="ribuck"/>

All amounts in the blockchain are denominated in satoshi before being converted for display.<ref name="why">{{cite btct|title=Why 1BTC should equal 10^8 satoshi ?|date=11 October 2014|id=819656}}</ref> The source code also uses satoshi when specifying an amount of bitcoin.<ref name="nov08"/> When displaying an extremely fine fraction of a bitcoin, such as when calculating [[satoshi per byte|fee per byte]] or a [[Bitcoin faucet|faucet]] reward, the amount is displayed in satoshi for readability.<ref>{{cite web|title=How do I calculate my transaction fee?|work=[[21]] Support|author=Binns, Will|date=|accessdate=23 October 2017|url=https://support.21.co/bitcoin/transactions-and-fees/how-do-i-calculate-my-transaction-fee}}</ref><ref>{{cite web|title=Do These "Free Bitcoin" Sites Work?|work=[[CryptoCoinsNews]]|author=Barnes, Samuel|date=9 April 2014|accessdate=19 August 2015|url=https://www.cryptocoinsnews.com/do-free-bitcoin-sites-work/}}</ref>

Although the satoshi is the finest amount that can be recorded in the blockchain,<ref name="why"/> [[payment channels]] may need to make very granular payments and so are sometimes denominated in ''millisatoshi'', which are one hundred billionths of a single bitcoin.<ref>[https://github.com/ElementsProject/lightning/blob/master/README.md#receiving-and-receiving-payments Receiving and receiving payments]</ref>

In January 2018, 1 Euro cent is worth approximately 83 satoshi.

==History==
The value of a bitcoin in satoshi was decided by Satoshi Nakamoto to be 100 million no later than November 2008.<ref name="nov08">{{cite btct|id=382374|date=23 December 2013|title=Bitcoin source from November 2008.}}</ref>

On November 15, 2010, ribuck proposed that the one hundredth of a bitcoin (0.01 BTC) be called a ''Satoshi''.<ref>{{cite btct|id=369|post=22160|date=14 July 2010|title=Official Bitcoin Unicode Character?}}</ref> Four months later he instead suggested that the one hundred millionth unit be called an ''austrian'' or a ''satoshi''.<ref>{{cite btct|id=3311|post=46648|date=10 February 2011|title=More divisibility required - move the decimal point}}</ref> The name ''satoshi'' caught on, and was widely adopted thereafter.<ref name="ribuck">{{cite btct|id=407442|post=4415850|date=9 January 2014|title=How did “satoshi” become the name of the base unit?}}</ref>

In December 2017, BIP-176<ref>https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki</ref> also proposed "Bits" be used as a standard term for 100 (one hundred) satoshis or 1/1,000,000 (one one-millionth) of a bitcoin.

==Usage==
===Plural===
Traditionally, the plural form has been simply ''satoshi'',<ref>[https://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=53369&oldid=53362 Bitcoin Wiki revision by theymos]</ref> but the term ''satoshis'' is also popular and equally correct. If the plural form were to follow the rules of Japanese grammar, it may be pronounced as ''satoshisa'',<ref name="jj73">{{cite btct|id=289475|post=3112861|date=9 September 2013|title=satoshii}}</ref> or simply ''satoshi''.<ref name="jj73"/>

===Symbol===
Satoshi is often abbreviated to ''sat'' or ''s'', although no currency symbol has been widely adopted. There are various proposed symbols:

{| class="wikitable"
|-
! Symbol
! Explanation
|-
| [[File:Satoshi-symbol-small.png|frameless|left]]
| Reminiscent of the Japanese aesthetic, the closest character being 丰 meaning: "Bountiful - abundant, lush, bountiful, plenty, luxurious growth of grass" which suggests a vast amount of Satoshi are still left to mine. This symbol has been adopted by multiple Bitcoin services including satoshilabs.com (Trezor), SatoshiCap.net, pricedinbitcoin21.com, Thunderhub.io, bitcoinicons.com, thebitcoinmachines.com, and many more.
|-
| 里
| In Japanese names, this character can (rarely) be read "satoshi". It is an uncommon Chinese/Japanese character on its own, and an infrequent radical (kangxi #166). It can be seen as a radical in the common kanji 理 and 量, used in meaningful words like 理想 (ideals), 理論 (theory), 理性 (reason), 理科 (science), and 量 (quantity). "Satoshi" is a rare reading; more commonly it is read as "ri" or "sato".
|-
| シ
| A Japanese katakana representing the syllable "shi". Note that this character is extremely common in Japanese, so it could cause confusion. Also, it can mean "death" in Japanese and Chinese.
|-
| ㋛
| As above, but circled to distinguish it from the katakana.
|-
| し
| As above, but this is the hiragana instead of the katakana. This is even more common than シ in Japanese writing, however.
|-
| サ
| A Japanese katakana represents the syllable "sa". Maybe it looks more reminiscent of a currency symbol than others. Note that this character is extremely common in Japanese, so it could cause confusion.
|}

==References==
<references/>
__NOTOC__
{{article}}
[[Category:Denominations]]
[[Category:Terms and properties named after Satoshi Nakamoto]]

Weaknesses

2022-06-30T13:44:49Z

AllEd01: /* Denial of Service (DoS) attacks */ added extra info and reference, corrected spelling

== Might be a problem ==
=== Wallet Vulnerable To Theft ===

The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt in.

==== New wallets vulnerable with old passwords via backups ====

An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.

An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause). The creation of a new wallet with new addresses and the sending of existing sums to them. Backed-up copies of the original wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and initially at least, the new wallet is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.

=== Tracing a coin's history ===
Tracing a coin's history can be used to connect identities to addresses (the [[Anonymity]] article elaborates on this concern in greater detail).

=== Sybil attack ===
If an attacker attempts to fill the network with clients that they control, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

* the attacker can refuse to relay blocks and transactions from everyone, effectively disconnecting you from the network
* the attacker can relay only blocks that they create, effectively putting you on a separate network and then also leaving you open to [[double-spending]] attacks
* if you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute [[double-spending]] attacks
* low-latency encryption/anonymization of Bitcoin's transmissions (with Tor, JAP, etc.) can be defeated relatively easily with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP

Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case where you're probably already unable to accept incoming connections.

Looking for suspiciously-low network hash-rates may help prevent the second one.

=== Packet sniffing ===
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which suggests you originated it). Bitcoin-QT has good Tor integration which closes this attack vector if used.

=== Denial of Service (DoS) attacks ===
In most cases, a denial of service (DoS) happens when a node is overloaded by too much data being sent. A DoS attack is caused deliberately by external parties.<ref>https://www.ionos.com/digitalguide/server/know-how/dos-and-ddos-attack-patterns-at-a-glance/</ref> This means that normal Bitcoin transactions cannot be made, although Bitcoin has some denial-of-service prevention built-in, it's likely still vulnerable to more sophisticated denial-of-service attacks.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

# Does not forward orphan transactions/blocks
# Does not forward double-spend transactions
# Does not forward the same block, transaction, or alert twice to the same peer.
# Continuous rate-limit of free transactions to mitigate 'penny-flooding'
# Keeps a DoS score of each connected peer and disconnects from a peer that sends messages that fail to comply with the rules.
# Bans IP addresses that misbehave for a time-lapse (24 hours default)
# Limits the number of stored orphan transactions (10000 by default)
# Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)
# Limits the number of stored signatures in the signature cache (50000 signatures by default)
# Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.
# Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
# In orphan/signature caches, when removing an item, evicts a random entry.
# Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker resulting in an exponential complexity.
# Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
# In RPC: Only sends an HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
# In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.
# In GUI: Limits URI length to prevent a DoS against the QR-Code dialog
# Considers non-standard signature scripts with size greater than 500 bytes.
# Considers non-standard signature scripts that contain operations that are not PUSHs.
# Does not forward nor process non-standard transactions

These are protocol rules built to prevent DoS:

# Restricts the block size to 1 megabyte.
# Restricts the maximum number of signature checks a transaction input may request
# Limits the size of each script (up to 10000 bytes)
# Limits the size of each value pushed while evaluating a script (up to 520 bytes)
# Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also, each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.
# Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)
# Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)
# Limits the number of signature checks a block may request (up to 20000 checks)

These are the Satoshi client protections added in version 0.8.0:

# Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).
# Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.
# When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/index.php?topic=144122.0) DoS attack)

Satoshi client does not directly limit peer bandwidth nor CPU usage.

=== Forcing clock drift against a target node ===

See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.

=== Illegal content in the block chain ===
It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data are non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 Various ideas have been proposed] to further limit data storage in the [[UTXO|UTXO set]] (but are not currently being seriously considered for deployment).

=== Security Vulnerabilities and bugs ===
It's possible but unlikely that a newly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every node to upgrade in a short time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from node to node, could cause the whole network to shutdown in a few hours. Bugs that break user anonymity, on the contrary, have been found, since the pseudo-anonymity property of Bitcoin has been analyzed less.
Starting from version 0.7.0, Bitcoin client can be considered a mature project. The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts. Also Bitcoin Satoshi client has passed the test of being on-line for more than 3 years, without a single vulnerability being exploited ''in the wild''.
See [[Common Vulnerabilities and Exposures]] for a detailed list of vulnerabilities detected and fixed.

=== Energy Consumption ===
Energy consumption for mining has a high correlation with bitcoin value (exchange rate). Because variable costs of [[mining]] are dominated by electricity price, the economic equilibrium for the mining rate is reached when global electricity costs for mining approximate the value of [[mining]] reward plus [[transaction_fee | transaction fees]].

So the higher the value of one bitcoin, the higher the value of mining rewards and transaction fees, the higher the energy consumption of the bitcoin network in the long run.

* more efficient mining gear does not reduce energy use of the bitcoin network. It will only raise the network [[difficulty]]
* cheaper energy linearly increases mining energy use of the bitcoin network
* the same conclusions apply to all [[proof of work]] based currencies.

== Probably not a problem ==

===Breaking the cryptography===
SHA-256 and [[ECDSA]] are considered very strong currently, but they might be broken in the far future. If that happens, Bitcoin can shift to a stronger algorithm. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].

===Scalability===
Bitcoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.

===Segmentation===
If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid. No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks. Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].

=== Attacking all users ===
The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this. Bitcoin requires that ''some'' country is still free.

=== Dropping transactions ===
Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains "active" and can be included in a later block. Two things discourage this:
* Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.
* [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.

=== Attacker has a lot of computing power ===
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
* Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain, affecting all coins that share a history with the reversed transaction
* Reverse confirmations for any transaction that had previously been seen in the block chain while he’s in control.
* Prevent some or all transactions from gaining any confirmations
* Prevent some or all other miners from mining any valid blocks
The attacker ''can't'':
* Reverse other people's transactions without their cooperation (unless their coin history has been affected by a double-spend)
* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
* Change the number of coins generated per block
* Create coins out of thin air
* Send coins that never belonged to him

Note that the above limitations only apply to the perspective of Bitcoin as seen by [[full node]]s. Some lightweight nodes work by trusting miners absolutely; from the perspective of Bitcoin as seen by lightweight nodes, miners ''can'' steal BTC, etc. This is one of the reasons why lightweight nodes are less secure than full nodes.

With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success.
For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate <ref>https://bitcoil.co.il/Doublespend.pdf</ref>.

It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. If miners rewrite historical blocks too far back, then full nodes with pruning enabled will be unable to continue, and will shut down; the network situation would then probably need to be untangled manually (eg. by updating the software to reject this chain even though it is longer).

Since this attack doesn't permit all that much power over the network, it is expected that rational miners will not attempt it. A profit-seeking miner should always gain more by just following the rules, and even someone trying to destroy the system might find other attacks more attractive. Probably the most likely scenario where this attack would be employed would be for a government to try to get control over Bitcoin by acquiring a majority of hashing power (either directly or by enforcing rules on private miners within its borders). Then this government could use the transaction-censorship power listed above to do things like:

* Prevent any transactions spending "stolen" coins, effectively destroying those coins. If the coins clearly are stolen, then there is a risk that this action will be accepted by the Bitcoin community, but this would set a very damaging precedent. If it becomes possible for coins to be blacklisted in this way, then it is a slippery slope toward blacklisting of other "suspicious" coins.
* Prevent all transactions from unknown people, so everyone has to register with the government in order to transact.

The appropriate response to any long-term attack by miners is a [[hardfork]] to change the proof-of-work function. This fires all existing miners, and allows totally new ones to replace them.

See also: [[Majority_attack]]

=== Spamming transactions ===
{{main|Flood attack}}
It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.

This is made expensive by the [[transaction fee|fees]] that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.

=== The [[Double-spending#Finney_attack|Finney attack]] ===
Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 0-confirmation transactions]. Accepting 0-confirmation large-value transactions is problematic; accepting them for low-value transactions (after waiting several seconds to detect an ordinary double-spend attempt) is probably safe.

===Rival/malicious client code===
Any rival client must follow Bitcoin's rules or else all current Bitcoin clients will ignore it. You'd have to actually get people to ''use'' your client. A better client that pretends to follow the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to gain widespread adoption. At that point, its author could use his exception and go largely unnoticed.

== Definitely not a problem ==

===Coin destruction===
Bitcoin has 2.1 quadrillion raw units, making up 8 decimals of BTC precision, so the entire network could potentially operate on much less than the full quantity of Bitcoins. If deflation gets to the point where transactions of more than 10 BTC are unheard of, clients can just switch to another unit so that, for example, it shows 10 mBTC rather than 0.01 BTC.

The maximum number of raw units might not be enough if the ''entire world'' starts using BTC, but it would not be too difficult to increase precision in that case. The transaction format and version number would be scheduled to change at some particular block number after a year or two, and everyone would have to update by then.

===Generating tons of addresses===
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.

Also, a collision is highly unlikely.

Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)
Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]

===Everyone calculates at the same rate===
If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win. However, each block contains a new, random public key known only to you in the list of transactions. The 256-bit "Merkle tree" hash of this is part of the block header.

So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).

===Generate "valid" blocks with a lower difficulty than normal===
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).

"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win.

==See Also==

* [[Double-spending]]
* [http://bitcoin.stackexchange.com/questions/10025/where-can-i-find-well-written-criticism-about-bitcoin Stack Exchange]

[[Category:Technical]]

Weaknesses

2022-06-30T12:42:48Z

AllEd01: /* Wallet Vulnerable To Theft */ spell and gramar check

== Might be a problem ==
=== Wallet Vulnerable To Theft ===

The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt in.

==== New wallets vulnerable with old passwords via backups ====

An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.

An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause). The creation of a new wallet with new addresses and the sending of existing sums to them. Backed-up copies of the original wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and initially at least, the new wallet is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.

=== Tracing a coin's history ===
Tracing a coin's history can be used to connect identities to addresses (the [[Anonymity]] article elaborates on this concern in greater detail).

=== Sybil attack ===
If an attacker attempts to fill the network with clients that they control, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

* the attacker can refuse to relay blocks and transactions from everyone, effectively disconnecting you from the network
* the attacker can relay only blocks that they create, effectively putting you on a separate network and then also leaving you open to [[double-spending]] attacks
* if you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute [[double-spending]] attacks
* low-latency encryption/anonymization of Bitcoin's transmissions (with Tor, JAP, etc.) can be defeated relatively easily with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP

Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case where you're probably already unable to accept incoming connections.

Looking for suspiciously-low network hash-rates may help prevent the second one.

=== Packet sniffing ===
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which suggests you originated it). Bitcoin-QT has good Tor integration which closes this attack vector if used.

=== Denial of Service (DoS) attacks ===
Sending lots of data to a node may make it so busy it cannot process normal Bitcoin transactions. Bitcoin has some denial-of-service prevention built-in, but is likely still vulnerable to more sophisticated denial-of-service attacks.

These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:

# Does not forward orphan transactions/blocks
# Does not forward double-spend transactions
# Does not forward the same block, transaction or alert twice to the same peer.
# Continuous rate-limit of free transactions to mitigate 'penny-flooding'
# Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
# Bans IP addresses that misbehave for a time lapse (24 hours default)
# Limits the number of stored orphan transactions (10000 by default)
# Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)
# Limits the number of stored signatures in the signature cache (50000 signatures by default)
# Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.
# Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
# In orphan/signature caches, when removing an item, evicts a random entry.
# Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker that result in exponential complexity.
# Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
# In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
# In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.
# In GUI: Limits URI length to prevent a DoS against the QR-Code dialog
# Considers non-standard signature scripts with size greater than 500 bytes.
# Considers non-standard signature scripts that contain operations that are not PUSHs.
# Does not forward nor process non-standard transactions

These are protocol rules built to prevent DoS:

# Restricts the block size to 1 megabyte.
# Restricts the maximum number of signature checks a transaction input may request
# Limits the size of each script (up to 10000 bytes)
# Limits the size of each value pushed while evaluating a a script (up to 520 bytes)
# Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.
# Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)
# Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)
# Limits the number of signature checks a block may request (up to 20000 checks)

These are the Satoshi client protections added in version 0.8.0:

# Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).
# Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.
# When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/index.php?topic=144122.0) DoS attack)

Satoshi client does not directly limit peer bandwidth nor CPU usage.

=== Forcing clock drift against a target node ===

See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.

=== Illegal content in the block chain ===
It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data are non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 Various ideas have been proposed] to further limit data storage in the [[UTXO|UTXO set]] (but are not currently being seriously considered for deployment).

=== Security Vulnerabilities and bugs ===
It's possible but unlikely that a newly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every node to upgrade in a short time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from node to node, could cause the whole network to shutdown in a few hours. Bugs that break user anonymity, on the contrary, have been found, since the pseudo-anonymity property of Bitcoin has been analyzed less.
Starting from version 0.7.0, Bitcoin client can be considered a mature project. The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts. Also Bitcoin Satoshi client has passed the test of being on-line for more than 3 years, without a single vulnerability being exploited ''in the wild''.
See [[Common Vulnerabilities and Exposures]] for a detailed list of vulnerabilities detected and fixed.

=== Energy Consumption ===
Energy consumption for mining has a high correlation with bitcoin value (exchange rate). Because variable costs of [[mining]] are dominated by electricity price, the economic equilibrium for the mining rate is reached when global electricity costs for mining approximate the value of [[mining]] reward plus [[transaction_fee | transaction fees]].

So the higher the value of one bitcoin, the higher the value of mining rewards and transaction fees, the higher the energy consumption of the bitcoin network in the long run.

* more efficient mining gear does not reduce energy use of the bitcoin network. It will only raise the network [[difficulty]]
* cheaper energy linearly increases mining energy use of the bitcoin network
* the same conclusions apply to all [[proof of work]] based currencies.

== Probably not a problem ==

===Breaking the cryptography===
SHA-256 and [[ECDSA]] are considered very strong currently, but they might be broken in the far future. If that happens, Bitcoin can shift to a stronger algorithm. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].

===Scalability===
Bitcoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.

===Segmentation===
If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid. No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks. Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].

=== Attacking all users ===
The IP addresses of most users are totally public. You can use Tor to hide this, but the network won't work if everyone does this. Bitcoin requires that ''some'' country is still free.

=== Dropping transactions ===
Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains "active" and can be included in a later block. Two things discourage this:
* Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.
* [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.

=== Attacker has a lot of computing power ===
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
* Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain, affecting all coins that share a history with the reversed transaction
* Reverse confirmations for any transaction that had previously been seen in the block chain while he’s in control.
* Prevent some or all transactions from gaining any confirmations
* Prevent some or all other miners from mining any valid blocks
The attacker ''can't'':
* Reverse other people's transactions without their cooperation (unless their coin history has been affected by a double-spend)
* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
* Change the number of coins generated per block
* Create coins out of thin air
* Send coins that never belonged to him

Note that the above limitations only apply to the perspective of Bitcoin as seen by [[full node]]s. Some lightweight nodes work by trusting miners absolutely; from the perspective of Bitcoin as seen by lightweight nodes, miners ''can'' steal BTC, etc. This is one of the reasons why lightweight nodes are less secure than full nodes.

With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success.
For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate <ref>https://bitcoil.co.il/Doublespend.pdf</ref>.

It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. If miners rewrite historical blocks too far back, then full nodes with pruning enabled will be unable to continue, and will shut down; the network situation would then probably need to be untangled manually (eg. by updating the software to reject this chain even though it is longer).

Since this attack doesn't permit all that much power over the network, it is expected that rational miners will not attempt it. A profit-seeking miner should always gain more by just following the rules, and even someone trying to destroy the system might find other attacks more attractive. Probably the most likely scenario where this attack would be employed would be for a government to try to get control over Bitcoin by acquiring a majority of hashing power (either directly or by enforcing rules on private miners within its borders). Then this government could use the transaction-censorship power listed above to do things like:

* Prevent any transactions spending "stolen" coins, effectively destroying those coins. If the coins clearly are stolen, then there is a risk that this action will be accepted by the Bitcoin community, but this would set a very damaging precedent. If it becomes possible for coins to be blacklisted in this way, then it is a slippery slope toward blacklisting of other "suspicious" coins.
* Prevent all transactions from unknown people, so everyone has to register with the government in order to transact.

The appropriate response to any long-term attack by miners is a [[hardfork]] to change the proof-of-work function. This fires all existing miners, and allows totally new ones to replace them.

See also: [[Majority_attack]]

=== Spamming transactions ===
{{main|Flood attack}}
It is easy to send transactions to yourself repeatedly. If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.

This is made expensive by the [[transaction fee|fees]] that would be required after the 50KB of free transactions per block are exhausted. An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees. An attacker will eventually run out of money. Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.

=== The [[Double-spending#Finney_attack|Finney attack]] ===
Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 0-confirmation transactions]. Accepting 0-confirmation large-value transactions is problematic; accepting them for low-value transactions (after waiting several seconds to detect an ordinary double-spend attempt) is probably safe.

===Rival/malicious client code===
Any rival client must follow Bitcoin's rules or else all current Bitcoin clients will ignore it. You'd have to actually get people to ''use'' your client. A better client that pretends to follow the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to gain widespread adoption. At that point, its author could use his exception and go largely unnoticed.

== Definitely not a problem ==

===Coin destruction===
Bitcoin has 2.1 quadrillion raw units, making up 8 decimals of BTC precision, so the entire network could potentially operate on much less than the full quantity of Bitcoins. If deflation gets to the point where transactions of more than 10 BTC are unheard of, clients can just switch to another unit so that, for example, it shows 10 mBTC rather than 0.01 BTC.

The maximum number of raw units might not be enough if the ''entire world'' starts using BTC, but it would not be too difficult to increase precision in that case. The transaction format and version number would be scheduled to change at some particular block number after a year or two, and everyone would have to update by then.

===Generating tons of addresses===
Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.

Also, a collision is highly unlikely.

Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)
Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]

===Everyone calculates at the same rate===
If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win. However, each block contains a new, random public key known only to you in the list of transactions. The 256-bit "Merkle tree" hash of this is part of the block header.

So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).

===Generate "valid" blocks with a lower difficulty than normal===
Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network. These blocks would be totally valid for his network. However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).

"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win.

==See Also==

* [[Double-spending]]
* [http://bitcoin.stackexchange.com/questions/10025/where-can-i-find-well-written-criticism-about-bitcoin Stack Exchange]

[[Category:Technical]]

ArtForz

2022-06-30T12:38:26Z

AllEd01: added new information

{{outdated}}
ArtForz is a regular on #bitcoin-dev. He and Laszlo Hanyecz are considered the first two person to mine with GPUs, using private mining code. ArtForz once held a high percentage of network computation power (~25%) but reports<ref>https://bitcointalk.org/index.php?topic=37904.msg478671#msg478671</ref> that he now controls less than 1%. He claims that his mining software is still more efficient than all other GPU miners. He uses a heavily-modified version of Bitcoin; notably, he requires less transaction fees and he doesn't perform IsStandard checks.

ArtForz has a very good understanding of Bitcoin. He reported [[incidents#LSHIFT_and_RETURN_bugs|serious bugs]] in Bitcoin's handling of certain [[script]] opcodes.

<references/>

[[Category:People]]

Asmoney

2022-06-30T12:19:38Z

AllEd01: added info and corrected grammar

AsMoney is an electronic payment system based on Bitcoin that helps its members make instant payment for goods or services or send and receive money with minimum fee, on the other hand, Asmoney provide a web-based [[EWallet]] used for sending, receiving, and storing Bitcoins. Asmoney support multi currencies and allow people to send money based on location and their local currency. Asmoney make Bitcoin easier for non-technical users to send and receive payments. AsMoney also supports Litecoin, Dogecoin and Peercoin.

==Currencies==

At the present time, Asmoney support BTC, LTC, USD, EUR, AUD, GBP, JPY, CAD, CHF, CNY, MYR, NZR, RUB, SGD, THB, TRL, ZAR, INR, IDR and EGP.

==Deposit==

Deposit
Asmoney users may deposit to your account by using three methods : Exchangers, Bitcoin and Litecoin.

==Withdrawal==

Same as deposit methods, Asmoney users can withdrawal from Asmoney account by using three methods anytime : Exchangers, Bitcoin and Litecoin

==Send and Receive money==

This feature provides the ability to send money to Asmoney username, there is No limitation for sending/receiving money to/from others

==Fees==

Due to lack of tax in P2P Currencies and low network fees, Asmoney fees is lower than other payment processors and safety is more than others. There are no fees for transfer on BTC/LTC between Asmoney accounts, the 0.5% fees apply for other currencies.

==Asmoney for Merchants==

Asmoney allow all users generate a checkout button and make accepting Bitcoin easy on any website by copying and pasting a few lines of code. Payment SCI allow merchants to accept Bitcoin with a hosted checkout page on asmoney.com.

==Mass Payment==

Asmoney provide an API interface that helps all members use API for sending Bitcoin to many recipients at once.

==External Links==

* [https://www.asmoney.com asmoney.com] website

==References==
<references />

[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Exchanges]]
[[Category:Shopping Cart Interfaces]]
[[Category:Services]]

1WBE

2022-06-29T20:30:15Z

AllEd01: grammar corrected

{{infobox company|name=1WBE.COM|image=[[File:1wbe.png|200px]]
|industry=[[Exchange|Bitcoin exchange]]
|foundation=January 27, 2014
|defunct=c. 2014
|pairs=BTC/USD BTC/EUR EUR/USD
|website=https://1wbe.com/en/
}}
'''1WBE''' was an exchange announced in January 2014. It suffered from slow withdrawal times<ref>{{cite btct|title=1wbe.com / worldwide bitcoin exchange is a scam !|id=672809|date=1 July 2014}}</ref> and closed at some point between mid 2014 and mid 2015.

==References==
<references/>

{{stub}}{{article}}
[[Category:Defunct exchanges]]
[[Category:Properties established in 2014]]
[[Category:USD exchanges]]
[[Category:EUR exchanges]]
[[Category:Barely notable subjects]]

Asia Nexgen Bitcoin Exchange

2022-06-29T20:28:52Z

AllEd01: /* Asia Nexgen (ANX) */ grammar, spelling corrected

== Asia Nexgen (ANX) ==

[https://anxpro.com '''ANX'''] is a trading platform for buying and selling Bitcoin in AUD, CAD, CHF, EUR, GBP, HKD, JPY, NZD, SGD and USD currencies.
The exchange was established in 2013 and is legally registered and based in Hong Kong. Asia Nexgen was one of the first Bitcoin exchanges in Hong Kong to be issued with a Money Services Operator (MSO) license by the Hong Kong Customs and Excise Department. The trading engine is built upon the LMAX Disruptor technology used by banks for their foreign currency exchange (FX) trading. The engine was designed to handle high volume, high throughput, and low latency trading. The exchange has a favorable reputation for offering same-day processing of deposit and withdrawal requests on a weekday, daily basis. 

ANX originally offered only a single product, namely [https://anxbtc.com '''ANXBTC'''] to satisfy customers who were wanting to buy and sell Bitcoins via a simple and efficient service with fast and varied payment processing options. 

On 20 January 2014, owing to the feedback from ANX clients, [https://anxpro.com '''ANXPRO'''] was released. ANXPRO was designed for the advanced user and specializes in Altcoins, Algos and Performance. The platform provides a professional trading facility with all major currency and crypto pairs. ANXPRO is the only cryptocurrency exchange in the world that facilitates Altcoin trading in no less than 10 fiat currencies. 

In a January 2014 promotion, the company distributed red envelopes of “lucky money”, a centuries-old New Year's tradition, which contained vouchers for HK$10 worth of Bitcoin (about 1.4 mBTC at the time). 

In February 2014, the company prepared to open Hong Kong's first physical bitcoin shop, in Sai Ying Pun. Customers, who must supply an identity card and proof of address for anti-money laundering regulatory compliance, will be able to purchase bitcoins for cash. 

In March 2014, ANX has brought the first Bitcoin ATM to Hong Kong. Customers must be verified to use this ATM and will need to use their Bitcoin wallet QR code to make a cash deposit. 

In July 2014, ANX announced a re-loadable prepaid debit card that can be used to make purchases or perform cash withdrawals via an extensive global network of retailers, online merchants and ATMs. It is available for immediate delivery for ANX customers whom have completed the ANX KYC verification procedure. 

== Advantages ==

• Trading Fees as low as 0.05% 
• Daily processing of withdrawals and deposits Mon-Fri, with less than 24hours turnaround. 
• Offer local HKD/AUD banking support with zero deposit fees. 
• Support the most popular cryto currencies: Bitcoin, Litecoin, Peercoin, Namecoin and Dogecoin. 
• Support all global fiat currencies: USD/ HKD/ GBP/ CHF/ NZD/ EUR/ CAD/ AUD/ YEN/ SGD. 
• A single order book for all currencies for maximum liquidity and ease of use from customer’s perspective. 
• Multilingual support (English, Traditional Chinese, Simplified Chinese). 
• Advanced trading interface including support for keyboard hotkeys (i.e. 'B' for Buy, 'L' for Limit, 'Enter' to execute, etc) 
• Native wallet apps for both [https://play.google.com/store/apps/details?id=com.anxbtc.android Android] and [https://itunes.apple.com/us/app/anx-vault-your-bitcoin-wallet/id855057847?ls=1&mt=8 iOS] 
• Support SEPA with same day processing of both EUR deposits and withdrawals. 
• Support Egopay with instant processing of both EUR/ USD deposits and withdrawals. 

== Security ==
• Support Two-Factor Authentication greatly reducing online identity theft. 
• ANX is using an industry leading service provider for DDOS protection and our servers are hosted in a Tier 3+ ISO 27001/9001 compliant datacentre. 
• ANX supports two-factor authentication in addition to email verification for all crypto withdrawals. 
• ANX does not run a fractural reserve. All customer funds segregated and accounted for. 

==External Links==

* [https://anxpro.com '''ANXPRO''']
* [https://anxbtc.com '''ANXBTC''']
* [http://www.linkedin.com/company/anx/ '''ANX LinkedIn''']

[[Category:Exchanges]]

Atomic multipath payments

2022-06-29T20:25:11Z

AllEd01: /* Roadmap */ grammar

'''Atomic Multipath Payments''' ('''AMP''') are payments that use multiple paths to complete a transaction that either all complete successfully or none complete successfully.

One of the problems the lightning network has had is limited ability to send higher-value payments, because of limitations in channel capacity along possible routes to the payee. Using AMP, a payer can send a payment using many paths, which can make larger payments far more reliable.

== Roadmap ==

AMP is not yet available yet on any lightning implementation, but non-atomic multipath payments (MPP) were recently implemented by LND in v0.10.0. MPP is the first stage in a three-stage process for AMP. The second stage is hash-based AMP, and the third step is a better form of AMP that uses points and scalars instead of hashes. The third stage requires [[Eltoo]] and [[Schnorr]].

Alert system

2022-06-29T20:21:05Z

AllEd01: corrected spelling

[[File:Prefinal alert.png|thumb|300px|The prefinal alert message in the status bar of the GUI client]]Bitcoin versions 0.3.10 introduced an '''alert system''' which allowed messages about critical network problems to be broadcast to all clients.

The alert system has been completely retired.<ref name="org">https://bitcoin.org/en/alert/2016-11-01-alert-retirement</ref> The code was removed since 0.13.0 and since 0.14.0 any old nodes will receive a static hard-coded "Alert Key Compromised" message.

When an alert was in effect, the message it contains would appear in the status bar of all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.

===Alert message===
Alerts are broadcast using the same [[network|TCP relay system]] as ''block'' and ''tx'' messages. They are not encoded in a special transaction. Unlike block and tx relaying, alerts are sent at the start of every new connection for as long as the alert is in effect. This ensures that everyone receives the alert.

Alerts contain this information:
* How long to relay the alert.
* How long to consider the alert valid.
* An alert ID number.
* A list of alerts that should be canceled upon receipt of this alert.
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.
* Alert priority.
* The alert text.

Only alerts that are signed by a specific ECDSA public key are considered valid. Some known private keyholders were [[Satoshi Nakamoto]], [[User:gavinandresen|Gavin Andresen]] and [[User:Theymos|theymos]], but the private key was made public after the alert system was retired, so there is no longer any special group of alert-key-holders.

===Safe mode===
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error. Current Bitcoin versions no longer go into safe mode in response to alerts, though Bitcoin ''will'' still go into safe mode when it detects on its own that something is seriously wrong with the network.

Even though Bitcoin no longer automatically disables RPC when an alert is live, it is wise for Bitcoin sites to shut down when an alert has been issued. To detect an active alert, poll the "errors" field of ''getinfo''.

To test safe mode, run Bitcoin with the -testsafemode switch. To override a real safe mode event, run Bitcoin with the -disablesafemode switch.

==History==
{{multiple image|align=vertical|width=300
|image1=alert.png
|image2=bitcoin-alert-cli.png
|footer=An alert appearing on bitcoin clients
}}

The alert system was hastily implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010. Satoshi never actually used this system; it remained dormant until the [[February 20, 2012 protocol change]], for which an alert was issued on February 18.<ref>[https://bitcoin.org/en/alert/2012-02-18-protocol-change February 20, 2012 Protocol Changes] at bitcoin.org</ref>

In 2016, the alert system was retired<ref name="org"/> because of the possibility of privileged users sending political alert messages,  and because of the possibility of the alert key having been taken from [[Mark Karpelès]] by the Japanese police in 2014.<ref>https://github.com/bitcoin/bitcoin/pull/7692</ref>

The alert key was scheduled to be released to the public in May 2017, but this was postponed.<ref name="org"/> It was eventually published in July 2018.

===Past alerts===
{| class="wikitable" border="1"
|-
! ID
! Sent date
! Expires (UTC)
! Versions
! Priority
! Message
|-
| 1010
| Feb 18, 2012
| Feb 21 02:47:15
| All
| 100
| See bitcoin.org/feb20 if you have trouble connecting after 20 February
|-
| 1011
| Mar 16, 2012
| cancelled May 15, 2012
| 0.5 - 0.5.3
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1012
| Mar 16, 2012
| cancelled May 15, 2012
| 6.0
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1013
| Mar 16, 2012
| cancelled May 15, 2012
| 5.99
| 5000
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix
|-
| 1015
| May 15, 2012
| May 16, 2013
| 0.1 - 0.4.5
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1016
| May 15, 2012
| May 16, 2013
| 0.4.99 - 0.5.4
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1020
| May 15, 2012
| May 16, 2013
| 0.6.0
| 5000
| URGENT: upgrade required, see http://bitcoin.org/dos for details
|-
| 1032
| March 12, 2013
| March 13, 2013
| 0.8.0
| 5000
| URGENT: chain fork, stop mining on version 0.8
|-
| 1033
| March 19, 2013
| March 20, 2013
| 0.1 - 0.7.2
| 10
| See http://bitcoin.org/may15.html for an important message
|-
| 1034
| May 9, 2013
| June 8, 2013
| 0.1 - 0.7.2
| 10
| Action required: see http://bitcoin.org/may15.html for more information
|-
| 1040
| April 11, 2014
| cancelled
| 0.9.0
| 5000
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/
|-
| 1041
| April 11, 2014
| April 11, 2015
| 0.9.0
| 5000
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed
|}

==See Also==

* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed

[[Category:Technical]]
[[Category:Vocabulary]]

==References==
<references/>

==External links==
https://bitcoin.org/en/alerts

{{Bitcoin Core documentation}}

Anycoin Direct

2022-06-29T20:16:17Z

AllEd01: /* History */ corrected spelling

Anycoin Direct is a cryptocurrency brokerage platform headquartered in the Netherlands. The company was registered at the Dutch Chamber of Commerce by Lennert Vlemmings, Bram C. L. Ceelen, and Julian A. W. van der Wijst under the name Bitplaats B.V. in April 2013.<ref>[https://www.kvk.nl/handelsregister/TST-BIN/FP/MDWS002@?BUTT=H608155310000&kvknummer=594661970000&product=Concernrelaties Chamber of Commerce - Registration]</ref>

== History ==

In 2014, the company expanded its services to Belgium by implementing the payment method, Bancontact, formerly known as Mister Cash. Initially, Anycoin Direct was called Bitplaats (Dutch for Bit[coin]place). However, the name changed to fit the geographic area served. <ref>[https://cointelegraph.com/news/anycoin-direct-makes-bitcoin-available-all-over-europe-in-under-5-minutes Cointelegraph - Anycoin Direct makes bitcoin available all over Europe]</ref> The company name also changed from Bitplaats B.V. to Phoenix Payments B.V. for the same reason.
The same year, Anycoin Direct further expanded its services to the European Economic Area (EEA) with the addition of Single Euro Payments (SEPA). <ref>[https://www.coinspeaker.com/anycoin-direct-makes-bitcoin-available-all-over-europe/ Coinspeaker- Anycoin Direct makes bitcoin available all over Europe]</ref> Additional local payment methods were added: Giropay & Mybank in September, Sofort in October, and Trustpay in March 2015.

Anycoin Direct announced a €500.000 private investment funding in January 2015.<ref>[https://www.coindesk.com/anycoin-direct-e500k-funding Coindesk - Anycoin Direct receives 500k funding]</ref> The funding allowed the company to expand outside the European Economic Area into Canada. Anycoin Direct partnered with San Francisco-based Salt Technology, Inc. to provide Interac Online Payments services to its Canadian customers. It discontinued service to Canada in late December 2016.

In March 2018, Anycoin Direct became the first European crypto broker to implement SegWit, a protocol upgrade that reduces the load placed on the Bitcoin network and improves scalability.<ref>[https://www.btc-echo.de/anycoin-direct-aktiviert-segwit/ BTC-Echo - Anycoin Direct activates SegWit]</ref>

==Mission Statement==
Anycoin Direct’s mission statement is “Cryptocurrencies: easily available for everyone, fully under your control.” It aims to achieve this by focusing on three pillars: convenience, speed and security.<ref>[https://anycoindirect.eu/en Anycoin Direct - Easy, Fast, Secure]</ref>
==Support==

You can contact Anycoin Direct through all of the following channels: <ul> <li>Live-chat</li> <li>Support ticket</li> <li>Telephone</li> <li>Facebook</li> </ul> 

==Supported payment methods==
* SEPA 
* Giropay 
* Sofort banking 
* Bancontact 
* iDEAL 
* MyBank 

==Fees and rates==

Concurrently, Anycoin Direct’s product folio consists of 21 cryptocurrencies available for buy, sell, and trade orders. The overall commission ranges between 0.3 and 1.0% without account (maintenance) fees.
The various payment methods charge a fixed and a variable amount. 

==External links==
[https://anycoindirect.eu/ Anycoin Direct website] 

==References==
<references/>

[[Category:Exchanges]]

Abescrow

2022-06-29T20:10:42Z

AllEd01: corrected grammar

An Anonymous bitcoin-based secure escrow service.

Essentially, Funds are held by the escrow service until the payment sender releases the funds to the payment recipient, after receive the item or service.
This service is provided by a real company based in Hong Kong and is anonymous because it does not save logs of IP.

==External Links==

* [https://abescrow.com/ ABEscrow - Anonymous Bitcoin Escrow] Trusted escrow service from a real hong kong based company.

* [http://www.webutation24.net/go/review/abescrow.com ABEscrow Rating] at Webutation - Online Website Reputation (and a quite negative one at the moment)

==References==
<references />

[[Category:Escrow services]]

BASIC

2022-06-29T20:07:32Z

AllEd01: corrected spelling, grammar

{{lowercase}}
{{Infobox company|name=bASIC|image=[[{{ns:file}}:Logo-basic.png|270x64px]]|website=[https://www.bitcoinasic.com/ bitcoinasic.com]}}
bASIC sprang forth from [[BTCFPGA]] which had a range of highly successful [[FPGA]] Bitcoin miners (ModMiner), and had hoped to release an ASIC design, taking pre-orders for funding.

On September 3rd, 2012, bASIC was announced as BitcoinASIC / BTCFPGA's 'fourth generation Bitcoin mining device'.<ref>https://bitcointalk.org/index.php?topic=79637.msg1157524#msg1157524</ref>.

On January 9th, 2013, the bASIC project was canceled<ref>https://bitcointalk.org/index.php?topic=135428.0</ref> and claimed to have been sold to an Asian investor, however, this claim was later retracted.

On January 13th, 2013, the principal of the project noted "At this point, if you are thinking of sending me a refund request, I recommend you do a chargeback instead."<ref>https://bitcointalk.org/index.php?topic=136217.0</ref>

On February 1st, 2013, a message was posted to the bASIC website stating that a "a devision of a huge corporate electronics manufacturer in Canada" had taken over the reins.<ref>https://bitcointalk.org/index.php?topic=140411.0</ref>, later revealed to be CAN-ELECTRIC<ref>https://bitcointalk.org/index.php?topic=140411.msg1497234#msg1497234</ref>. However, a purported exchange between a [[BitcoinTalk Forum]] member and Can Electric resulted in a statement suggesting that they were not involved in this endeavor.<ref>https://bitcointalk.org/index.php?topic=140411.msg1507124#msg1507124</ref>

== References ==
<references />

B-money

2022-06-29T20:02:50Z

AllEd01: corrected grammar

'''B-money''' was an early proposal created by [[Wei Dai]] for an "anonymous, distributed electronic cash system". [[Satoshi Nakamoto]] referenced b-money when creating [[Bitcoin]]. In his essay, published on the cypherpunks mailing-list in November 1998, Dai proposed two protocols. The first protocol is impractical as it requires a broadcast channel that is unjammable as well as being synchronous.

In the first protocol in the essay, the use of a [[proof of work]] function is recommended as a means of creating money. Dai's B-Money was proposed in the context of cypherpunks mailing-list discussions relating to possible applications of [[Hashcash]], the first symmetric proof-of-work function, which was itself also published on the same mailing-list, the previous year - May 1997. (Like the B-money proposal, bitcoin itself also uses the hashcash cost-function as the proof-of-work during coin minting). In B-Money, money is transferred by broadcasting the transaction to all participants, all of whom keep accounts of all others. Contracts can be made with possible reparation in case of default, with a third party agreeing to be the arbitrator. If there is no agreement, each party broadcasts arguments or evidence in its favor and each of the participants determines the reparations/fines in his accounts for himself.

The second protocol has only a subset of the participants (the "servers") keeping accounts, which they have to publish, and the participants who do transactions verifying their balances by asking many of them. The participants also verify that the money supply is not being inflated. An amount of money as bail is required to become a server, which is lost if the server is found to be dishonest.

An alternate method of creating money is proposed, via an auction where participants bid on the solution of computational problems of known complexity.

==External Links==
*[http://weidai.com/bmoney.txt b-money, an anonymous, distributed electronic cash system]
*[http://www.hashcash.org/ hashcash cost-function]
[[Category:Economics]]