Bitcoin Wiki - User contributions [en]

Satoshi (unit)

2018-02-15T15:40:55Z

Randolf: /* History */ Added BIP-176's proposed "Bits" terminology

[[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 block chain 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 block chain,<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
|-
| 里
| 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 representing 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

2018-02-04T14:59:02Z

Randolf: /* Illegal content in the block chain */ Fixed a spelling error, improved a link's title, and moved one portion into parenthesis

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

2018-02-04T14:55:02Z

Randolf: /* Tracing a coin's history */ Improved link to "Anonymity" article

== 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 - intially 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 re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. Various ideas have [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 been proposed] to further limit datastorage in the 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.
* 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
* 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

2018-02-04T14:51:00Z

Randolf: /* Sybil attack */ More improvements to the writing style

== 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 - intially 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. [[Anonymity|More info]].

=== 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 re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. Various ideas have [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 been proposed] to further limit datastorage in the 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.
* 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
* 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

2018-02-04T07:56:31Z

Randolf: /* Sybil attack */ Added a comma so the first paragraph makes sense

== 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 - intially 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. [[Anonymity|More info]].

=== Sybil attack ===
An attacker can attempt to fill the network with clients controlled by him, 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, disconnecting you from the network.
* The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.
* If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
* Low-latency encryption/anonymization of Bitcoin's transmissions (With Tor, JAP, etc.) can be defeated relatively easy 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 re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. Various ideas have [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 been proposed] to further limit datastorage in the 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.
* 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
* 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]]

Base58Check encoding

2017-11-27T09:11:24Z

Randolf: /* Base58 symbol chart */ Added a parenthesized note that 0, O, I, and l are excluded

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

==Background==
The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:
// Why base-58 instead of standard base-64 encoding?
// - Don't want 0OIl characters that look the same in some fonts and
// could be used to create visually identical looking account numbers.
// - A string with non-alphanumeric characters is not as easily accepted as an account number.
// - E-mail usually won't line-break if there's no punctuation to break at.
// - Doubleclicking selects the whole number as one word if it's all alphanumeric.

==Features of Base58Check==
Base58Check has the following features:
* An arbitrarily sized payload.
* A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
* One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
* Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
* An extra step for preservation of leading zeroes in the data.

==Creating a Base58Check string==
A Base58Check string is created from a version/application byte and payload as follows.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
# The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero '''byte''', as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''
A more detailed example is provided on the page describing the [[Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address | technical background]] of the bitcoin address.

==Encoding a Bitcoin address==
Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:
* Pay-to-script-hash (p2sh): payload is: <code>[[RIPEMD160]]([[SHA256]]('''redeemScript'''))</code> where '''redeemScript''' is a script the wallet knows how to spend; version <code>0x05</code> (these addresses begin with the digit '3')
* Pay-to-pubkey-hash (p2pkh): payload is <code>[[RIPEMD160]]([[SHA256]]('''ECDSA_publicKey'''))</code> where '''ECDSA_publicKey''' is a public key the wallet knows the private key for; version <code>0x00</code> (these addresses begin with the digit '1')

The resulting hash in both of these cases is always exactly 20 bytes.
These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key|ECDSA private keys]] in the [[wallet import format]].
This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer).
For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

==Base58 symbol chart==
The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin (the characters excluded are: 0, O, I, and l).
{| class="wikitable"
|-
!Value
!Character
!Value
!Character
!Value
!Character
!Value
!Character
|-
|0
|1
|1
|2
|2
|3
|3
|4
|-
|4
|5
|5
|6
|6
|7
|7
|8
|-
|8
|9
|9
|A
|10
|B
|11
|C
|-
|12
|D
|13
|E
|14
|F
|15
|G
|-
|16
|H
|17
|J
|18
|K
|19
|L
|-
|20
|M
|21
|N
|22
|P
|23
|Q
|-
|24
|R
|25
|S
|26
|T
|27
|U
|-
|28
|V
|29
|W
|30
|X
|31
|Y
|-
|32
|Z
|33
|a
|34
|b
|35
|c
|-
|36
|d
|37
|e
|38
|f
|39
|g
|-
|40
|h
|41
|i
|42
|j
|43
|k
|-
|44
|m
|45
|n
|46
|o
|47
|p
|-
|48
|q
|49
|r
|50
|s
|51
|t
|-
|52
|u
|53
|v
|54
|w
|55
|x
|-
|56
|y
|57
|z
|}

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is

code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();

==Version bytes==
Here are some common version bytes:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
|-
|0
|1
|Bitcoin pubkey hash
|-
|5
|3
|Bitcoin script hash
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|-
|52
|M or N
|Namecoin pubkey hash
|-
|128
|5
|Private key
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== See Also ==
* [http://lenschulwitz.com/base58 Online Base58 Decoder, Encoder, and Validator]

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp "Satoshi" C++ codebase (decode and encode, no external libraries needed)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [http://lenschulwitz.com/b58/base58perl.txt Base58 Decode, Encode, and Validate in Perl]

[[Category:Technical]]

[[es:Codificación Base58Check]]

Proof of Stake

2017-11-10T03:09:50Z

Randolf: /* Motivation For Proof of Stake */ Fixed formatting of numbered points

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 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 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 continue 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 which 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 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 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 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 a 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 remain 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 proportional to 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 reward.

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. 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 allows the stake signing key to spend 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 be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once 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 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 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 criteria.
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 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 which 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 block chain 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.

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

Proof of Stake

2017-11-10T03:03:45Z

Randolf: Corrected name of BitcoinTalk.org member "QuantumMechanic" and linked the name to QuantumMechanic's profile page there.

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:
1) Executing an attack would be much more expensive.
2) 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 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 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 continue 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 which 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 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 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 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 a 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 remain 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 proportional to 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 reward.

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. 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 allows the stake signing key to spend 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 be able to spend up to 2.3% of their balance per week and will only lose 2.3% in the event of theft. Once 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 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 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 criteria.
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 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 which 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 block chain 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.

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

Technical background of version 1 Bitcoin addresses

2017-10-28T06:34:49Z

Randolf: /* Collisions (lack thereof) */ Referred to the Large Bitcoin Collider project as an example

[[File:PubKeyToAddr.png|thumb|right|Conversion from ECDSA public key to Bitcoin Address]]
This article may be too technical for some users. The more basic article on [[Address|Bitcoin Addresses]] may be more appropriate.

A [[Bitcoin address]] is a 160-bit hash of the public portion of a public/private [[Wikipedia:Elliptic_Curve_DSA|ECDSA]] keypair. Using [[Wikipedia:Public-key_cryptography|public-key cryptography]], you can "sign" data with your [[private key]] and anyone who knows your public key can verify that the signature is valid.

A new keypair is generated for each receiving address (with newer [[Deterministic wallet | HD wallets]], this is done deterministically).
The public key and their associated private keys (or the seed needed to generate them) are stored in the [[wallet]] data file.
This is the only file users should need to [[backup|backup]].
A "send" transaction to a specific Bitcoin address requires that the corresponding wallet knows the private key implementing it.
This has the implication that if you create an address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins received with that address are lost; this is not an issue for HD wallets where all addresses are generated from a single seed.
Addresses are added to an address [[key pool]] prior to being used for receiving coins. If you lose your wallet entirely, all of your coins are lost and can never be recovered.

Bitcoin allows you to create as many addresses as you want, and use a new one for every transaction.
There is no "master address": the "Your Bitcoin address" area in some wallet UIs has no special importance.
It's only there for your convenience, and it should change automatically when used.

Bitcoin addresses contain a built-in check code, so it's generally not possible to send Bitcoins to a mistyped address. However, if the address is well-formed but no one owns it (or the owner lost their wallet.dat), any coins sent to that address will be lost forever.

Hash values and the checksum data are converted to an alpha-numeric representation using a custom scheme: the [[Base58Check encoding]] scheme. Under Base58Check, addresses can contain all alphanumeric characters except 0, O, I, and l. Normal addresses currently always start with 1 (addresses from script hashes use 3), though this might change in a future version. Testnet addresses usually start with ''m'' or ''n''. Mainline addresses can be 25-34 characters in length, and testnet addresses can be 26-34 characters in length. Most addresses are 33 or 34 characters long.

== Collisions (lack thereof) ==
Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a [[Wikipedia:Collision_(computer_science)|collision]]. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner's entire wallet (or vice versa). If you were to intentionally try to make a collision, it would currently take 2^107 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and [[transaction fee|transaction fees]] than to try to create collisions, as demonstrated by projects like the [https://lbc.cryptoguru.org/ Large Bitcoin Collider] which attempt to generate address collisions.

It is more likely that the Earth is destroyed in the next 5 seconds, than that a collision occur in the next millenium.

==How to create Bitcoin Address==
0 - Having a private [[ECDSA]] key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
1 - Take the corresponding public key generated with it (65 bytes, 1 byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes corresponding to Y coordinate)
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
2 - Perform [[SHA-256]] hashing on the public key
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
3 - Perform [[RIPEMD-160]] hashing on the result of SHA-256
010966776006953D5567439E5E39F86A0D273BEE
4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main Network)
00010966776006953D5567439E5E39F86A0D273BEE
''(note that below steps are the [[Base58Check encoding]], which has multiple library options available implementing it)'' 
5 - Perform SHA-256 hash on the extended RIPEMD-160 result
445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094
6 - Perform SHA-256 hash on the result of the previous SHA-256 hash
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30
7 - Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
D61967F6
8 - Add the 4 checksum bytes from stage 7 at the end of extended RIPEMD-160 hash from stage 4. This is the 25-byte binary Bitcoin Address.
00010966776006953D5567439E5E39F86A0D273BEED61967F6
9 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the most commonly used Bitcoin Address format
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

==See Also==
* [[Address]]
* [[Base58Check encoding]]
* [http://gobittest.appspot.com/Address Address testing suite]
* [http://lenschulwitz.com/base58 Online Address Validator and Base58 Encoder/Decoder]

[[Category:Technical]]

{{Bitcoin Core documentation}}

Mining

2017-10-22T15:31:44Z

Randolf: /* The Difficulty Metric */ Various improvements to the writing

[[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 is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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 12.5 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 unwise in some countries and setups.

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

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

Mining

2017-10-22T15:26:18Z

Randolf: Linked both instances of the phrase "mining rig" to the Mining_rig page

[[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 is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless.

=== 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 12.5 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 unwise in some countries and setups.

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

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

Mining

2017-10-22T15:23:40Z

Randolf: /* Mining services (Cloud mining) */

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "mining rig"]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "mining rig" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining").
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless.

=== 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 12.5 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 unwise in some countries and setups.

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

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

Mining

2017-10-22T15:22:30Z

Randolf: Changed "colloquial term" to "colloquial metaphor"

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "mining rig"]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "mining rig" is a colloquial metaphor for a single computer system that performs the necessary computations for "mining").
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless.

=== 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 12.5 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 unwise in some countries and setups.

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

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

Mining

2017-10-22T15:21:14Z

Randolf: Changed "quick and dirty" to "home-made" and also added information about the meaning of the colloquial term "mining rig"

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A home-made "mining rig"]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions (and a "mining rig" is a colloquial term for a single computer system that performs the necessary computations for "mining").
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless.

=== 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 12.5 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 unwise in some countries and setups.

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

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

Mining

2017-10-22T15:17:10Z

Randolf: /* History */

[[File:Quick-and-dirty-4x5970-cooling.jpg|thumb|right|A quick and dirty mining rig]]
== Introduction ==
'''Mining''' is the process of adding transaction records to Bitcoin's public ledger of past transactions.
This ledger of past transactions is called the [[block chain]] as it is a chain of [[block|blocks]].
The block chain serves to [[Confirmation|confirm]] transactions to the rest of the network as having taken place.
Bitcoin nodes use the block chain 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 allow Bitcoin nodes to reach a secure, tamper-resistant consensus.
Mining is also the mechanism used to 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 currency available at a rate that resembles the rate at which commodities like gold are mined from the ground.

== 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. It is recalculated every 2016 blocks to a value such that the previous 2016 blocks would have been generated in exactly two weeks had everyone been mining at this difficulty. This will yield, on average, one block every ten minutes. As more miners join, the rate of block creation will go up. As the rate of block generation goes up, the difficulty rises to compensate which will push the rate of block creation back down. Any blocks released by malicious miners that do not meet the required difficulty [[Target|target]] will simply be rejected by everyone on the network and thus will be worthless.

=== 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 12.5 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 unwise in some countries and setups.

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

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

Vocabulary

2017-10-19T22:51:38Z

Randolf: /* Generate Bitcoins */

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis, or 1.00000000 bitcoin.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
The process by which new bitcoins (a.k.a., the "Block Reward") are distributed via [[Mining]].

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest [[Block Chain]].

=====Memory pool=====
Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each Bitcoin client currently running within the network is referred to as a Node of the system.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a Satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

[[Category:Technical]]
[[Category:Vocabulary| ]]

{{Bitcoin Core documentation}}

Vocabulary

2017-10-19T22:50:20Z

Randolf: /* BTC */

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis, or 1.00000000 bitcoin.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
The process by which new bitcoins (aka the "Block Reward") are distributed via [[Mining]].

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest [[Block Chain]].

=====Memory pool=====
Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each Bitcoin client currently running within the network is referred to as a Node of the system.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a Satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

[[Category:Technical]]
[[Category:Vocabulary| ]]

{{Bitcoin Core documentation}}

Vocabulary

2017-10-19T22:49:20Z

Randolf: /* Branching Point */ Added a period to the end of this single-sentence paragraph.

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches.

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
The process by which new bitcoins (aka the "Block Reward") are distributed via [[Mining]].

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest [[Block Chain]].

=====Memory pool=====
Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each Bitcoin client currently running within the network is referred to as a Node of the system.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a Satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

[[Category:Technical]]
[[Category:Vocabulary| ]]

{{Bitcoin Core documentation}}

Vocabulary

2017-10-19T22:48:45Z

Randolf: /* Block Reward */

{| align="right"
| __TOC__
|}

=====Bitcoin=====
The name of a decentralized p2p crypto-currency network.

=====[[Bitcoins]]=====
Digital currency units generated and used within the Bitcoin system. Common abbreviations include BTC, XBT or lowercase ''bitcoin'' when referring to units of the currency.

=====[[Block]]=====
Blocks are links in a chain of transaction verifications. Outstanding transactions get bundled into a block and are verified roughly every ten minutes on average. Each subsequent block strengthens the verification of previous blocks. Each block contains one or more transactions.

=====[[Block Chain]]=====
Each block includes the difficult-to-produce verification hash of the previous block. This allows each subsequent block to be linked to all previous blocks. These blocks which are linked together for the purpose of verifying transactions within blocks is called the block chain.

=====[[Mining#Reward|Block Reward]]=====
When a Bitcoin miner finds a block, it receives newly minted bitcoins known as the "Block Reward." The reward (a.k.a., subsidy) is halved every four years and is responsible for bitcoin's [[controlled supply]].

=====Branching Point=====
The block at which the block chain diverges into multiple chain branches

=====BTC=====
The common decimal [[Units|unit]] of a single bitcoin. Equal to 100,000,000 satoshis.

=====[[Checkpoint Lockin]]=====
Every once in a while, an old block hash is hardcoded into Bitcoin software. Different implementations choose different checkpoint locations. Checkpoints prevent various DOS attacks from nodes flooding unusable chains and attacks involving isolating nodes and giving them fake chains. Satoshi announced the feature [https://bitcointalk.org/index.php?topic=437 here] and it was discussed to death [https://bitcointalk.org/index.php?topic=1647 here].

=====Coinbase=====
"Coinbase" is another name for a generation transaction. The input of such a transaction contains some arbitrary data where the scriptSig would go in normal transactions -- this data is sometimes called the "coinbase", as well.

=====[[Confirmation]]=====
To protect against double spending, a transaction should not be considered as "confirmed" until a certain number of blocks in the block chain confirm, or verify that the transaction. The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction.

=====[[Difficulty]]=====
Every 2016 blocks, Bitcoin adjusts the difficulty of verifying blocks based on the time it took to verify the previous 2016 blocks. The difficulty is adjusted so that given the average estimated computing power of the whole bitcoin network, only one block will verified on average every ten minutes for the next 2016 blocks. The difficulty is usually expressed as a number, optionally accurate to many decimal places (eg. in [http://blockexplorer.com/b/100000 block 100,000] it was 14,484.162361. The difficulty is inversely proportional to the hash target, which is expressed as a hex number with around 50 digits, and is the number under which a block's generated hash must be to qualify as an officially verified block. The hash target is equal to ((65535 << 208) / difficulty). Difficulty is also often called block difficulty, hash difficulty, verification difficulty or the difficulty of generating bitcoins.

=====[[Double-spending|Double-Spending]]=====
Attempting to spend coins that have already been spent in another transaction

=====Generate Bitcoins=====
The process by which new bitcoins (aka the "Block Reward") are distributed via [[Mining]].

=====[[Hash]]=====
The output of a cryptographic [[#Hash_function|hash function]].

=====Hash function=====
A computer algorithm which takes an arbitrary amount of input data and deterministically produces fixed length output, known as the data's "hash", that can be used to easily verify that data has not been altered. If you change any single bit of the original data and run the hash algorithm, the hash will completely change. Because the hash is seemingly random, it is prohibitively difficult to try to produce a specific hash by changing the data which is being hashed.

=====Low Priority=====
See Priority.

=====Main Chain=====
The longest [[Block Chain]].

=====Memory pool=====
Generators store [[transactions]] waiting to get into a block in their memory pool after receiving them. Received transactions are stored even if they are invalid to prevent nodes from constantly requesting transactions that they've already seen. The memory pool is cleared when Bitcoin is shut down, causing the [[network]] to gradually forget about transactions that haven't been included in a [[block]].

=====Merkle root=====
Every [[transactions|transaction]] has a [[hash]] associated with it. In a [[block]], all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the [[block hashing algorithm|block header]]. With this scheme, it is possible to securely verify that a transaction has been accepted by the network (and get the number of confirmations) by downloading just the tiny block headers and [[Wikipedia:Merkle tree|Merkle tree]] -- downloading the entire block chain is unnecessary. This feature is currently not used in Bitcoin, but it will be in the future.

===== Miner=====
Computer software which is designed to repeatedly calculate hashes with the intention to create a successful block and earn coins from transaction fees and new coins created with the block itself. The term references an analogy of gold miners who dig gold out of the ground and thus "discover" new gold that can be used to create new coins with a similar kind of discovery occurring with a successful hash to create new Bitcoins.

=====Node=====
Each Bitcoin client currently running within the network is referred to as a Node of the system.

=====Nonce=====
A nonce is an otherwise meaningless number which is used to alter the outcome of a hash. Each time Bitcoin hashes a block, it increments a nonce within the block which it is trying verify. If the numeric value of the effectively random hash is below a certain amount determined by the block generation difficulty, then the block is accepted by other clients and gets added to the chain.

=====[[Orphan Block]]=====
An orphan block is a block which has no known parent in the currently-longest [[block chain]]. Not to be confused with a [[#Stale_Block|Stale Block]] (which has a known parent, but is no longer part of the longest chain).

=====Orphan root=====
The root (first) block in an [[Orphan Block|orphan]] block chain.

=====Priority=====
A scoring mechanism to help ensure that expensive data storage isn't consumed by lower quality and spam. Low priority transactions will not get included by a miner if the limited space is already filled by higher priority transactions. A [[Transaction Fee|transaction fee]] will affect priority.

=====[[Proof of work]]=====
A result that can only be obtained through the use of computational resources. Changing the data in the proof of work requires redoing the work.

=====Reorganize=====
A block chain reorganize (or '''reorg''') happens when one chain becomes longer than the one you are currently working on. All of the blocks in the old chain that are not in the new one become orphan blocks, and their generations are invalidated. Transactions that use the newly-invalid generated coins also become invalid, though this is only possible in large chain splits because generations can't be spent for 100 blocks. The number of confirmations for transactions may change after a reorg, and transactions that are not in the new chain will become "0/unconfirmed" again. If a transaction in the old chain conflicts with one in the new chain (as a result of double-spending), the old one becomes invalid.

=====Satoshi=====
The base unit of Bitcoin (0.00000001 BTC) is sometimes called a Satoshi, after Bitcoin's creator [[Satoshi Nakamoto]].

=====Seed Nodes=====
Nodes whose IP addresses are included in the [[Original Bitcoin client|Bitcoin client]] for use during a new installation when the normal bootstrapping process through IRC wasn't possible.

=====Stale Block=====
A well-formed block which is no longer part of the difficultywise-longest and well-formed blockchain. Not to be confused with an [[#Orphan_Block|Orphan Block]] (which has no known parent in the longest [[block chain]]).

=====Subsidy=====
See "[[#Block_Reward|Block Reward]]" above.

=====Super Nodes=====
A participant in a p2p network which connects to as many other nodes as possible.

=====[[Tonal Bitcoin]]=====
Adaptation of Bitcoin to the [http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29 Tonal System]. 1 TBC is defined as 1,0000 (65,536 decimal) base bitcoin units. Not widely used.

=====[[Transaction Fee]]=====
A voluntary fee which can be added to a transaction which is used as an incentive to add the bitcoin transaction to a block. The fee determines the likelihood of inclusion in any given block, where a high fee included with a transaction has a priority over transactions with a lower fee included or no fee at all.

=====Virgin bitcoin=====
The reward for generating a [[Block|block]] that has not yet been spent, a state which might increase the ability to transact [[anonymity|anonymously]].

[[Category:Technical]]
[[Category:Vocabulary| ]]

{{Bitcoin Core documentation}}