Bitcoin Wiki - User contributions [en]

Bitcoin Market

2016-11-01T08:43:21Z

Dooglus: fix forum URLs

The '''Bitcoin Market''' is a former [[bitcoin]] [[currency exchange]] site owned and operated by dwdollar.

==History==

Trading on the site began February 6th, 2010<ref>[https://bitcointalk.org/index.php?topic=20.msg265#msg265 Announcement by dwdollar]</ref>

A major update to the site occurred in March, 2011. Among the changes were: smaller minimum trade size, 24 X 7 trading, and some steps to help ensure that payment will be made for trades that execute.

Though the site at one time was used for trading using PayPal as payment method, fraud caused the exchange to discontinue PayPal trading on June 4, 2011<ref>[https://bitcointalk.org/index.php?topic=12678 Recent Events At Bitcoin Market]</ref>.

Important information can also be gained from the Bitcoin Market website homepage which shows a graph of the Bitcoin exchange rate (to US Dollars). This data is also offered in the JSON format.

==See Also==

* [[Buying bitcoins]]

==External Links==

* [http://darknetmarkets.co/ Darknet Bitcoin Markets list]
* [https://www.bitcoinmarket.com/ Bitcoin Market]

==References==
<References />

Brainwallet

2016-07-18T15:02:16Z

Dooglus: Correct spelling errors

A '''brainwallet''' refers to the concept of storing Bitcoins in one's own mind by memorizing a mnemonic recovery seed. If the mnemonic is not recorded anywhere, the Bitcoins can be thought of as being held only in the mind of the owner. If a brainwallet is forgotten or the person dies or is permanently incapacitated, the Bitcoins are lost forever. Using techniques like memory pegging allow them to be memorized and recalled easily.

To create a brainwallet, use Bitcoin wallet software to generate a mnemonic seed and then memorize it. Such seeds are generated by wallets like [[Electrum]], [[Armory]] and [[Mycelium]].

=Worked Example=

# On a computer with no malware, run [[Electrum]] and generate the 13-word recovery seed.
# Memorize the seed using http://en.wikipedia.org/wiki/Mnemonic_peg_system
# When spending or saving, restore the wallet from memory using the seed.
# Use the master public key to create an online watch-only wallet, where you can send to but not spend.
# Spend from the wallet in the manner of [[Cold_storage|deep cold storage]]. Transferring the unsigned transaction to the cold storage computer, signing it and broadcasting to the network.

==Example Mnemonic Peg==
To memorize a mnemonic seed with this method you must invent a story which hits the words as "keynotes". Try to make it like a fairy tale story, use imagery. Make it somehow striking and emotionally resonant. When remembering you just remember the key words, not all the other words - the other can be remembered more as images and thoughts (which are hard to write down)

Let's say we have this seed:

witch collapse practice feed shame open despair creek road again ice least

You'd imagine walking through a building familiar to you, maybe your own home or workplace or school.

* You imagine looking in the first room and seeing your mother dressed as a '''witch''', playing the jenga boardgame until the tower '''collapses'''.
* You walk to the next room and see your father '''practising''' with a longbow, he shoots a chicken to '''feeds''' himself.
* In the next room you see your brother naked in '''shame''' attempting to cover himself, he's looking through a window that's '''open''' and flapping in the wind.
* Now you reach the kitchen, girlfriend is looking at Picasso's [https://en.wikipedia.org/wiki/Guernica_%28Picasso%29 Guernica] on the wall. She is in '''despair''' from it. Next to it is a television playing the show Dawson's '''Creek'''.
* Next you're in the garage, your childhood friend is working on his car. He plans to go on a '''road''' trip for the 5th time this month, he's going '''again'''.
* Finally to go outside to the garden. It's early spring and the ground is covered in melting '''ice'''. Two of your other friends are there, one friend has a huge basket of apples, the other has a smaller basket but you're holding only some apples. You've got the '''least''' apples.

Repeat this story in your head several times over a short period - the first few days. It will sink in, deep, after that. You'll only have to revisit it very occasionally. After a while you can ignore it for months and it'll still come back, not that I'd recommend relying on that.

==Video Example of Mnemonic Peg Method==

From the BBC documentary The Human Mind (2003) by Professor Robert Winston. Approximately 31 minutes in. Memorizing a list of 30 random words.

https://www.youtube.com/watch?v=lRhfQCW1f68&t=1867

==Fallible Memory==
Despite the memory aids, human memory can be very fallible. So if your only storage is memory you may find that it just vanished one day. Keeping a copy stored on paper somewhere could be a useful backup, depending on circumstances.

=Obsolete Brainwallet Style=

An early old-style brainwallet was created by by memorization of a passphrase and converting it a [[private key]] with a hashing or key derivation algorithm (example: SHA256). That private key is then used to compute a Bitcoin address. This method was found to be very insecure and '''should not be used'''. Humans are not a good source of entropy. Using a single address also has problems associated with [[address reuse]].

==Low Entropy from Human-Generated Passphrases==

Practically everyone who knows about or cares loudly yells at people DO NOT USE BRAINWALLETS [GENERATED BY HUMANS]. We've seen pretty concrete evidence that users are resistant to good advice in this space, and they are shocked when their favorite quotation is cracked and they lose their coins (But it was 60 characters long! I even added a special character! how is this possible?!), the existing sites promoting this stuff won't use a KDF stronger than SHA256*1 because "users are stupid if they use weak passwords". <ref>[https://bitcointalk.org/index.php?topic=311000.msg3345309#msg3345309 Re: hardening brain-wallets with a useful blind proof of work ]</ref>

==Ryan Castellucci DEFCON Talk==

Ryan Castellucci gave a talk at DEFCON23 about cracking brainwallet passphrases. Although brainwallet passphrases were being exploited for years by this point, the talk helped bring the issues to more popular consciousness.<ref>[https://rya.nc/cracking_cryptocurrency_brainwallets.pdf Ryan Castellucci DEFCON Talk]</ref><ref>[https://www.reddit.com/r/Bitcoin/comments/3g9f1s/why_im_releasing_a_brainwallet_cracker_at_defcon/ Reddit thread on Ryan's talk]</ref><ref>[https://www.youtube.com/watch?v=foil0hzl4Pg a video of Ryan's talk]</ref>

==Legacy Code==

If you have coins in an old-style brainwallet, the website http://www.bitaddress.org/ contains a GUI for generating the private key using the sha256(passphrase) algorithm.

=References=
<references>
</references>

Zero Knowledge Contingent Payment

2016-02-27T04:06:44Z

Dooglus: /* Further mproving privacy */ typos

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

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

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

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

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

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

===Zero knowledge proof to binding===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zero Knowledge Contingent Payment

2016-02-27T03:59:16Z

Dooglus: /* Hash locked transactions */ typo

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

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

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

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

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

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

===Zero knowledge proof to binding===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scalability FAQ

2016-01-24T02:32:51Z

Dooglus: /* Does it reduce the risk of a hard fork? */ fix typo

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''

Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and new estimates<ref name="garzik_bip" /> place the
theoretical maximum at 7 TPS with current Bitcoin consensus rules
(including the 1MB block size limit).

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.

==== O(n2) network total validation resource requirements ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref>
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees).

Miners who have more transactions available to them than they have room in the blocks they choose to make, typically choose to maximize their revenue by including the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions.

If blocks become full on a regular basis, users who pay the minimum fee will have to wait a longer and longer time for their transactions to confirm. At this point, a fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

=== What is the most efficient way to scale Bitcoin? ===

Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.

If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development.

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>

== General Block Size Increase Theory ==

Questions about increasing the block size in general, not related to any
specific proposal.

==== Why are some people in favor of keeping the block size at 1 MB forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref>
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref>
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref>
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" />

== Specific Scaling Proposals ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What is the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will be as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2016-01-24T02:16:55Z

Dooglus: /* Should miners be allowed to decide the block size? */ fix typo

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''

Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and new estimates<ref name="garzik_bip" /> place the
theoretical maximum at 7 TPS with current Bitcoin consensus rules
(including the 1MB block size limit).

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.

==== O(n2) network total validation resource requirements ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref>
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees).

Miners who have more transactions available to them than they have room in the blocks they choose to make, typically choose to maximize their revenue by including the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions.

If blocks become full on a regular basis, users who pay the minimum fee will have to wait a longer and longer time for their transactions to confirm. At this point, a fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

=== What is the most efficient way to scale Bitcoin? ===

Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.

If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development.

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>

== General Block Size Increase Theory ==

Questions about increasing the block size in general, not related to any
specific proposal.

==== Why are some people in favor of keeping the block size at 1 MB forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref>
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine improperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref>
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref>
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" />

== Specific Scaling Proposals ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What is the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Scalability FAQ

2016-01-24T01:59:46Z

Dooglus: /* Doesn’t Lightning require bigger blocks anyway? */ 180 times more != 180,000% more

Answers to commonly-asked questions and concerns about scaling Bitcoin, including “level 1” solutions such as increasing the block size and “level 2” solutions such as the proposed Lightning network.

== Background ==

Questions about how Bitcoin currently works (related to scaling) as well as questions about the technical terminology related to the scaling discussion.

=== What is the short history of the block size limit? ===

''Note: the software now called Bitcoin Core was previously simply called “Bitcoin”.<ref>[https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core Bitcoin Core 0.9.0 release notes], Bitcoin.org, 19 March 2014</ref> To avoid confusion with the Bitcoin system, we’ll use the Bitcoin Core name.''

Bitcoin Core was initially released without an explicit block size limit. However, the code did limit network messages to a maximum of 32 MiB, setting an effective upper bound on block size.<ref>[https://bitcointalk.org/index.php?topic=68121 Earliest known Bitcoin code], <code>src/main.h:17</code></ref>

Around 15 July 2010, Satoshi Nakamoto changed Bitcoin Core’s mining code so that it wouldn’t create any blocks larger than 990,000 bytes.<ref>[https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349 Bitcoin Core commit a30b56e], Satoshi Nakamoto, 15 July 2010</ref>

Two months later on 7 September 2010, Nakamoto changed Bitcoin Core’s consensus rules to reject blocks larger than 1,000,000 bytes (1 megabyte) if their block height was higher than 79,400.<ref>[https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730 Bitcoin Core commit 8c9479c], Satoshi Nakamoto, 7 September 2010</ref> (Block 79,400 was later produced on 12 September 2010.<ref>[https://www.biteasy.com/blockchain/blocks/000000000021d821ec06be7173f413690bc5c4bc648dfa70b3b6763236f055b7 Block height 79400], dated 12 September 2010</ref>)

Neither the July nor the September commit message explains the reason for the limit, although the careful attempt to prevent a fork may indicate Nakamoto didn’t consider it an emergency.

Nakamoto’s subsequent statements supported raising the block size at a later time<ref>[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 Increasing the block size when needed], Satoshi Nakamoto, 3 October 2010</ref>, but he never publicly specified a date or set of conditions for the raise.

=== What is this Transactions Per Second (TPS) limit? ===

The current block size limit is 1,000,000 bytes (1 megabyte)<ref>[https://github.com/bitcoin/bitcoin/blob/41076aad0cbdfa4c4cf376e345114a5c29086f81/src/consensus/consensus.h#L10 <code>MAX_BLOCK_SIZE</code>], retrieved 2 July 2015</ref>, although a small amount of that space (such as the block header) is not available to store transactions.<ref>[https://bitcoin.org/en/developer-reference#serialized-blocks Block serialization description], Bitcoin.org Developer Reference</ref>

Bitcoin transactions vary in size depending on multiple factors, such as whether they’re spending single-signature inputs or a multiple signature inputs, and how many inputs and outputs they have.

The simple way to calculate the number of Transactions Per Second (TPS) Bitcoin can handle is to divide the block size limit by the expected average size of transactions, divided by the average number of seconds between blocks (600). For example, if you assume average transactions are 250 bytes,

<pre>6.6 TPS = 1,000,000 / 250 / 600</pre>

There seems to be general agreement that Bitcoin in 2015 can handle about 3 TPS with the current average size of transactions.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007986.html Max TPS based on current average transaction size], Mike Hearn, 8 May 2015</ref><ref name="maxwell_not_proposing">[https://www.reddit.com/r/Bitcoin/comments/39yaod/bitcoinorg_position_on_hard_forks/cs7qz5c "No one proposing 3 TPS forever"], Gregory Maxwell, 15 June 2015</ref>

Both old estimates<ref>[[Scalability]], Bitcoin Wiki, retrieved 7 July
2015</ref> and new estimates<ref name="garzik_bip" /> place the
theoretical maximum at 7 TPS with current Bitcoin consensus rules
(including the 1MB block size limit).

=== What do devs mean by the scaling expressions O(1), O(n), O(n2), etc…? ===

[https://en.wikipedia.org/wiki/Big_O_notation Big O notation] is a shorthand used by computer scientists to describe how well a system scales. Such descriptions are rough approximations meant to help predict potential problems and evaluate potential solutions; they are not usually expected to fully capture all variables.

* '''O(1)''' means a system has roughly the same properties no matter how big it gets.
* '''O(n)''' means that a system scales linearly: doubling the number of things (users, transactions, etc.) doubles the amount of work.
* '''O(n2)''' means that a system scales quadratically : doubling (2x) the number of things quadruples (4x) the amount of work. Often written O(n^2) is places without convenient superscripts.
* Additional examples may be found in the [https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions Wikipedia article]

The following subsections show cases where big O notation has been applied to the scaling Bitcoin transaction volume.

==== O(1) block propagation ====

Bitcoin Core currently relays unconfirmed transactions and then later relays blocks containing many of the same transactions. This redundant relay can be eliminated to allow miners to propagate large blocks very quickly to active network nodes, and would also significantly reduce miner need for peak bandwidth. Currently most miners use a network<ref name="block_relay_net">[http://bitcoinrelaynetwork.org/ Matt Corallo's block relay network]</ref> that is about 25x more efficient than stock Bitcoin Core<ref>[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#i-know-that-you-know IBLT design document], Gavin Andresen, 11 August 2014</ref> and almost equally as effective as O(1) block propagation for current block sizes.

==== O(n2) network total validation resource requirements ====

[[File:On2_scaling_illustrated.png|thumb|right|visualization of O(n2) scaling]]

Each on-chain Bitcoin transaction needs to be processed by each full node. If we assume that a certain percentage of users run full nodes (''n'') and that each user creates a certain number of transactions on average (''n'' again), then the network’s total resource requirements are <code>n2 = n * n</code>. In short, this means that the aggregate cost of keeping all transactions on-chain quadruples each time the number of users doubles.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009199.html Total system cost], Dr. Adam Back, 28 June 2015</ref> For example,

* Imagine a network starts with 100 users and 2 total nodes (a 2% ratio).
* The network doubles in users to 200. The number of nodes also doubles to 4 (maintaining a 2% ratio of decentralized low-trust security). However, double the number of users means double the number of transactions, and each node needs to process ''every'' transaction---so each node now does double work with its bandwidth and its CPU. With double the number of nodes and double the amount of work per node, total work increases by four times.
* The network doubles again: 400 users, 8 nodes (still 2% of total), and 4 times the original workload per node for a total of 16 times as much aggregate work as the original.
* Another doubling: 800 users, 16 nodes (still 2%), and 8 times the original workload per node for a total of 64 times aggregate work as the original.
* Another doubling: 1,600 users—sixteen times the original---with 32 nodes (still 2%), and 16 times the original workload per node. The aggregate total work done by nodes is 256 times higher than it was originally.

=== What’s the difference between on-chain and off-chain transactions? ===

On-chain Bitcoin transactions are those that appear in the Bitcoin block chain. Off-chain transactions are those that transfer ownership of bitcoins without putting a transaction on the block chain.

Common and proposed off-chain transactions include:

* '''Exchange transactions:''' when you buy or sell bitcoins, the exchange tracks ownership in a database without putting data in the block chain. Only when you deposit or withdraw bitcoins does the transaction appear on the block chain.
* '''Web wallet internal payments:''' many web wallets allow users of the service to pay other users of the same service using off-chain payments. For example, when one Coinbase user pays another Coinbase user.
* '''Tipping services:''' most tipping services today, such as ChangeTip, use off-chain transactions for everything except deposits and withdrawals.<ref>[https://www.changetip.com/fees ChangeTip fees], retrieved 3 July 2015</ref>
* '''Payment channels:''' channels are started using one on-chain transaction and ended using a second on-chain transaction.<ref>[https://bitcoin.org/en/developer-guide#micropayment-channel Micropayment channels], Bitcoin.org Developer Guide</ref> In between can be an essentially unlimited number of off-chain transactions as small as a single satoshi (1/100,000,000th of a bitcoin). Payment channels include those that [https://bitcoinj.github.io/working-with-micropayments exist today] as well as proposed hub-and-spoke channels and the more advanced [http://lightning.network/ Lightning network].

Approximately 90% to 99% of all bitcoin-denominated payments today are made off-chain.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008844.html Pure off-chain is a weak form of layer 2], Dr. Adam Back, 19 June 2015</ref>

=== What is a fee market? ===

When you create a Bitcoin transaction, you have the option to pay a [[transaction fee]]. If your software is flexible, you can pay anything from zero fees (a free transaction) to 100% of the value of the transaction (spend-to-fees).

Miners who have more transactions available to them than they have room in the blocks they choose to make, typically choose to maximize their revenue by including the transactions that pay the most fees per kilobyte of data.<ref name="fee_pri">[https://bitcointalk.org/index.php?topic=95837.0 Fee prioritization patch], Gavin Andresen, 26 July 2012</ref> This confirms higher-fee transactions before lower-fee transactions.

If blocks become full on a regular basis, users who pay the minimum fee will have to wait a longer and longer time for their transactions to confirm. At this point, a fee market may arise where transactions that pay higher fees get confirmed significantly faster than transactions that pay low fees.<ref name="todd_coinwallet">[https://gist.github.com/petertodd/8e87c782bdf342ef18fb Comments on the CoinWallet.eu tx-flood stress-test], Peter Todd, 22 June 2015</ref><ref name="garzik_bip" />

=== What is the most efficient way to scale Bitcoin? ===

Remove its decentralization properties, specifically decentralized mining and decentralized full nodes. Mining wastes enormous amounts of electricity to provide a decentralized ledger and full nodes waste an enormous amount of bandwidth and CPU time keeping miners honest.

If users instead decided to hand authority over to someone they trusted, mining and keeping miners honest wouldn’t be needed. This is how Visa, MasterCard, PayPal, and the rest of the centralized payment systems works—users trust them, and they have no special difficulty scaling to [[scalability|millions of transactions an hour]]. It’s very efficient; it isn’t decentralized.

=== What is a hard fork, and how does it differ from other types of forks? ===

The word fork is badly overloaded in Bitcoin development.

* '''[[hardfork|Hard fork]]:''' a change to the system which is not backwards compatible. Everyone needs to upgrade or things can go wrong.
* '''[[softfork|Soft fork]]:''' a change to the system which is backwards compatible as long as a majority of miners enforce it. Full nodes that don’t upgrade have their security reduced.
* '''Chain fork:''' when there are two are more blocks at the same height on a block chain. This typically happens a few times a week by accident, but it can also indicate more severe problems.
* '''[https://en.wikipedia.org/wiki/Fork_%28software_development%29 Software fork]:''' using the code from an open source project to create a different project.
* '''[https://help.github.com/articles/fork-a-repo/ Git/GitHub fork]:''' a way for developers to write and test new features before contributing them to a project.

(There are other types of software-related forks, but they don’t tend to cause as much confusion.)

=== What are the block size soft limits? ===

Bitcoin Core has historically come pre-configured to limit blocks it mines to certain sizes.<ref name="fee_pri" /> These “limits” aren’t restrictions placed on miners by other miners or nodes, but rather configuration options that help miners produce reasonably-sized blocks.

Miners can change their soft limit size (up to 1 MB) using <code>-blockmaxsize=<size></code>

Default soft limits at various times:

* '''July 2012:''' <code>-blockmaxsize</code> option created and set to default 250 KB soft limit<ref>[https://github.com/bitcoin/bitcoin/commit/c555400ca134991e39d5e3a565fcd2215abe56f6 Bitcoin Core commit c555400], Gavin Andresen, 12 July 2012</ref>
* '''November 2013:''' Raised to 750KB<ref>[https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0 Bitcoin Core commit ad898b40], Gavin Andresen, 27 November 2013</ref>
* '''June 2015:''' Raise to 1 MB suggested<ref>[https://github.com/bitcoin/bitcoin/pull/6231 Bitcoin Core pull #6231], Chris Wheeler, 4 June 2015</ref>

== General Block Size Increase Theory ==

Questions about increasing the block size in general, not related to any
specific proposal.

==== Why are some people in favor of keeping the block size at 1 MB forever? ====

It is commonly claimed<ref name="garzik_bip" /><ref>[https://epicenterbitcoin.com/podcast/082/ Epicenter Bitcoin podcast #82], Mike Hearn (interviewed), 8 June 2015</ref> that there are people opposed to ever raising the maximum block size limit, but no Bitcoin developers have suggested keeping the maximum block size at one megabyte forever.<ref name="maxwell_not_proposing" />

All developers support raising the maximum size at some point<ref>[https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/cs5hj8l Nothing magic about 1MB], Dr. Adam Back, 13 June 2015</ref><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008328.html Regarding size-independent new block propagation], Pieter Wuille, 28 May 2015</ref>—they just disagree about whether now is the correct time.

==== Should miners be allowed to decide the block size? ====

A block may include as little as a single transaction, so miners can always restrict block size. Letting miners choose the maximum block size is more problematic for several reasons:

# '''Miners profit, others pay the cost:''' bigger blocks earn miners more fees, but miners don’t need to store those blocks for more than a few days.<ref>[https://github.com/bitcoin/bitcoin/pull/5863 Bitcoin Core pull #5863 adding pruning functionality], Suhas Daftuar et al., 6 March 2015</ref> Other users who want full validation security, or who provide services to lightweight wallets, pay the costs of downloading and storing those larger blocks.
# '''Bigger miners can afford more bandwidth:''' each miner needs to download every transaction that will be included in block,<ref name="maxwell_correcting_assumptions" /> which means that they all need to pay for high-speed connections. However, a miner with 8.3% of total hash rate can take that cost out of the about 300 BTC they make a day, while a miner with only 0.7% of total hash rate has to take that cost out of only 25 BTC a day. This means bigger miners may logically choose to make bigger blocks even though it may further centralize mining.
# '''Centralized hardware production:''' only a few companies in the world produce efficient mining equipment, and many of them have chosen to stop selling to the public.<ref>[http://blogs.wsj.com/venturecapital/2014/09/05/for-kncminer-time-to-forget-selling-bitcoin-machines-to-at-home-miners/ KnCMiner to stop selling to home miners], Wall Street Journal, Yuliya Chernova, 5 September 2014</ref> This prevents ordinary Bitcoin users from participating in the process even if they were willing to pay for mining equipment.
# '''Voting by hash rate favors larger miners:''' voting based on hash rate allows the current hash rate majority (or super-majority) to enforce conditions on the minority. This is similar to a lobby of large businesses being able to get laws passed that may hurt smaller businesses.<ref>[https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/cs5gvak Miners choosing the block size limit is ill-advised], Meni Rosenfeld, 13 June 2015</ref>
# '''Miners may not care about users:''' this was demonstrated during the [[July 2015 Forks]] where even after miners lost over $50,000 USD in income from mining invalid chains, and even after they were told that long forks harm users, they continued to mine inproperly.<ref>[https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Intention to continue SPV mining], Wang Chun, 4 July 2015</ref>

However, there are also possible justifications for letting miners choose the block size:

# '''Authenticated participants:''' miners are active participants in Bitcoin, and they can prove it by adding data to the blocks they create.<ref>[https://bitcoin.org/en/developer-reference#term-coinbase-field Coinbase field], Bitcoin.org Developer Reference</ref> It is much harder to prove people on Reddit, BitcoinTalk, and elsewhere are real people with an active stake in Bitcoin.
# '''Bigger blocks may cost miners:''' small miners and poorly-connected miners are at a disadvantage if larger blocks are produced<ref name="wuille_centralization" />, and even large and well-connected miners may find that large blocks reduce their profit percentage if the cost of bandwidth rises too high or their stale rate increases.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008355.html F2Pool block size concerns], Chun Wang, 29 May 2015</ref>

==== How could a block size increase affect user security? ====

Bitcoin’s security is highly dependent on the number of active users who protect their bitcoins with a full node like Bitcoin Core. The more active users of full nodes, the harder it is for miners to trick users into accepting fake bitcoins or other frauds.<ref>[https://medium.com/@lopp/bitcoin-nodes-how-many-is-enough-9b8e8f6fd2cf Bitcoin nodes: how many is enough?], Jameson Lopp, 7 June 2015</ref>

Full nodes need to download and verify every block, and most nodes also store blocks plus relay transactions, full blocks, and filtered blocks to other users on the network. The bigger blocks become, the more difficult it becomes to do all this, so it is expected that bigger blocks will both reduce the number of users who currently run full nodes and suppress the number of users who decide to start running a full node later.<ref>[https://www.reddit.com/r/Bitcoin/comments/3bae2d/amir_taaki_on_raising_the_block_size_a_lot_of/cslcgmw Block size increases-only will create problems], Dr. Adam Back, 28 June 2015</ref>

In addition, full blocks may increase mining centralization<ref name="wuille_centralization" /> at a time when mining is already so centralized that it makes it easy to reverse transactions which have been confirmed multiple times.<ref>[http://bitcoin.stackexchange.com/questions/32562/when-to-worry-about-1-confirmation-payments/32564#32564 When to worry about one-confirmation payments], David A. Harding, 17 November 2014</ref>

==== How could larger blocks affect proof-of-work (POW) security? ====

Proof of work security is dependent on how much money miners spend on mining equipment. However, to effectively mine blocks, miners also need to spend money on bandwidth to receive new transactions and blocks created by other miners; CPUs to validate received transactions and blocks; and bandwidth to upload new blocks. These additional costs don’t directly contribute to POW security.<ref name="maxwell_correcting_assumptions">[https://www.reddit.com/r/Bitcoin/comments/39tgno/letting_miners_vote_on_the_maximum_block_size_is/cs6rek5 Correcting wrong assumptions about mining], Gregory Maxwell, 15 June 2015</ref>

As block sizes increase, the amount of bandwidth and CPU required also increases. If block sizes increase faster than the costs of bandwidth and CPU decrease, miners will have less money for POW security relative to the gross income they earn.

In addition, larger blocks have a higher risk of becoming stale (orphaned)<ref name="rusty_dsl" />, which directly correlates to lost POW security. For example, if the network average stale rate is 10%, then 10% of POW performed isn't protecting transactions on the block chain.

=== What happens if blocks aren't big enough to include all pending transactions? ===

This is already the case more often than not<ref>[http://statoshi.info/dashboard/db/transactions?from=1433297061121&to=1435889061123 Statoshi.info mempool queue June to July 2015]</ref>, so we know that miners will simply queue transactions. The transactions eligible for block inclusion that pay the highest fee per kilobyte will be confirmed earlier than transactions that pay comparatively lower fees.<ref name="fee_pri" />

What happens from there is debated:

* BitcoinJ lead developer Mike Hearn believes there would be “crashing nodes, a swelling transaction backlog, a sudden spike in double spending, [and] skyrocketing fees.”<ref>[https://medium.com/@octskyward/crash-landing-f5cc19908e32 Crash Landing], Mike Hearn, 7 May 2015</ref>
* Bitcoin Foundation chief scientist Gavin Andresen believes that the “average transaction fee paid will rise, people or applications unwilling or unable to pay the rising fees will stop submitting transactions, [and] people and businesses will shelve plans to use Bitcoin, stunting growth and adoption.” <ref>[https://github.com/bitcoin/bitcoin/pull/6341 Bitcoin Core pull #6341], Gavin Andresen, 26 June 2015</ref>
* Bitcoin Core developer Pieter Wuille replies to Andresen’s comment above: “Is it fair to summarize this as ‘Some use cases won’t fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt.’? I think that is already happening […] I don’t think we should be afraid of this change or try to stop it.” <ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009098.html The need for larger blocks], Pieter Wuille, 26 June 2015</ref>
* Bitcoin Core developer Jeff Garzik writes, "as blocks get full and the bidding war ensues, the bitcoin user experience rapidly degrades to poor. In part due to bitcoin wallet software’s relative immaturity, and in part due to bitcoin’s settlement based design, the end user experience of their transaction competing for block size results in erratic, and unpredictably extended validation times."<ref name="garzik_bip" />

== Specific Scaling Proposals ==

=== Andresen-Hearn Block Size Increase Proposals ===

Questions about the series of related proposals by Gavin Andresen and Mike Hearn to use a hard fork to raise the maximum block size, thereby allowing miners to include more on-chain transactions. As of July 2015, the current focus is [https://github.com/bitcoin/bips/pull/163 BIP101].

==== What is the major advantage of this proposal? ====

''Bitcoin can support many more users.'' Assuming earliest possible adoption, 250 bytes per on-chain transaction, 144 blocks per day, and 2 transaction a day per user, Bitcoin can support about,

* 288,000 users in 2015
* 2,304,000 users in 2016 (800% increase)
* 4,608,000 in 2018 (1,600%)
* 9,216,000 in 2020 (3,200%)
* 18,432,000 in 2022 (6,400%)
* 36,864,000 in 2024 (12,800%)
* 73,728,000 in 2026 (25,600%)
* 147,456,000 in 2028 (51,200%)
* 294,912,000 in 2030 (102,400%)
* 589,824,000 in 2032 (204,800%)
* 1,179,648,000 in 2034 (409,600%
* 2,359,296,000 in 2036 (819,200%)

==== What is the major disadvantage of this proposal? ====

''The total cost of remaining decentralized will be high.'' Assuming earliest possible adoption and that the ratio of total users to full node operators remains the same as today, the total estimated amount of work necessary to maintain the decentralized system under the [[#O.28n2.29_network_total_validation_resource_requirements|O(2) scaling model]] will be,

* 100% of today’s work in 2015
* 6,400% in 2016
* 25,600% in 2018
* 102,400% in 2020
* 409,600% in 2022
* 1,638,400% in 2024
* 6,553,600% in 2026
* 26,214,400% in 2028
* 104,857,600% in 2030
* 419,430,400% in 2032
* 1,677,721,600% in 2034
* 6,710,886,400% in 2036

For example, if the total amount spent on running full nodes today (not counting mining) is $100 thousand per year, the estimated cost for the same level of decentralization in 2036 will be $6.7 trillion per year if validation costs stay the same. (They'll certainly go down, but algorithmic and hardware improvements probably won't eliminate an approximate 6,710,886,400% cost increase.)

==== What are the dangers of the proposed hard fork? ====

Under the current proposal, 75% of miners must indicate that they agree to accept blocks up to 8 MB in size.<ref name="bip101">[https://github.com/bitcoin/bips/pull/163 BIP101], Gavin Andresen, 24 June 2016</ref> After the change goes into effect, if any miner creates a block larger than 1 MB, all nodes which have not upgraded yet will reject the block.<ref>[https://bitcoin.org/en/developer-guide#consensus-rule-changes Consensus rule changes], Bitcoin.org Developer Guide</ref>

If all full nodes have upgraded, or very close to all nodes, there should be no practical effect. If a significant number of full nodes have not upgraded, they will continue using a different block chain than the upgraded users, with the following consequences:

* Bitcoins received from before the fork can be spent twice, once on both sides of the fork. This creates a high double spend risk.
* Bitcoins received after the fork are only guaranteed to be spendable on the side of the fork they were received on. This means some users will have to lose money to restore Bitcoin to a single chain.

Users of hosted wallets (Coinbase, BlockChain.info, etc.) will use whatever block chain their host chooses. Users of lightweight P2P SPV wallets will use the [[Thin Client Security|longest chain they know of]], which may not be the actual longest chain if they only connect to nodes on the shorter chain. Users of non-P2P SPV wallets, like Electrum, will use whatever chain is used by the server they connect to.

If a bad hard fork like this happens, it will likely cause large-scale confusion and make Bitcoin very hard to use until the situation is resolved.

==== What is the deployment schedule for BIP 101? ====

* The patch needs to be accepted into Bitcoin Core, Bitcoin XT, or both.
* If accepted into Bitcoin Core, miners using that software will need to upgrade (this probably requires a new released version of Bitcoin Core). If accepted only into Bitcoin XT, miners will need to switch to using XT.
* After 75% of miners have upgraded, 8MB blocks will become allowed at the the latest of (1) 11 January 2016 or (2) two weeks after the 75% upgrade threshold.<ref name="bip101" />
* After the effective date has passed, any miner may create a block larger than 8MB. When a miner does this, upgraded full nodes will accept that block and non-upgraded full nodes will reject it, forking the network.<ref name="bip101" /> See [[#What_are_the_dangers_of_the_proposed_hard_fork.3F|hard fork dangers]] for what his might mean.

==== Will miners go straight from 1 MB blocks to 8 MB blocks? ====

That would be highly unlikely. Uploading an 8 MB block currently takes significantly more time than uploading a 1 MB block<ref name="rusty_dsl">[http://rusty.ozlabs.org/?p=509 Mining on a home DSL connection test results], Rusty Russell, 19 June 2015</ref>, even with the roughly 25x reduction in size available from use of Matt Corallo’s block relay network.<ref name="block_relay_net" />

The longer it takes to upload a block, the higher the risk it will become a stale block—meaning the miner who created it will not receive the block subsidy or transaction fees (currently about 25 BTC per block).

However, if technology like Invertible Bloom Lookup Tables (IBLTs) is deployed and found to work as expected<ref name="iblt">[https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 O(1) block propagation], Gavin Andresen, 8 August 2014</ref>, or if mining [[#What_is_the_most_efficient_way_to_scale_Bitcoin.3F|centralizes further]], adding additional transactions may not have a significant enough cost to discourage miners from creating full blocks. In that case, blocks will be filled as soon as there are enough people wanting to make transactions paying the default relay fee<ref>[https://github.com/bitcoin/bitcoin/pull/3305 Bitcoin Core pull #3305 dropping default fees], Mike Hearn, 22 November 2013</ref> of 0.00001000 BTC/kilobyte.

==== What tests have been performed related to this proposal? ====

* '''20MB block processing''' (Gavin Andresen) “if we increased the maximum block size to 20 megabytes tomorrow, and every single miner decided to start creating 20MB blocks and there was a sudden increase in the number of transactions on the network to fill up those blocks… the 0.10.0 version of [Bitcoin Core] would run just fine.”<ref>[http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html Twenty megabyte block testing], Gavin Andresen, 20 January 2015</ref> (ellipses in original)
* '''Mining & relay simulation''' (Gavin Andresen) “if blocks take 20 seconds to propagate, a network with a miner that has 30% of the hashing power will get 30.3% of the blocks.”<ref>[http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners Are bigger blocks better for bigger miners?], Gavin Andresen, 22 May 2015</ref>
* '''Mining on a home DSL connection''' (Rusty Russell) “Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.”<ref name="rusty_dsl" />
* '''Mining centralization pressure''' (Pieter Wuille) “[This] does very clearly show the effects of larger blocks on centralization pressure of the system.”<ref name="wuille_centralization">[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008581.html Mining centralization pressure from non-uniform propagation speed], Pieter Wuille, 12 June 2015</ref>

=== Garzik Miner Block Size Voting Proposal (AKA BIP100) ===

''Note, BIP 100 is the marketing name for this proposal. No BIP number
has yet been publicly requested, and the number assigned is unlikely to
be 100.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005756.html
Prenumbered BIP naming], Gregory Maxwell, 12 May 2014</ref>''

Questions related to Jeff Garzik's proposal<ref name="garzik_bip">[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Draft BIP: decentralized economic policy], Jeff Garzik, 12 June 2015 (revised 15 June 2015)</ref> to allow miners to vote on raising and lowering the maximum block size.

==== What does this proposal do? ====

# It creates a one-time hard fork that does not automatically change the maximum block size.

# It allows miners to vote to increase or decrease the maximum block size within the range of 1MB to 32MB. These changes are neither hard forks nor soft forks, but simply rules that all nodes should know about after the initial hard fork.

==== Does it reduce the risk of a hard fork? ====

Hard forks are most dangerous when they're done without strong
consensus.<ref name="garzik_bip" /><ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008779.html Consensus changes are not about making a change to the software],
Pieter Wuille, 18 June 2015</ref>

If Garzik's proposal gains strong consensus, it will as safe as possible
for a hard fork and it will allow increasing the block size up to 32 MB
without any additional risk of a fork.

==== Why is it limited to 32 megabytes? ====

According to the draft BIP, "the 32 MB hard fork is largely coincidental -- a whole network upgrade at 32 MB was likely needed anyway."

=== Lightning Network ===

Questions related to using the proposed [http://lightning.network/ Lightning network] as a way to scale the number of users Bitcoin can support.

==== How does transaction security differ from that of Bitcoin? ====

Transactions on the proposed Lightning network use Bitcoin transactions exclusively to transfer bitcoins<ref name="russell_lightning1">[http://rusty.ozlabs.org/?p=450 Lightning Networks: Part I], Rusty Russell, 30 March 2015</ref>, and so the same security as regular Bitcoin transactions is provided when both a Lightning hub and client are cooperating.

When a Lightning hub or client refuses to cooperate with the other (maybe because they accidentally went offline), the other party can still receive their full 100% bitcoin balance by closing the payment channel—but they must first wait for a defined amount of time mutually chosen by both the hub and client.<ref>[http://rusty.ozlabs.org/?p=462 Lightning Networks: Part II], Rusty Russell, 1 April 2015</ref>

If one party waits too long to close the payment channel, the other party may be able to steal bitcoins. However, it is possible to delegate the task of closing the channel in an emergency to an unlimited number of hubs around the Internet, so closing the channel on time should be easy.<ref name="russell_lightning4">[http://rusty.ozlabs.org/?p=477 Lightning Networks: Part IV], Rusty Russell, 8 April 2015</ref>

In summary, provided that payment channels are closed on time, the worst that can happen to users is that they may have to wait a few weeks for a channel to fully close before spending the bitcoins they received from it. Their security is otherwise the same as with regular Bitcoin.

For Lightning hubs, security is slightly worse in the sense that they need to keep a potentially-large amount of funds in a hot wallet<ref name="lightning_paper">[http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf Lightning Network (Draft 0.5)], Section 6.3: Coin Theft via Hacking, Joseph Poon and Thaddeus Dryja</ref>, so they can’t take advantage of the anti-hacking protection offered by cold wallets. Otherwise, Lightning hubs have the same security as clients.

==== When will Lightning be ready for use? ====

Lightning requires a basic test implementation (work underway<ref>[https://lists.blockstream.com/pipermail/lightning-dev/2015-June/000018.html Lightning first steps], Rusty Russell, 13 June 2015</ref>), several soft-fork changes to the Bitcoin protocol (work underway<ref>[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65: CheckLockTimeVerify], Peter Todd, 1 October 2014</ref><ref>[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement], Mark Friedenbach, 28 May 2015</ref>, and wallets need to be updated to support the Lightning network protocol.<ref name="russell_lightning4" />

Dr. Adam Back has said, "I expect we can get something running inside a year."<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009242.html Reply to Andresen regarding Lightning], Dr. Adam Back, 28 June 2015</ref>

==== Doesn’t Lightning require bigger blocks anyway? ====

Lightning is block-size neutral. It requires one on-chain transaction to open a channel between a hub and a client, and one on-chain transaction to close a channel.<ref name="russell_lightning1" /> In between it can support an unlimited number of transactions between anyone on the Lightning network.<ref name="lightning_paper" />

Using the numbers from the Lightning presentation<ref name="lightning_slides">[http://lightning.network/lightning-network.pdf Lightning presentation], Joseph Poon, 23 February 2015</ref>, if people open and close a plausible two channels a year, Lightning can support about 52 million users with the current one-megabyte limit—and each user can make an unlimited number of transactions. Currently, assuming people make an average of only two Bitcoin transactions a day, basic Bitcoin can support only 288,000 users.

Under these assumptions, Lightning is 180 times (17,900%) more efficient than basic Bitcoin.

Presumably, if around 30 million people are using Bitcoin via Lightning so that capacity is called into question, it will not be difficult to find consensus to double the block size to two megabytes and bring user capacity up to 105 million. The same goes for later increases to 200 million (4MB), 400 million (8MB), 800 million (16MB), 1.6 billion (32 MB), 3.2 billion (64MB), and all 7 billion living humans (133MB). In each case, all Lightning network participants get unlimited transactions to the other participants.

For basic Bitcoin to scale to just 2 transactions a day for 7 billion people would require 24-gigabyte blocks.<ref name="lightning_slides" />

=== Sidechains ===

==== Real quick, what are sidechains? ====

Block chains that are separate from Bitcoin’s block chain, but which allow you to receive and spend bitcoins using a two-way peg (2WP).<ref name="sidechains_paper">[https://www.blockstream.com/sidechains.pdf Sidechains paper], Adam Back et al., 22 October 2014</ref> (Although a sidechain can never be more secure than the Bitcoin block chain.<ref>[https://www.reddit.com/r/Bitcoin/comments/39r85g/sidechain_hate/cs5spbg Security limitations of pegged chains], Gregory Maxwell, 14 June 2015</ref>)

==== Are sidechains a scaling option? ====

No. Sidechains have the same fundamental scaling problems as Bitcoin does. Moving some transactions to sidechains simply moves some problems elsewhere on the network—the total difficulty of the problem remains the same.<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008617.html Sidechains not a direct means for solving any of the scaling problems Bitcoin has], Pieter Wuille, 13 June 2015</ref>

==== But couldn’t I create a sidechain that had 100 GB blocks? ====

Certainly, sidechain code is open source<ref>[https://github.com/ElementsProject/elements Elements Project]</ref>—so you can create your own sidechain. But you’d still have the difficulty of finding people who are willing to validate 100 GB blocks with their own full nodes.

==== Do sidechains require a hard fork? ====

No. Federated sidechains, such as have already been implemented<ref>[https://github.com/ElementsProject/elements/tree/alpha Elements Alpha]</ref>, don’t require any changes to the Bitcoin consensus rules. Merged-mined sidechains, which have not been implemented yet, do require a backwards-compatible soft fork in order to transfer funds between Bitcoin and the sidechain.<ref name="sidechains_paper" />

== References ==
<references />

Talk:Tonal Bitcoin

2015-03-01T08:08:33Z

Dooglus: Good luck getting rid of the silly Tonal stuff. I've tried and it just gets added straight back in.

This is for discussion, '''not trolling'''. Note that this is not an encyclopedia, and does not have any "notability" requirements. If you don't want to use Tonal, don't. Trolling is not acceptable and will be deleted. Reasoned criticism is welcome in the "Criticism" section of the page.

I have no legitimate stake in the matter, I made a few edits that I hope remove POV and still embrace the idea of Tonal Bitcoin. This is Raize, I am sorry I am not familiar enough with wiki editing to provide my signature. --[[User:Raize|Raize]]

==Proposal for deletion==

I propose to delete this article on the following grounds.

# "Tonal bitcoin" ''is'' Bitcoin. Tonal Bitcoin only refers to the choice of the bitcoin user to employ a different representation of standard bitcoin balances. Instead of using decimal, the originator proposes using tonal units. If we follow this approach to the extreme, we could also use any base X system. It comes down to this: If you have a bitcoin balance of X in decimal notation, you can convert this to a balance Y in tonal units.
# There is almost no information about tonal bitcoin available on the web attesting to its insignificance. All information that is available seems to come from a single source. To make matters worse, the information that is available is extremely confusing and poorly written.
# No one, with the possible exception of one person, use "tonal bitcoin" units.
# Not one exchange or business uses Tonal bitcoin units (to my knowledge).

[[User:Lunokhod|Lunokhod]] ([[User talk:Lunokhod|talk]]) 14:59, 21 August 2014 (UTC)

: '''1)''' Exactly why it is on-topic to the wiki, and should ''not'' be deleted; '''2)''' This wiki is just as relevant to the web as any random altcoin website, and this wiki explicitly permits and encourages original content and original research, unlike Wikipedia which is merely an encyclopedia; '''3)''' I know multiple people who use TBC (though I won't do so publicly so they can be trolled) - and in any case, significance and/or notability is not a concern of this wiki (see [[:Bitcoin:About|the wiki about/policy page]]); '''4)''' Again, irrelevant. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 16:10, 24 August 2014 (UTC)

:: I agree that this should not be deleted. This is not Wikipedia, we don't have a notability policy, and explicitly allow technical or niche material relating to bitcoin. [[User:Nanotube|Nanotube]] ([[User talk:Nanotube|talk]]) 16:31, 24 August 2014 (UTC)

I think this article should be deleted as this wiki is for Bitcoin, not altcoins. The creator of Tonal Bitcoins calls it "First (and best) altcoin ever: Tonal Bitcoin (TBC)" - https://bitcointalk.org/index.php?topic=218388.0 , and seeing as this wiki has no article on [[Litecoin]] or [[Dogecoin]], this website should go as well. Nobody cares about this, and it's just useless clutter on pages like this or [[Units]].

[[User:ThePiachu|ThePiachu]] ([[User talk:ThePiachu|talk]]) 01:49, 1 March 2015 (UTC)

:This just seems petty and vindictive to me, and also needlessly drama inducing. This wiki exists to cover Bitcoin things, it's fine if it covers niche and obscure aspects of the Bitcoin ecosystem. That this wiki isn't free hosting and advertisement for your choice of competing currencies is no reason to justify deleting things on the wiki. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 06:26, 1 March 2015 (UTC)

::A fair point. That being said, due to the nonexistent userbase of the Tonal Bitcoins, I would keep them away from non-relevant pages of the wiki, such as the mentioned [[Units]]. [[User:ThePiachu|ThePiachu]] ([[User talk:ThePiachu|talk]]) 07:31, 1 March 2015 (UTC)

:::I use base 27 for all my bitcoin balances and have made up names for all the numbers and powers of 27. They're named after my cats. Can I add them to the [[Units]] page? [[User:Dooglus|Dooglus]] ([[User talk:Dooglus|talk]]) 08:08, 1 March 2015 (UTC)

Talk:Tonal Bitcoin

2015-03-01T08:01:33Z

Dooglus: Good luck getting rid of the silly Tonal stuff. I've tried and it just gets added straight back in.

Talk:Inputs.io

2013-11-10T07:36:55Z

Dooglus: Created page with "> inputs service was hacked or owner scammed On November 7th, 2013 Apparently the hack happened a couple of weeks before the site was shut down. > Currently, Inputs.io is su..."

> inputs service was hacked or owner scammed On November 7th, 2013

Apparently the hack happened a couple of weeks before the site was shut down.

> Currently, Inputs.io is supported by the following sites:
>
> * Just-dice.com

Just-Dice stopped accepting inputs.io deposits before the site was shut down, when 42 BTC was stolen from the Just-Dice inputs account and TradeFortress requested the return of the deposit Just-Dice was holding as collateral.

User talk:Dooglus

2013-02-21T04:22:28Z

Dooglus:

Location: Kamloops, BC, Canada

E-Mail: dooglus@gmail.com

Instant Messaging: dooglus@gmail.com on both Jabber and MSN

Contributors Award participant: 16Pb8nKA64tHiYrox8rS4Mi8vEpJk4dp3X

Units

2013-02-21T04:17:10Z

Dooglus: Remove hyphens and mixed case. We don't wrote Kilo-Gram, we write kilogram. Left tonal stuff alone because I don't know anything about it.

{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"
|- style="background-color:silver"
! Abbreviation
! Pronunciation
! style="background-color: #7fdfdf" | Decimal (BTC)
! style="background-color: #7fdf7f" | [[Tonal Bitcoin|Tonal (TBC)]]
! Tonal, as Hexadecimal
|-
|colspan="2"| Maximum Bitcoins ever<ref>[http://www.wolframalpha.com/input/?i=%28sum%28210000*floor%285000000000%2F2^i%29%29%2C+i%3D0+to+32%29%2F10000000 Wolfram|Alpha]</ref>
| 20,999,999.9769    
| 7,750,54.00 
| 7,75f0,59e4.009 
|- style="background-color:lime"
|
| Tam-Bitcoin
| 2,814,749.76710656
| 1,0000,0000     
| 1,0000,0000     
|- style="background-color:cyan"
| MBTC
| megabitcoin
| 1,000,000         
| 593,1079.4   
| 5af3,107a.4   
|- style="background-color:cyan"
| kBTC
| kilobitcoin
| 1,000         
| 17,4876.8  
| 17,4876.e8  
|- style="background-color:cyan"
| hBTC
| hectobitcoin
| 100         
| 2,540.4  
| 2,540b.e4  
|-
|colspan="2"| Initial block reward
| 50         
| 1,2905.2  
| 1,2a05.f2  
|- style="background-color:lime"
| ᵇTBC
| Bong-Bitcoin
| 42.94967296
| 1,0000     
| 1,0000     
|- style="background-color:cyan"
| daBTC
| decabitcoin
| 10         
| 39.9  
| 3b9a.ca  
|- style="background-color:lime"
| ᵐTBC
| Mill-Bitcoin
| 2.68435456
| 1000     
| 1000     
|- style="background-color:cyan"
| BTC
| *bitcoin
| 1         
| 55.1  
| 5f5.e1  
|- style="background-color:lime"
| ˢTBC
| San-Bitcoin
| 0.16777216
| 100     
| 100     
|- style="background-color:cyan"
| dBTC
| decibitcoin
| 0.1       
| 8.68 
| 98.968 
|- style="background-color:lime"
| ᵗTBC
| Ton-Bitcoin
| 0.01048576
| 10     
| 10     
|- style="background-color:cyan"
| cBTC
| centibitcoin
| 0.01      
| .424 
| f.424 
|- style="background-color:cyan"
| mBTC
| millibitcoin
| 0.001     
| 1.869 
| 1.86a 
|- style="background-color:lime"
| TBC
| *Bitcoin
| 0.00065536
| 1     
| 1     
|- style="background-color:lime"
| TBCᵗ
| Bitcoin-ton
| 0.00004096
| 0.1   
| 0.1   
|- style="background-color:lime"
| TBCˢ
| Bitcoin-san
| 0.00000256
| 0.01  
| 0.01  
|- style="background-color:cyan"
| μBTC
| microbitcoin
| 0.000001  
| 0.0064
| 0.0064
|- style="background-color:lime"
| TBCᵐ
| Bitcoin-mill
| 0.00000016
| 0.001 
| 0.001 
|- style="background-color:lime"
| TBCᵇ
| Bitcoin-bong
| 0.00000001
| 0.0001
| 0.0001
|-
|
| "Satoshi"
| 0.00000001
| 0.0001
| 0.0001
|}
* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.

==See Also==

* [[MilliBit]]

==References==
<references />

Units

2013-02-20T21:42:55Z

Dooglus: the 'c' in bitcoin is meant to be lowercase

{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"
|- style="background-color:silver"
! Abbreviation
! Pronunciation
! style="background-color: #7fdfdf" | Decimal (BTC)
! style="background-color: #7fdf7f" | [[Tonal Bitcoin|Tonal (TBC)]]
! Tonal, as Hexadecimal
|-
|colspan="2"| Maximum Bitcoins ever<ref>[http://www.wolframalpha.com/input/?i=%28sum%28210000*floor%285000000000%2F2^i%29%29%2C+i%3D0+to+32%29%2F10000000 Wolfram|Alpha]</ref>
| 20,999,999.9769    
| 7,750,54.00 
| 7,75f0,59e4.009 
|- style="background-color:lime"
|
| Tam-Bitcoin
| 2,814,749.76710656
| 1,0000,0000     
| 1,0000,0000     
|- style="background-color:cyan"
| MBTC
| Mega-Bitcoin
| 1,000,000         
| 593,1079.4   
| 5af3,107a.4   
|- style="background-color:cyan"
| kBTC
| Kilo-Bitcoin
| 1,000         
| 17,4876.8  
| 17,4876.e8  
|- style="background-color:cyan"
| hBTC
| Hecto-Bitcoin
| 100         
| 2,540.4  
| 2,540b.e4  
|-
|colspan="2"| Initial block reward
| 50         
| 1,2905.2  
| 1,2a05.f2  
|- style="background-color:lime"
| ᵇTBC
| Bong-Bitcoin
| 42.94967296
| 1,0000     
| 1,0000     
|- style="background-color:cyan"
| daBTC
| Deca-Bitcoin
| 10         
| 39.9  
| 3b9a.ca  
|- style="background-color:lime"
| ᵐTBC
| Mill-Bitcoin
| 2.68435456
| 1000     
| 1000     
|- style="background-color:cyan"
| BTC
| *Bitcoin
| 1         
| 55.1  
| 5f5.e1  
|- style="background-color:lime"
| ˢTBC
| San-Bitcoin
| 0.16777216
| 100     
| 100     
|- style="background-color:cyan"
| dBTC
| Deci-Bitcoin
| 0.1       
| 8.68 
| 98.968 
|- style="background-color:lime"
| ᵗTBC
| Ton-Bitcoin
| 0.01048576
| 10     
| 10     
|- style="background-color:cyan"
| cBTC
| Centi-Bitcoin
| 0.01      
| .424 
| f.424 
|- style="background-color:cyan"
| mBTC
| Milli-Bitcoin
| 0.001     
| 1.869 
| 1.86a 
|- style="background-color:lime"
| TBC
| *Bitcoin
| 0.00065536
| 1     
| 1     
|- style="background-color:lime"
| TBCᵗ
| Bitcoin-ton
| 0.00004096
| 0.1   
| 0.1   
|- style="background-color:lime"
| TBCˢ
| Bitcoin-san
| 0.00000256
| 0.01  
| 0.01  
|- style="background-color:cyan"
| μBTC
| Micro-Bitcoin
| 0.000001  
| 0.0064
| 0.0064
|- style="background-color:lime"
| TBCᵐ
| Bitcoin-mill
| 0.00000016
| 0.001 
| 0.001 
|- style="background-color:lime"
| TBCᵇ
| Bitcoin-bong
| 0.00000001
| 0.0001
| 0.0001
|-
|
| "Satoshi"
| 0.00000001
| 0.0001
| 0.0001
|}
* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.

==See Also==

* [[MilliBit]]

==References==
<references />

Private key

2013-01-24T22:02:04Z

Dooglus: /* See Also */ link to 'How to import private keys v7+'

A '''private key''' in the context of Bitcoin is a secret number that allows bitcoins to be spent. Every Bitcoin address has a matching private key, which is saved in the wallet file of the person who owns the balance. The private key is mathematically related to the Bitcoin address, and is designed so that the Bitcoin address can be calculated from the private key, but importantly, the same cannot be done in reverse.

Because the private key is the "ticket" that allows someone to spend bitcoins, it is important that these are kept secure. Private keys can be kept on computer files, but they are also short enough that they can be printed on paper. An example of a utility that allows extraction of private keys from your wallet file for printing purposes is [[pywallet]].

In order to create a transaction with a private key, it must be available to a program or service that allows entry or importing of private keys. Some wallets allow the private key to be imported without generating any transactions while other wallets or services require that the private key be swept. When a private key is swept, a transaction is broadcast that sends the entire balance held by the private key to another address in the wallet or securely controlled by the service in question.

An example of private key sweeping is the method used on [[MtGox]]'s Add Funds screen. Just as with any other deposit, there is risk of double-spending so funds are deposited to the MtGox account after a six-confirmation wait (typically one hour). In contrast [[BlockChain.info]]'s My Wallet service and Bitcoin-QT each provide a facility to import a private key without creating a sweep transaction.

==An example private key==
In Bitcoin, a private key is a 256-bit number, which can be represented one of several ways. Here is a private key in hexadecimal - 256 bits in hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F.

E9 87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D A6 1F 20 BD 67 FC 23 3A A3 32 62

==Range of valid private keys==
Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.

The range of valid private keys is governed by the [[secp256k1]] ECDSA standard used by Bitcoin.

==Base 58 Wallet Import format==
When we represent private keys in Bitcoin, however, we use a shorter format known as [[wallet import format]], which offers a few advantages. The wallet import format is shorter, and includes built-in error checking codes so that typos can be automatically detected and/or corrected (which is impossible in hex format). Wallet import format is the most common way to represent private keys in Bitcoin. For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5. Private keys associated with compressed public keys are 52 characters and start with a capital L or K. This is the same private key in wallet import format.

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

When a private key is imported, it always corresponds to exactly one [[Address|Bitcoin address]]. Any utility which performs the conversion can display the matching Bitcoin address. The mathematical conversion is somewhat complex and best left to a computer, but it's notable that each private key will always correspond to the same address no matter which program is used to convert it.

The Bitcoin address corresponding to the sample above is: 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

==Mini private key format==
Some applications use the [[mini private key format]]. Not every private key or Bitcoin address has a corresponding mini private key - they have to be generated a certain way in order to ensure a mini private key exists for an address. The mini private key is used for applications where space is critical, such as in QR codes and in [[physical bitcoins]]. The above example has a mini key, which is:

SzavMBLoXU6kDrqtUVmffv

==Summary==
Any Bitcoins sent to the address 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be spent by anybody who knows the private key in ''any'' of the three formats. That includes bitcoins presently at the address, as well as any bitcoins that are ever sent to it in the future. The private key is only needed to spend the balance, not necessarily to see it. The Bitcoin balance of the address can be determined by anybody with the public [[Block Explorer]] at http://www.blockexplorer.com/address/1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj - even if they don't have the private key.

If a private key with a Bitcoin balance is compromised or stolen, the bitcoin balance can only be protected if it is immediately spent to a different address whose private key is not compromised. Because bitcoins can only be spent once, when they are spent away from a private key, the private key is worthless unless more coins are sent to the address.

==See Also==

* [[Paper wallet]]
* [[How to import private keys]]
* [[How to import private keys v7+]]

[[es:Clave privada]]

Help:How to import private keys in Bitcoin Core 0.7+

2013-01-24T21:56:38Z

Dooglus: /* Backup Wallet */ there's no need to close the client. backups of encrypted wallets are encrypted whether the wallet is unlocked or not

==Backup Your Wallet==
Although this process is well tested and used you should always take another backup
of your wallet.dat file before starting.

==Open Debug Window==
Then go to menu:
/Help/Debug Window

[[File:Screen1.PNG|px200]]

and click on the tab - Console.

==Unlock your wallet==

If your wallet is encrypted (I hope it is!) you must unlock it. If not just skip this step.

To do this just type into the box at the bottom:
<pre>
walletpassphrase "YourLongPassphrase" 600
</pre>
You need the quotes if there is a space in your phrase else there is no need for them.
The 600 means your wallet is unlocked for 10 minutes (600 seconds).

[[File:Unlock.PNG|px200]]

==Run Import Command in Debug Window==
In the console at the very bottom is a text entry box. In here enter:
<pre>
importprivkey yourPrivateKeyInWalletImportFormat "TheLabelThatIWant"
</pre>
The quotes are only needed if you want a space in the label.
[[File:Import1.PNG]]

You now have to be patient. On a fast PC it takes 2 minutes to import, and
during this time it looks like you application has hung. After waiting a few minutes
you will see:

[[File:Import2.PNG]]

You are now done. But always best to check it worked.

==Check Key Imported OK==

Once Imported you can check that you have the address by closing the Debug window and going back to your address book.

You should see the address here:

[[File:InAddressBook.PNG]]

And you can even send a transaction to check e.g.

[[File:ReceivedTrans.PNG]]

==Backup Wallet==
Your backup of your wallet will not have this key in obviously. So before you do anything else backup the wallet.dat file as normal.

Help:How to import private keys in Bitcoin Core 0.7+

2013-01-24T21:55:10Z

Dooglus: /* Run Import Command in Debug Window */ typo

==Backup Your Wallet==
Although this process is well tested and used you should always take another backup
of your wallet.dat file before starting.

==Open Debug Window==
Then go to menu:
/Help/Debug Window

[[File:Screen1.PNG|px200]]

and click on the tab - Console.

==Unlock your wallet==

If your wallet is encrypted (I hope it is!) you must unlock it. If not just skip this step.

To do this just type into the box at the bottom:
<pre>
walletpassphrase "YourLongPassphrase" 600
</pre>
You need the quotes if there is a space in your phrase else there is no need for them.
The 600 means your wallet is unlocked for 10 minutes (600 seconds).

[[File:Unlock.PNG|px200]]

==Run Import Command in Debug Window==
In the console at the very bottom is a text entry box. In here enter:
<pre>
importprivkey yourPrivateKeyInWalletImportFormat "TheLabelThatIWant"
</pre>
The quotes are only needed if you want a space in the label.
[[File:Import1.PNG]]

You now have to be patient. On a fast PC it takes 2 minutes to import, and
during this time it looks like you application has hung. After waiting a few minutes
you will see:

[[File:Import2.PNG]]

You are now done. But always best to check it worked.

==Check Key Imported OK==

Once Imported you can check that you have the address by closing the Debug window and going back to your address book.

You should see the address here:

[[File:InAddressBook.PNG]]

And you can even send a transaction to check e.g.

[[File:ReceivedTrans.PNG]]

==Backup Wallet==
Your backup of you wallet will not have this key in obviously. So before you do anything else close the
client (to ensure that it is locked again) and backup the wallet.dat file as normal.

Help:How to import private keys in Bitcoin Core 0.7+

2013-01-24T21:54:20Z

Dooglus: /* Unlock your wallet */ typos

==Backup Your Wallet==
Although this process is well tested and used you should always take another backup
of your wallet.dat file before starting.

==Open Debug Window==
Then go to menu:
/Help/Debug Window

[[File:Screen1.PNG|px200]]

and click on the tab - Console.

==Unlock your wallet==

If your wallet is encrypted (I hope it is!) you must unlock it. If not just skip this step.

To do this just type into the box at the bottom:
<pre>
walletpassphrase "YourLongPassphrase" 600
</pre>
You need the quotes if there is a space in your phrase else there is no need for them.
The 600 means your wallet is unlocked for 10 minutes (600 seconds).

[[File:Unlock.PNG|px200]]

==Run Import Command in Debug Window==
In the console at the very bottom is a text entry box in here enter:
<pre>
importprivkey yourPrivateKeyInWalletImportFormat "TheLabelThatIWant"
</pre>
The quotes are only needed if you want a space in the label.
[[File:Import1.PNG]]

You now have to be patient. On a fast PC it takes 2 minutes to import, and
during this time it looks like you application has hung. After waiting a few minutes
you will see:

[[File:Import2.PNG]]

You are now done. But always best to check it worked.

==Check Key Imported OK==

Once Imported you can check that you have the address by closing the Debug window and going back to your address book.

You should see the address here:

[[File:InAddressBook.PNG]]

And you can even send a transaction to check e.g.

[[File:ReceivedTrans.PNG]]

==Backup Wallet==
Your backup of you wallet will not have this key in obviously. So before you do anything else close the
client (to ensure that it is locked again) and backup the wallet.dat file as normal.

List of address prefixes

2012-10-10T14:15:35Z

Dooglus: prefixes for uncompressed and compressed private keys differ

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Uncompressed Bitcoin Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Compressed Bitcoin Private key
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-10-10T13:02:14Z

Dooglus: give example testnet privkey, and correct the starting character

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Bitcoin Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|c
|Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

Script

2012-03-19T21:44:37Z

Dooglus: fix the description of OP_IFDUP

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to show evidence of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).

Scripts are big-endian.

The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

== Words ==
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain.

True=1 and False=0.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not 0, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is 0, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / False
|'''Marks transaction as invalid''' if top stack value is not true. True is removed, but false is not.
|-
|OP_RETURN
|106
|0x6a
|Nothing
|Nothing
|'''Marks transaction as invalid'''.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|Concatenates two strings. ''Currently disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|Returns a section of a string. ''Currently disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|Keeps only characters left of the specified point in a string. ''Currently disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|Keeps only characters right of the specified point in a string. ''Currently disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Returns the length of the input string.
|}

=== Bitwise logic ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|Flips all of the bits in the input. ''Currently disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|Boolean ''and'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|Boolean ''or'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|Boolean ''exclusive or'' between each bit in the inputs. ''Currently disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|True / false
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Arithmetic is limited to max 4 byte integers

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|The input is multiplied by 2. ''Currently disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|The input is divided by 2. ''Currently disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|a is multiplied by b. ''Currently disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|a is divided by b. ''Currently disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|Returns the remainder after dividing a by b. ''Currently disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|Shifts a left b bits, preserving sign. ''Currently disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|Shifts a right b bits, preserving sign. ''Currently disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|out
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|True / false
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|True / False
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction invalid.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_VERNOTIF
|102
|0x66
|Transaction is invalid even when occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED1
|137
|0x89
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|Transaction is invalid unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1-OP_NOP10
|176-185
|0xb0-0xb9
|The word is ignored.
|}

== Scripts ==
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above.

=== Standard Transaction to Bitcoin address ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Standard Generation / transaction to IP address ===

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction with a message ===

It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. Scripts are limited to 10,000 bytes and 201 instructions/values, and each individual instruction/value is limited to 520 bytes.

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptSig: <sig>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG
|
|-
|<sig>
|<message> OP_DROP <pubKey> OP_CHECKSIG
|scriptSig added to the stack.
|-
|<sig> <message>
|OP_DROP <pubKey> OP_CHECKSIG
|The message has been put.
|-
|<sig>
|<pubKey> OP_CHECKSIG
|Top stack item has been removed.
|-
|<sig> <pubKey>
|OP_CHECKSIG
|Checking signature against the public key.
|-
|true
|Empty.
|Stack holds the value of signature check now.
|}

=== Example non standard transaction on Testnet ===

These 2 links below show a non standard transaction. It just prepends the hex of "bob" and the operation OP_DROP
which just removes it. As you can see they can be spent as normal.

Input non-std transaction:
http://blockexplorer.com/testnet/t/6ttfeb55B1

Spent by:
http://blockexplorer.com/testnet/t/AFdRB1CHS3

==See Also==

* [[Transactions]]
* [[Contracts]]

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

Vocabulary

2012-03-10T20:16:06Z

Dooglus: differentiate between 'hash' and 'hash function'

;'''Bitcoin''' ''(abbreviated BTC)''
: The name of a decentralized p2p crypto-currency application.
;'''[[Bitcoins]]'''
: The currency used and generated within the Bitcoin system.
;'''[[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.
;'''Branching Point'''
: The block at which the block chain diverges into multiple chain branches
;'''BTC'''
: The common decimal [[Units|unit]] of Bitcoins, equal to 100,000,000 satoshis.
;'''Chain Branching'''
;'''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'''
: Attempting to spend coins that have already been spent in another transaction
;'''Generate Bitcoins'''
: When a Bitcoin miner finds a block, it receives newly minted bitcoins and the transaction fees which may or may not be included in the block. The amount of bitcoins awarded for verifying a block is 50 BTC for the first 210,000 blocks and half the previous amount of bitcoins for each subsequent 210,000 blocks. On average, 210,000 blocks take about 4 years to verify. The total amount of bitcoins that will ever be minted is roughly 21,000,000 BTC.
;'''[[Hash]]'''
: The output of a 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.
;'''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 that is not in the currently-longest [[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.
;'''Subsidy'''
: The block subsidy is the BTC created for generating a block. The subsidy is halved every four years.
;'''Super Nodes'''
: A participant in a p2p network which connects to as many other nodes as possible.
;'''[[Tonal Bitcoin]]''' ''(abbreviated TBC)''
: 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| ]]

List of address prefixes

2012-02-29T19:36:39Z

Dooglus: add testnet private key format

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|239
|2
|Testnet Private key
|
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-23T05:46:26Z

Dooglus: use a valid example geist geld address. gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK is too short to be valid, even though it's geist geld's creator's donation address...

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T07:06:45Z

Dooglus: show example addresses in fixed width font. notice GEG address is too short...

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Private key
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T06:49:36Z

Dooglus: add more example addresses, found randomly on the forums. the private key was generated randomly using bitaddress.org

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|95
|f
|Fairbrix pubkey hash
|fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|105
|j
|i0coin pubkey hash
|jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|125
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|-
|127
|t
|Tenebrix pubkey hash
|tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL
|-
|128
|5
|Private key
|5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq
|-
|138
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T05:46:09Z

Dooglus: i0coin uses version 105. https://github.com/doublec/i0coin/blob/master/src/base58.h "SetData(fTestNet ? 112 : 105, &hash160, 20);"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|95
|f
|Fairbrix pubkey hash
|
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|105
|j
|i0coin pubkey hash
|jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|125
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|138
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T05:41:18Z

Dooglus: Fairbrix addresses use version 95: https://github.com/coblee/Fairbrix/blob/cpumine/src/base58.h : "#define ADDRESSVERSION ((unsigned char)(fTestNet ? 95 : 95))"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|95
|f
|Fairbrix pubkey hash
|
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|125
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|138
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T02:53:03Z

Dooglus: solidcoin uses version 125. see http://downloads.solidcoin.info/solidcoin-source-2041.zip , src/base58.h: "nVersion = 125;"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|125
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|138
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|196
|2
|Bitcoin testnet script hash
|
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T02:49:44Z

Dooglus: ixcoin uses version 138. https://github.com/ixcoin/ixcoin/blob/master/src/base58.h : "#define ADDRESSVERSION ((unsigned char)(fTestNet ? 111 : 138)) //ixcoin"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|138
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|?
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T02:46:57Z

Dooglus: geistgeld uses version 97 - see https://github.com/Lolcust/GeistGeld/blob/multimergemine2/geist.conf : "AddressVerson=97". verson, wtf?

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|97
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|?
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|?
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T02:30:21Z

Dooglus: Tenebrix addresses start with 't': https://github.com/Lolcust/Tenebrix/blob/cpumine/src/base58.h - "#define ADDRESSVERSION ((unsigned char)(fTestNet ? 127 : 127))"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|127
|t
|Tenebrix pubkey hash
|
|-
|128
|5
|Private key
|
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|?
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|?
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|?
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T01:55:51Z

Dooglus: litecoin uses 48 - see https://github.com/coblee/litecoin/blob/master/src/base58.h : "SetData(fTestNet ? 111 : 48, &hash160, 20); // Litecoin addresses start with L"

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|48
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|128
|5
|Private key
|
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|?
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|?
|?
|Tenebrix pubkey hash
|
|-
|?
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|?
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

List of address prefixes

2012-02-20T01:54:37Z

Dooglus: add a table showing address length and prefix for each version byte

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j
|-
|5
|3
|Bitcoin script hash
|
|-
|21
|4
|Bitcoin (compact) public key (proposed)
|
|-
|52
|M or N
|Namecoin pubkey hash
|NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz
|-
|128
|5
|Private key
|
|-
|196
|2
|Bitcoin testnet script hash
|
|-
|?
|L
|Litecoin pubkey hash
|LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr
|-
|?
|g
|GeistGeld pubkey hash
|gK5Lx6ypWgr69Gw9yGzE6dsA7kcuCRZRK
|-
|?
|?
|Tenebrix pubkey hash
|
|-
|?
|x
|ixcoin pubkey hash
|xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV
|-
|?
|s
|Solidcoin pubkey hash
|sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f
|}

The following table shows the leading symbol(s) and address length(s) for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

Base58Check encoding

2012-02-19T01:33:19Z

Dooglus: /* Version bytes */ base58.h says "PUBKEY_ADDRESS_TEST = 111". not 192. and my testnet address begins with an 'm', not a '2'.

A modified Base 58 encoding known as '''Base58Check''' is used for encoding [[Bitcoin address]]es.

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings. A Bitcoin address is simply a Base58Check-encoded string with a 20-byte payload, the payload being the hash of the [[public key]] associated with the address.

The original Bitcoin client source code discusses 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 0x05 for this byte (older ones used 0x00).
* 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/application 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.'''

==Encoding a Bitcoin address==
A Bitcoin address is based on any [[ECDSA]] [[secp256k1]] public/private [[key pair]].

A Bitcoin address is the Base58Check encoding of the hash of the associated [[script]]. Specifically, it is Base58Check(5,[[RIPEMD160]]([[SHA256]]([[script]]))), with the following constraints:
* [[RIPEMD160]] and [[SHA256]] in this case are always exactly 20 and 32 unsigned bytes respectively. 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.)
* 0 refers to the version/application byte.

Because of the 0x05 version/application byte, Bitcoin addresses always start with the digit '3'.

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key]]s 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). 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.
{| 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 0x01 + hash + 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
|}

== Source ==
https://github.com/bitcoin/bitcoin/blob/master/src/base58.h

== Relevant functions in source code ==
* inline string EncodeBase58Check(const vector<unsigned char>& vchIn)
* inline bool DecodeBase58Check(const char* psz, vector<unsigned char>& vchRet)
* inline bool DecodeBase58Check(const string& str, vector<unsigned char>& vchRet)

[[Category:Technical]]

Difficulty

2012-02-15T07:31:58Z

Dooglus: fixed typos

''See also: [[target]]''

=== What is "difficulty"? ===

Difficulty is a measure of how difficult it is to find a new [[block]] compared to the easiest it can ever be.

=== How often does the difficulty change? ===

Every 2016 [[block|blocks]].

=== What is the formula for difficulty? ===

difficulty = maximum_target / current_target

(target is a 256 bit number)

===How is difficulty stored in blocks?===

Each block stores a packed representation (called "Bits") for its actual hexadecimal [[target]]. The target can be derived from it via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

So the difficulty at 0x1b0404cb is therefore:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983

Here's a fast way to calculate difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:

<source lang="cpp">
#include <iostream>
#include <cmath>

inline float fast_log(float val)
{
int * const exp_ptr = reinterpret_cast <int *>(&val);
int x = *exp_ptr;
const int log_2 = ((x >> 23) & 255) - 128;
x &= ~(255 << 23);
x += 127 << 23;
*exp_ptr = x;

val = ((-1.0f/3) * val + 2) * val - 2.0f/3;
return ((val + log_2) * 0.69314718f);
}

float difficulty(unsigned int bits)
{
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));
}

int main()
{
std::cout << difficulty(0x1b0404cb) << std::endl;
return 0;
}
</source>

Unfortunately I don't have much use for it in libbitcoin. Maybe some miner will find it useful.

To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:

<source lang="python">
import decimal, math
l = math.log
e = math.e

print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)
</source>

=== What is the current difficulty? ===
[http://blockexplorer.com/q/getdifficulty Current difficulty], as output by BitCoin's getDifficulty.

[http://blockexplorer.com/q/estimate Estimated next difficulty]

[http://bitcoin.sipa.be Graphs]

=== What is the maximum difficulty? ===

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)

=== Can the difficulty go down? ===
Yes it can. See discussion in [[target]].

=== What is the minimum difficulty? ===
The minimum difficulty, when the target is at the maximum allowed value, is 1.

=== What network hash rate results in a given difficulty? ===
The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is
0xffff * 2**208
and for difficulty D is
(0xffff * 2**208)/D

The expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208)
or just
D * 2**48 / 0xffff

The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was
D * 2**48 / 0xffff / 600
over the previous 2016 blocks. Can be further simplified to
D * 2**32 / 600
without much loss of accuracy.

At difficulty 1, that is around 7 Mhashes per second.

At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.

=== How soon might I expect to generate a block? ===
(The [https://www.bitcointalk.org/index.php?topic=1682.0 eternal question].)

The average time to find a block can be approximated by calculating:
time = difficulty * 2**32 / hashrate
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.

For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"
23.85
and find that it takes just under 24 hours on average.

* Any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts your hardware can make per second.
* You need to know the difficulty (above) and your khash/sec rate (reported by the client).
** [[Mining Hardware Comparison]] has some stats that may help you predict what you could get.
* Visit a calculator or perform the maths yourself,
** http://www.alloscomp.com/bitcoin/calculator.php
* Remember it's just probability! There are no guarantees you will win every N days.

==Related Links==

* [http://btcserv.net/bitcoin/history/ Bitcoin Difficulty History]
* See also: [[target]]

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

[[pl:Trudność]]

P2Pool

2012-02-13T06:46:23Z

Dooglus: /* Donating to P2Pool miners */ explain more about donating to miners

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and has better fundamental resistance to DoS attacks than centralized pools.

Miners are configured to connect to a P2Pool node that can be run locally, alongside the miner. P2Pool users must run a full Bitcoin node which serves the purpose of independently validating transactions and the Bitcoin blockchain. P2Pool also supports merged mining and several alternative blockchains.

P2Pool nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns above 100% of the expected reward.

== Overview ==

P2Pool shares form a "sharechain" with each share referencing the previous share's hash. Each share contains a standard Bitcoin block header, some P2Pool-specific data that is used to compute the generation transaction (total subsidy, payout script of this share, a nonce, the previous share's hash, and the current target for shares), and a Merkle branch linking that generation transaction to the block header's Merkle hash.

The chain continuously regulates its target to keep generation around one share every ten seconds, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.)

=== Payout logic ===

Each share contains a generation transaction that pays to the previous ''n'' shares, where ''n'' is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 50BTC) and the transaction fees are combined and apportioned according to these rules:

A subsidy of 0.5% is sent to the node that solved the block in order to discourage not sharing solutions that qualify as a block. (A miner with the aim to harm others could withhold the block, thereby preventing anybody from getting paid. He can NOT redirect the payout to himself.) The remaining 99.5% is distributed evenly to miners based on work done recently.

In the event that a share qualifies as a block, this generation transaction is exposed to the Bitcoin network and takes effect, transferring each node its payout.

=== Stales ===

P2Pool stales don't work the same way as stales on centralized pools. On a centralized pool a stale is work which is too old to be accepted by the pool's Bitcoin node; this kind of stale is very rare in P2Pool because each user runs their own local bitcoind.

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

When you first start P2Pool claimed efficiency will be low and the error bounds on this estimate will be large, but as it runs the numbers will converge to their correct values.

If your efficiency is unusually low, make sure your network connection isn't overloaded, that your miners support long polling and are not set to work for excessive amounts of time, and that your bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** Bitcoin 0.5 or later is required
** It's important that your Bitcoin client be fully synchronized before starting. It's also better if you have the Bitcoin port forwarded
* Download p2pool:
** Windows binary: See http://forum.bitcoin.org/index.php?topic=18313.0
** Source download: https://github.com/forrestv/p2pool/tags
** git: git clone git://github.com/forrestv/p2pool.git
* Run p2pool: (See below for additional options.)
** Windows py2exe: run_p2pool.exe
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== Miners ===

This is all for the latest p2pool version, as it includes several new workarounds.

With all miners, using a HIGH FPS target (100?) or a LOW intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--p2pool-port PORT] [-n ADDR[:PORT]] [--disable-upnp]
[-w PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
use specified network (default: bitcoin)
--testnet use the network's testnet
--debug enable debugging mode
-a ADDRESS, --address ADDRESS
generate payouts to this address (default: <address
requested from bitcoind>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--disable-upnp don't attempt to use UPnP to forward p2pool's P2P port
from the Internet to this computer

p2pool interface:
--p2pool-port PORT use port PORT to listen for connections (forward this
port from your router!) (default: bitcoin:9333,
litecoin:9338)
-n ADDR[:PORT], --p2pool-node ADDR[:PORT]
connect to existing p2pool node at ADDR listening on
port PORT (defaults to default p2pool P2P port) in
addition to builtin addresses

worker interface:
-w PORT, --worker-port PORT
listen on PORT for RPC connections from miners
(default: bitcoin:9332, litecoin:9327)
-f FEE_PERCENTAGE, --fee FEE_PERCENTAGE
charge workers mining to their own bitcoin address (by
setting their miner's username to a bitcoin address)
this percentage fee to mine on your p2pool instance.
Amount displayed at http://127.0.0.1:WORKER_PORT/fee
(default: 0)

bitcoind interface:
--bitcoind-address BITCOIND_ADDRESS
connect to this address (default: 127.0.0.1)
--bitcoind-rpc-port BITCOIND_RPC_PORT
connect to JSON-RPC interface at this port (default:
bitcoin:8332, litecoin:9332 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== Protocol description ==

P2Pool's protocol mirrors Bitcoin's P2P protocol in many ways. It uses the same framing (prefix, command, length, checksum, payload) and similar commands:

* '''version''' - sent to establish a connection - contains (''version'', ''services'', ''addr_to'', ''addr_from'', ''nonce'', ''sub_version'', ''mode'', ''best_share_hash'')
* '''setmode''' - sent to update the ''mode'' sent in the '''version''' message - contains (''mode'')
* '''ping''' - sent to keep connection alive - contains ()
* '''addrme''' - request that the receiving node send out an addr for the sending node - contains (''port'')
* '''addrs''' - broadcast list of nodes' addresses - contains (''addrs'')
* '''getaddrs''' - request that the receiving node send ''count'' addrs - contains (''count'')
* '''getshares''' - request that the receiving node send the shares referenced by ''hashes'' and ''parents'' of their parents, stopping at any share referenced by ''stops'' - contains (''hashes'', ''parents'', ''stops'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 forum profile].

==Donating to P2Pool miners==
In order to encourage people to mine to P2Pool you can donate to the recent miners in proportion using a sendmany:

For example, a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you can replace forre.st with 127.0.0.1 if you're running a P2Pool node locally, so you don't have to trust that the URL gives accurate figures.

Note that the amount you donate will be allocated to recent miners in proportion to the amount of work they've done in the last 24 hours or so, but all the miner whose shares of the donated amount are less than 0.01 BTC will have their shares combined into a single amount which is awarded to one of them at random, with the chance of winning this 'lottery' weighted by the miner's recent amount of work done. You can change this 0.01 BTC threshold like this, for example, which says to pay 10 BTC, but to share it amongst more miners that the default, cutting off at 0.001 BTC instead of at 0.01 BTC.
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10/0.001)"
</pre>

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2012-02-13T06:24:48Z

Dooglus: /* Donating to P2Pool miners */ fixed typo

[[Image:P2pool_chain.png‎|thumb|350px|right|Visualization of the P2Pool share chain]]
P2Pool is a decentralized [[Bitcoin]] [[Bitcoin Pool|mining pool]] that works by creating a peer-to-peer network of miner nodes.

<blockquote>P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target. Whenever a peer announces a new share found (new block in the P2Pool block chain), it is received by the other peers, and the other peers verify that this block contains payouts for all the previous miners who found a share (and announced it) that made it into the P2Pool share chain. This continues until some peer finds a block that has a difficulty that meets the Bitcoin network's difficulty target. This peer announces this block to the Bitcoin network and miners who have submitted shares for this block are paid in the generation transaction, proportionally to how many shares they have found in the last while. - Unknown author</blockquote>

Decentralized payout pooling solves the problem of centralized mining pools degrading the decentralization of Bitcoin, avoids the risk of hard to detect theft by pool operators, and has better fundamental resistance to DoS attacks than centralized pools.

Miners are configured to connect to a P2Pool node that can be run locally, alongside the miner. P2Pool users must run a full Bitcoin node which serves the purpose of independently validating transactions and the Bitcoin blockchain. P2Pool also supports merged mining and several alternative blockchains.

P2Pool nodes work on a chain of shares similar to Bitcoin's blockchain. Each node works on a block that includes payouts to the previous shares' owners and the node itself, which can also result in a share if it meets P2Pool's difficulty.

Because of the importance of strengthening Bitcoin's decentralization some Bitcoin supporters donate to P2Pool miners, resulting in returns above 100% of the expected reward.

== Overview ==

P2Pool shares form a "sharechain" with each share referencing the previous share's hash. Each share contains a standard Bitcoin block header, some P2Pool-specific data that is used to compute the generation transaction (total subsidy, payout script of this share, a nonce, the previous share's hash, and the current target for shares), and a Merkle branch linking that generation transaction to the block header's Merkle hash.

The chain continuously regulates its target to keep generation around one share every ten seconds, just as Bitcoin regulates it to generate one block every ten minutes.

Unlike Bitcoin, nodes do not know the entire chain - instead they only hold the last 8640 shares (the last day's worth). In order to prevent an attacker from working on a chain in secret and then releasing it, overriding the existing chain, chains are judged by how much work they have since a point in the past. To ascertain that the work has been done since that point, nodes look at the Bitcoin blocks that the shares reference, establishing a provable timestamp. (If a share points to a block, it was definitely made after that block was made.)

=== Payout logic ===

Each share contains a generation transaction that pays to the previous ''n'' shares, where ''n'' is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.

The block reward (currently 50BTC) and the transaction fees are combined and apportioned according to these rules:

A subsidy of 0.5% is sent to the node that solved the block in order to discourage not sharing solutions that qualify as a block. (A miner with the aim to harm others could withhold the block, thereby preventing anybody from getting paid. He can NOT redirect the payout to himself.) The remaining 99.5% is distributed evenly to miners based on work done recently.

In the event that a share qualifies as a block, this generation transaction is exposed to the Bitcoin network and takes effect, transferring each node its payout.

=== Stales ===

P2Pool stales don't work the same way as stales on centralized pools. On a centralized pool a stale is work which is too old to be accepted by the pool's Bitcoin node; this kind of stale is very rare in P2Pool because each user runs their own local bitcoind.

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is [[Comparison_of_mining_pools|PPLNS]] only your stale rate relative to other nodes is relevant; the absolute rate is not.

There are two reported kinds of stales in P2Pool: "DEAD ON ARRIVAL" shares and orphan shares. Dead shares were too old by the time they arrived at your local P2Pool. Very high dead rates can indicate miner misconfiguration. Orphan shares are shares which were not extended by the rest of the P2Pool network, because some other miner's share was accepted first. Very high orphan rates may indicate network connectivity problems.

The P2Pool console output shows your relative stale rate compared to other P2Pool miners in the 'Own efficiency' column:
<pre>
2012-01-07 20:57:51.797420 Pool stales: 13% Own: 13±2% Own efficiency: 100±2%
</pre>

When you first start P2Pool claimed efficiency will be low and the error bounds on this estimate will be large, but as it runs the numbers will converge to their correct values.

If your efficiency is unusually low, make sure your network connection isn't overloaded, that your miners support long polling and are not set to work for excessive amounts of time, and that your bitcoind has multiple connections.

== Joining the pool ==

Follow these steps to join the pool:

* Run Bitcoin with the RPC interface enabled: put rpcuser=USER, rpcpassword=LONG_RANDOM_SECRET_VALUE, and server=1 in bitcoin.conf (on separate lines)
**'''Replace LONG_RANDOM_SECRET_VALUE with something long and random like the output of smashing your keyboard for a bit like fju4M78yAj3ds39pak92raK'''. You don't need to be able to remember it. If your RPC port becomes exposed to the internet a thief could steal your bitcoin if they could guess it, or use a brute force attack in order to find it.
** Bitcoin 0.5 or later is required
** It's important that your Bitcoin client be fully synchronized before starting. It's also better if you have the Bitcoin port forwarded
* Download p2pool:
** Windows binary: See http://forum.bitcoin.org/index.php?topic=18313.0
** Source download: https://github.com/forrestv/p2pool/tags
** git: git clone git://github.com/forrestv/p2pool.git
* Run p2pool: (See below for additional options.)
** Windows py2exe: run_p2pool.exe
** Source: python run_p2pool.py
* Run a miner daemon with long polling connecting to 127.0.0.1 (or the IP of the host running p2pool if it isn't on the same computer as the miner) on port 9332 with any username and password
** cgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher
* python-argparse for Python 2.6 and lower
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man" 
'''A:''' "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin"

'''Q:''' "Do the 'orphan' and 'dead' shares in P2Pool's status display hurt me?" 
'''A:''' They shouldn't - It's normal for some fraction of everyone's shares to end up orphaned or dead. Because payouts are calculated by counting how many shares you have relative to others, everyone with normal configurations is equally "hurt" by this. However, if you have a large proportion of stales, your payout will be hurt. You can see how well you're doing by looking at P2Pool's "Efficiency" (ex: ''Efficiency: ~110.6% (40-111%)''). If 100% doesn't lie within the [http://en.wikipedia.org/wiki/Confidence_interval confidence interval] at the end, something is probably wrong (with 5% confidence).

'''Q:''' "What do I do if my efficiency is low?" 
'''A:''' If you have a lot of dead shares or the "Local dead on arrival" number is higher than a few percent, that means that something is wrong with your miner. Check to make sure that it is one of the working versions in the ''Miners'' section on this page. Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. Lower the intensity or raise the FPS of your miner. If you have a lot of orphan shares, something is wrong with P2Pool's P2P connection. Don't overload your internet connection or enable QoS (Quality of Service) on your router.

=== Miners ===

This is all for the latest p2pool version, as it includes several new workarounds.

With all miners, using a HIGH FPS target (100?) or a LOW intensity (8 for cgminer?) helps a lot with reducing stales.

* cgminer works perfectly without any extra options. However, using multiple pools might cause problems, because long polling is only done for one pool.
* ufasoft works perfectly.
* DiabloMiner works fine after commit 3b731b9.
* Phoenix works fine after commit a658ef2.
* Poclbm works fine after commit 5e994e7.

P2Pool uses higher difficulty shares than most centralized pools, so you'll see fewer shares reported. This is normal and doesn't reduce your payments. It's also normal to see longpoll messages once per every ten seconds on average.

=== Useful features ===

* If upgrading P2Pool or changing its configuration, you can start another instance of P2Pool in parallel with the first. It will start normally, but realize that the worker and P2P listening ports are busy and keep trying to bind to them in the background. Thus, you can do almost-completely-seemless upgrades of P2Pool.
* If you run multiple P2Pool nodes or have trusted friends that run P2Pool, you can use ''-n'' to establish a constant extra P2P connection to them.
* You can make P2Pool use a configuration file by running run_p2pool.py @FILENAME, with FILENAME being the path to a file containing the command-line arguments (newlines are ignored) Example:
<pre>
--net litecoin
-n 1.2.3.4
</pre>
* Setting the username of your miner connecting to P2Pool to a Bitcoin address will make it mine to that address instead of the one requested from bitcoind or set by -a

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /graphs - RRD graphs of past hash rates for pool and local miners. Look for "VIP password" in P2Pool's output when it starts and use that for your miners to get graphs for individual miners.
* /rate
* /users
* /fee
* /current_payouts
* /patron_sendmany - Gives sendmany outputs for fair donations to P2Pool
* /global_stats
* /local_stats
* /peer_addresses
* /payout_addr
* /recent_blocks
* /uptime
* /chain_img - Visualization of sharechain
* /web/log - Some different stats collected over the last day

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin, litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--merged-url MERGED_URL]
[--merged-userpass MERGED_USERPASS]
[--give-author DONATION_PERCENTAGE] [--irc-announce]
[--p2pool-port PORT] [-n ADDR[:PORT]] [--disable-upnp]
[-w PORT] [-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]

p2pool (version 28a1948)

optional arguments:
-h, --help show this help message and exit
--version show program's version number and exit
--net {bitcoin, litecoin}
use specified network (default: bitcoin)
--testnet use the network's testnet
--debug enable debugging mode
-a ADDRESS, --address ADDRESS
generate payouts to this address (default: <address
requested from bitcoind>)
--datadir DATADIR store data in this directory (default: <directory
run_p2pool.py is in>/data)
--logfile LOGFILE log to this file (default: data/<NET>/log)
--merged MERGED_URLS call getauxblock on this url to get work for merged
mining (example:
http://ncuser:ncpass@127.0.0.1:10332/)
--merged-url MERGED_URL
DEPRECATED, use --merged
--merged-userpass MERGED_USERPASS
DEPRECATED, use --merged
--give-author DONATION_PERCENTAGE
donate this percentage of work to author of p2pool
(default: 0.5)
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--disable-upnp don't attempt to use UPnP to forward p2pool's P2P port
from the Internet to this computer

p2pool interface:
--p2pool-port PORT use port PORT to listen for connections (forward this
port from your router!) (default: bitcoin:9333,
litecoin:9338)
-n ADDR[:PORT], --p2pool-node ADDR[:PORT]
connect to existing p2pool node at ADDR listening on
port PORT (defaults to default p2pool P2P port) in
addition to builtin addresses

worker interface:
-w PORT, --worker-port PORT
listen on PORT for RPC connections from miners
(default: bitcoin:9332, litecoin:9327)
-f FEE_PERCENTAGE, --fee FEE_PERCENTAGE
charge workers mining to their own bitcoin address (by
setting their miner's username to a bitcoin address)
this percentage fee to mine on your p2pool instance.
Amount displayed at http://127.0.0.1:WORKER_PORT/fee
(default: 0)

bitcoind interface:
--bitcoind-address BITCOIND_ADDRESS
connect to this address (default: 127.0.0.1)
--bitcoind-rpc-port BITCOIND_RPC_PORT
connect to JSON-RPC interface at this port (default:
bitcoin:8332, litecoin:9332 <read from bitcoin.conf if
password not provided>)
--bitcoind-p2p-port BITCOIND_P2P_PORT
connect to P2P interface at this port (default:
bitcoin:8333, litecoin:9333 <read from bitcoin.conf if
password not provided>)
BITCOIND_RPCUSERPASS bitcoind RPC interface username, then password, space-
separated (only one being provided will cause the
username to default to being empty, and none will
cause P2Pool to read them from bitcoin.conf)
</pre>

== Protocol description ==

P2Pool's protocol mirrors Bitcoin's P2P protocol in many ways. It uses the same framing (prefix, command, length, checksum, payload) and similar commands:

* '''version''' - sent to establish a connection - contains (''version'', ''services'', ''addr_to'', ''addr_from'', ''nonce'', ''sub_version'', ''mode'', ''best_share_hash'')
* '''setmode''' - sent to update the ''mode'' sent in the '''version''' message - contains (''mode'')
* '''ping''' - sent to keep connection alive - contains ()
* '''addrme''' - request that the receiving node send out an addr for the sending node - contains (''port'')
* '''addrs''' - broadcast list of nodes' addresses - contains (''addrs'')
* '''getaddrs''' - request that the receiving node send ''count'' addrs - contains (''count'')
* '''getshares''' - request that the receiving node send the shares referenced by ''hashes'' and ''parents'' of their parents, stopping at any share referenced by ''stops'' - contains (''hashes'', ''parents'', ''stops'')
* '''shares''' - broadcast message of the contents of shares - contains (''shares'')

==History==

This project was announced on June 17, 2011 by Forrest Voight<ref>[https://forum.bitcoin.org/index.php?topic=18313.0 p2pool: Decentralized, DoS-resistant, Hop-Proof - Now active on mainnet!]</ref>.

The began testing against mainnet in mid-July, 2011. The pool was reviewed on a [[Bitcoin Miner]] post on July 26, 2011<ref>[http://www.bitcoinminer.com/post/8101660461 P2Pool Decentralized Pool Nearly Ready For Prime-Time]</ref>.

The software author's address for donations can be found in the signature section of his [http://forum.bitcoin.org/index.php?action=profile;u=6447 forum profile].

==Donating to P2Pool miners==
In order to encourage people to mine to P2Pool you can donate to the recent miners in proportion using a sendmany:

E.g. a bash script to donate 10 btc is:
<pre>
~/src/bitcoin/src/bitcoind sendmany "" "$(GET http://forre.st:9332/patron_sendmany?total=10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you can replace forre.st with 127.0.0.1 if you're running a P2Pool node locally, so you don't have to trust that the URL gives accurate figures.

If you decide to donate you should announce it on the forums so that your donations provide the most incentive possible.

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]

==External Links==

* [http://forum.bitcoin.org/index.php?topic=18313.0 P2Pool forum]
* [https://github.com/forrestv/p2pool p2pool] project on GitHub
* {{Freenode IRC|p2pool}} discussion and support

==References==
<references />

[[Category:Pool Operators]]

OP CHECKSIGEX DRAFT BIP

2012-02-01T06:48:07Z

Dooglus: /* Backwards Compatibility */ typo, confirmed in https://bitcointalk.org/index.php?topic=62037.msg725518#msg725518

<pre>
BIP: 22
Title: OP_CHECKSIGEX
Author: Mike Caldwell <mcaldwell@swipeclock.com>
Status: Draft
Type: Standards Track
Created: 31-01-2012
</pre>

==Abstract==

This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.

==Motivation==
The purpose of this proposal is to address some of the perceived shortcomings in [[BIP 0016]] and [[BIP 0017]], as well as objections that have been raised with respect to the difficulty in statically analyzing all of the potential scenarios that could arise. If adopted, it would be a complete replacement for both BIP 16 and BIP 17.

Like BIP 16, this proposal keeps the burden for supplying the conditions to redeem a transaction on the redeemer.

Like BIP 16 and BIP 17, this proposal ensures that payments to multisig addresses can be accomplished with addresses in the customary format. In other words, this proposal provides the benefit of allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.

Unlike BIP 16 and BIP 17, this proposal creates no new transaction types.

Unlike BIP 16 and BIP 17, this proposal is believed to create no new scenarios where a "stealing bot" could be implemented to grab transactions created under the new standard from the view of the old clients.

Unlike BIP 16, this proposal creates no new types of script that must be recognized as a special case by design (referred to in BIP 16 as "ugly").

Unlike BIP 17, this proposal requires no reliance on the redefinition of OP_NOP opcodes to operations that must trigger failure, where they would never trigger failure under their prior definitions.

Unlike BIP 16 and BIP 17, implementation of this proposal is likely to be relatively simple and easy to audit, with modifications localized to as few as two key areas of the code. Changes to the definition of a standard transaction would be a single straightforward increase to the maximum size of a parameter, and the entire set of changes to script behavior would be a single block addition that fits completely within the case statement currently handling OP_CHECKSIG.

This proposal goes out of its way expressly to avoid Turing completeness and to permit easy visual verification that Turing completeness has not been added. In particular, it proposes creation of an extra sandbox stack whose access is exclusive to evaluation functions. This evaluation stack is a completely new stack that is independent of the regular and "alt" stacks defined in the Bitcoin scripting system.

In this proposal, all existing transactions become normal cases of an extended opcode. No changes are made to the way new transactions are sent, only how they are redeemed.

==Specification==

The OP_CHECKSIG function is renamed to OP_CHECKSIGEX and termed ''check signature expression''. The current OP_CHECKSIG takes two parameters: a signature and a public key; the redefined OP_CHECKSIGEX is extended such that its arguments are a ''list'' of n signatures along with a ''public key expression'' that consumes those signatures, and also which supports a subset of interpreted opcodes that are executed strictly on a new, separate sandbox stack known as the ''expression evaluation'' stack.

By retaining the same opcode, all existing transactions using OP_CHECKSIG (i.e. the vast majority of Bitcoin transactions) become OP_CHECKSIGEX transactions. Specifically, they become a specific case of OP_CHECKSIGEX: one which happen to contain exactly one signature and one public key to be validated. Thus, they retain identical behavior as before the redefinition.

As OP_CHECKSIGEX, the function will continue to pop two parameters from the stack: one representing public key(s), and the other representing signature(s). Under the original OP_CHECKSIG, the public key portion is always 65 bytes. Under the extended OP_CHECKSIGEX, the public key portion may be greater than 65 bytes, this would represent the multi-signature formula supplied at redemption.

A public key expression, whether 65 bytes or larger, constitutes an ''evaluation script'' that runs in a limited context, and only has access to an evaluation stack. An evaluation script strictly cannot read, push, pop, or otherwise reference anything on the stack(s) used in normal script processing. The evaluation stack shall be empty at the beginning of each execution of OP_CHECKSIGEX, and the OP_CHECKSIGEX operation has exactly two results: complete transaction failure, or validation success (with behavior identical to a successful OP_CHECKSIG as presently defined).

It shall be noted that in Bitcoin, all 65-byte public keys begin with the byte 0x04, which is a constant that denotes an uncompressed public key. (In this context, "uncompressed" means that both the X and Y components of the public key are provided, as opposed to Y being flagged as computable from X and therefore omitted. In Bitcoin, each component is always 32 bytes; two 32-byte components plus the 0x04 prefix add up to 65 bytes.)

The fact that the existing OP_CHECKSIG expects public keys starting with 0x04 is exploited in this proposal, by defining 0x04 in OP_CHECKSIGEX in the context of evaluation to simply mean, "check one ECDSA signature in uncompressed format". Therefore, an existing transaction consisting of a single public key, single signature, and transactions currently utilizing OP_CHECKSIG would
become interpreted as an OP_CHECKSIGEX opcode which contains an instruction (0x04) to check a single uncompressed signature - resulting in identical behavior.

By including a subset of opcodes specifically turned on for OP_CHECKSIGEX, the multi signature functionality can be included in a reduced "expression" context without the risk of adding Turing-completeness to the scripting engine, nor the risk of the ability of scripts to modify themselves. In addition, the opcodes that are currently disabled due to non-use (such as the arithmetic opcodes that evaluation would need) can be enabled in a context that greatly limits their reach, since they'll be running in an enclosed environment with highly limited data access.

The signature list is a simple binary blob of digital signatures concatenated together, each of which can either be present, or intentionally omitted (leaving a null placeholder entry in the list). As already is the practice in standard Bitcoin transactions, real signatures always begins with 0x30 plus a length byte which can be used to locate the end of the signature. A placeholder is hereby defined as a single 0x00 byte.

A placeholder is used to denote that a particular signature is absent and not needed. (For example, an '''(A AND B) OR C''' transaction, where only C is provided, would have two placeholders in the list to represent A and B.) Any time the evaluation script attempts to check a placeholder, no computational resources are expended on EC operations, but instead, a 0 is immediately pushed to the top of the evaluation stack.

Success of the evaluation script is denoted by a 1 at the top of the private evaluation stack. Once the evaluation script is completed and control returns to the outer script, the contents of the evaluation stack are abandoned.

===Proposed opcodes to be supported in evaluation environment===
The following opcodes would be supported in an evaluation environment. They would not necessarily need to be enabled in the environment of regular script processing (and in fact ought not to be). Thus, they have been prefixed as EVALOP_ instead of OP_, to show they are different, even if the same constants are chosen to represent these as the corresponding OP_ version.

* EVALOP_CHECKSIGU (opcode strictly defined as 0x04) - Check a single uncompressed ECDSA signature. The U stands for uncompressed. The next 64 bytes are the X and Y coordinates of the public key, and one signature is pulled from the signature list. Push 1 or 0 on the stack to denote success or failure.
* EVALOP_NOP
* EVALOP_INVERT - turn a 1 on top of the eval stack to a 0 and vice versa.
* EVALOP_AND - pop two items off eval stack, if both 1 then push 1, else push 0.
* EVALOP_OR - pop two items off eval stack, if either 1 then push 1, else push 0.
* EVALOP_ADD - pop two items off eval stack, push sum.
* EVALOP_DUP - duplicate top item on stack.
* Comparison operators (equality, less than, greater than, etc.)
* Ability to push constants 0-75 (with the exception of the repurposed opcode 0x04, which must be handled via a replacement opcode or via EVALOP_PUSHDATA1)

In addition,
* Operations expecting a 1 or 0 on the top of the stack shall cause transaction failure if the stack does not contain these elements or if they are not 1 or 0.
* Operations shall be explicitly defined as unsigned 32-bit arithmetic, with overflows explicitly defined as causing transaction failure.
* Note that none of the operations defined thus far involve stack operations involving anything other than scalar 32-bit unsigned integers (assuming "true" and "false" are denoted as 1 and 0). Notably, there is no defined need for objects such as blobs of bytes or big integers, as all of these are provided as explicit parameters to the EVALOP_CHECKSIGU operation. In the absence of a well-articulated need to utilize any other data type in this limited evaluation context, it is advisable to limit the functionality of the ''evaluation stack'' such that it only holds 32-bit unsigned integers.

===Examples of use cases===

All of these use cases assume the standard transaction format which is recited as follows, but modified such that pubKeyHash is called pubKeyExHash (public key expression hash), and pubKey is called pubKeyEx (public key expression).

Sending funds: OP_DUP OP_HASH160 <pubKeyExHash> OP_EQUALVERIFY OP_CHECKSIGEX
Redeeming funds: <sigs> <pubKeyEx>

A standard transaction as is known now. This transaction leaves the evaluation environment with a 1 on the top of the evaluation stack, resulting in OP_CHECKSIGEX returning true.

<sigs> - contains a single signature.
<pubKeyEx> - contains a single public key, i.e. 0x04 + xy i.e. EVALOP_CHECKSIGU + xy

A two party, A and B transaction.

<sigs> - contains two signatures, binary concatenated together
<pubKeyEx> contains: EVALOP_CHECKSIGU + x1y1 + EVALOP_CHECKSIGU + x2y2 + EVALOP_AND

An (A AND B) OR C, redeemed using signatures A and B

<sigs> - contains two signatures and one placeholder
<pubKeyEx> contains: EVALOP_CHECKSIGU + x1y1 + EVALOP_CHECKSIGU + x2y2 + EVALOP_AND + EVALOP_CHECKSIGU + x3y3 + EVALOP_OR

An (A AND B) OR C, redeemed using only signature C

<sigs> - contains two placeholders and one signature
<pubKeyEx> contains: EVALOP_CHECKSIGU + x1y1 + EVALOP_CHECKSIGU + x2y2 + EVALOP_AND + EVALOP_CHECKSIGU + x3y3 + EVALOP_OR

An m-of-n transaction, requiring (for example) 5 out of 10 signatures

<sigs> - contains 10 items, a combination of signatures and placeholders
<pubKeyEx> contains: EVALOP_CHECKSIGU + x1y1 +
9 repetitions of: EVALOP_CHECKSIGU + xnyn + EVALOP_ADD +
(constant 5) + EVALOP_GREATERTHANOREQUAL

==Backwards Compatibility==

New transactions are non-standard to old implementations. But old implementations will generate transactions that are fully compatible with the new format. Sending Bitcoins to multisignature addresses as defined in this proposal will not break old clients, but redeeming them will. Regardless, old implementations will be rendered incompatible once such extended transactions appear on the network.

Old implementations would fail gracefully as they built their own fork of the chain that continued to include regular transaction but would omit multisig spends as well as respends of those same coins. Old clients would see and record Bitcoins paid to multisig addresses normally (since the transactions are standard and look just like non-multisig transactions), but would not be able to see those Bitcoins ever come back from multisig addresses to regular ones. The most likely failure mode an old client would see is an inability to see received Bitcoins from a new client if those coins had participated in a previous multisig transaction.

Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").

A suggested implementation is to program the client such that the functionality is enabled only on Testnet, and on the main Bitcoin network once a certain level of voting consensus has been established into the block chain. So long as the functionality is disabled, OP_CHECKSIG shall succeed so long as the expected parameters of one single signature and one single private key are provided.

==Avoiding Turing completeness surprises==
In order to minimize the possibility of a later discovery that the proposal resulted in the accidental implementation of a Turing complete script engine, the following details are recommended and/or required for implementers.

The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.

The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure (which terminates script processing) or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success).

==Notes==
This was once informally proposed by Casascius.

As it was understood by Casascius, the proposal was informally rejected, mainly on the notion that it would be silly or unclean to have a script interpreter of one type embedded within a script interpreter of another type.

This proposal is being reintroduced as a BIP simply because, due to heightened concern regarding Turing completeness surprises - where a script may be able to modify its own behavior - having separate partitioned storage
and operations for two different types of script content may be seen as a viable answer to the concern. The partitioning, of course, referring to the main script - which has access to control flow operations (if/then/else), as well as the ability
to modify scripts run in the "evaluation context" and then that separate
"evaluation" context - consisting solely of code that has access to nothing beyond its own private data, the signature validation function, and basic arithmetic options.

It is believed that implementation of this BIP would be relatively easy, with changes to code being confined strictly to the addition of a single new loop that runs with in the OP_CHECKSIG[EX] portion of the script interpreter.

[[Category:BIP|D]]

MtGox/API

2011-11-17T08:13:55Z

Dooglus: I'm able to use the API without specifying username or password, so this is clearly incorrect.

The [[MtGox]] API provides various methods to access different informations from the market, place orders, and more.

Two APIs are available at this point: the HTTP api (available by posting to mtgox.com/code/*) and the websocket API.

==Number Formats==

In the "old API", currency- and amount-values (price, volume,...) were given as '''float'''. These values are likely being deprecated and replaced by fields of the same name with "_int" as suffix. These are '''fixed-decimal''', so you have to move the decimal point yourself (divide). The exponent differs based on the kind of the value.

In order to convert the '''int''' to a '''decimal''' you can...

{| class="wikitable"
|-
! kind of field !! ...divide by !! ...multiply by
|-
| BTC (volume, amount) || 1E8 (10,000,000) || 0.00000001
|-
| USD (price) || 1E5 (100,000) || 0.00001
|-
| JPY (price) || 1E3 (1,000) || 0.001
|}

Implementation advice: it's probably best to use '''int''' or '''Decimal''' (if your language/db offers such a type) in your clients. Using '''float''' will likely lead to nasty rounding problems.

== currency symbols ==
List of the Currency symbols you can use with the API :

USD, AUD, CAD, CHF, CNY, DKK, EUR, GBP, HKD, JPY, NZD, PLN, RUB, SEK, SGD, THB

== HTTP API ==
This API is available in <nowiki>https://mtgox.com/api/*</nowiki>, and provides various informations. It also supports making an order, a withdraw, a deposit, etc. There is also a [https://rubygems.org/gems/mtgox Ruby gem] and [[Finance::MtGox|Perl module]] for interacting with the HTTP API.

=== Authentication ===

Authentication is performed by signing each request using HMAC-SHA512. The request must contain an extra value "nonce" which must be an always incrementing numeric value. A reference implementation is provided here:
<source lang="php">
<?php

function mtgox_query($path, array $req = array()) {
// API settings
$key = '';
$secret = '';

// generate a nonce as microtime, with as-string handling to avoid problems with 32bits systems
$mt = explode(' ', microtime());
$req['nonce'] = $mt[1].substr($mt[0], 2, 6);

// generate the POST data string
$post_data = http_build_query($req, '', '&');

// generate the extra headers
$headers = array(
'Rest-Key: '.$key,
'Rest-Sign: '.base64_encode(hash_hmac('sha512', $post_data, base64_decode($secret), true)),
);

// our curl handle (initialize if required)
static $ch = null;
if (is_null($ch)) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MtGox PHP client; '.php_uname('s').'; PHP/'.phpversion().')');
}
curl_setopt($ch, CURLOPT_URL, 'https://mtgox.com/api/'.$path);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

// run the query
$res = curl_exec($ch);
if ($res === false) throw new Exception('Could not get reply: '.curl_error($ch));
$dec = json_decode($res, true);
if (!$dec) throw new Exception('Invalid data received, please make sure connection is working and requested API exists');
return $dec;
}

// example 1: get infos about the account, plus the list of rights we have access to
var_dump(mtgox_query('0/info.php'));

// old api (get funds)
var_dump(mtgox_query('0/getFunds.php'));

// trade example
// var_dump(mtgox_query('0/buyBTC.php', array('amount' => 1, 'price' => 15)));
</source>

Python version here: https://bitcointalk.org/index.php?topic=49789.msg592388#msg592388

=== Cache ===

All of the API methods below have cached results, ticker, depth . . . have a 10 seconds cache .
No need to poll more often, you wont have more results, you could just be blocked by the prolexic anti ddos features.

=== Methods API version 0===

==== 0/data/getTrades.php ====
This allows retrieving all trades which happened in the last 24 hours. The returned data is cached and may not reflect latest activity.

Parameters:
* since: Passing a tid in "since" allows retrieving all trades since that trade. The passed id is may not exist. Ie. to get all trades from the very beginning one would just call https://mtgox.com/code/data/getTrades.php?since=0 . since returns only 100 trades, and you can call the method again by passing the latest trade you have imported in since.

* data is returned in standard json format like :
<source lang="php">
[
{"date":1279408157,
"price":"0.04951",
"amount":"20",
"price_int":"4951",
"amount_int":"2000000000",
"tid":"1",
"price_currency":"USD",
"item":"BTC",
"trade_type":""
"primary":"Y"
},
{"date":1279424586,"price":"0.05941","amount":"50.01","price_int":"5941","amount_int":"5001000000","tid":"2","price_currency":"USD","item":"BTC","trade_type":""}]
</source>

==== 0/getDepth.php ====
Get the current Market depth

https://mtgox.com/api/0/data/getDepth.php?Currency=PLN

https://mtgox.com/api/0/data/getDepth.php?Currency=AUD

https://mtgox.com/api/0/data/getDepth.php?Currency=USD

==== 0/getFunds.php ====
Get your current balance

https://mtgox.com/api/0/getFunds.php

getfunds is now deprecated since multi currency, please use info.php

==== 0/buyBTC.php ====
Place an order to Buy BTC

https://mtgox.com/api/0/buyBTC.php

POST data: amount=#&price=#&Currency=PLN

returns a list of your open orders

you can omit the price to do a market order

==== 0/sellBTC.php ====
Place an order to Sell BTC

https://mtgox.com/api/0/sellBTC.php

POST data: &amount=#&price=#&Currency=PLN

returns a list of your open orders

you can omit the price to do a market order

==== 0/getOrders.php ====
Fetch a list of your open Orders

https://mtgox.com/api/0/getOrders.php

oid: Order ID

type: 1 for sell order or 2 for buy order

status: 1 for active, 2 for not enough funds

==== 0/cancelOrder.php ====
Cancel an order

https://mtgox.com/api/0/cancelOrder.php

POST data: oid=#&type=#

oid: Order ID

type: 1 for sell order or 2 for buy order

==== 0/redeemCode.php ====
Used to redeem a mtgox coupon code

https://mtgox.com/api/0/redeemCode.php

* call with a post parameter "code" containing the code to redeem

* it will return an array with amount (float amount value of code), currency (3 letters, BTC or USD), reference (the transaction id), and status

==== 0/withdraw.php ====
withdraw / Send BTC

https://mtgox.com/api/0/withdraw.php

POST data: group1=BTC&btca=bitcoin_address_to_send_to&amount=#

* pass btca parameter to withdraw to a btc adress

* pass group1 for a coupon : BTC2CODE or USD2CODE

* pass group1=DWUSD for a dwolla withdraw

* pass green=1 to use the new greenaddress feature ( see [[GreenAddress]] )
* return code and status if successful

To make a withdraw in another Currency , use group1=USD2CODE and add a Currency parameter ( example Currency=EUR to get a mtgox EUR coupon )

==== 0/btcAddress.php ====
get a bitcoin deposit adress for your account

https://mtgox.com/api/0/btcAddress.php

* pass POST data "description" to add a description that will appear in your history when this BTC address receive a deposit

* returns a bitcoin deposit address

==== 0/history_[CUR].csv ====

Allows downloading your activity history for a given currency (BTC or USD for now).

https://mtgox.com/api/0/history_BTC.csv

https://mtgox.com/api/0/history_USD.csv

==== 0/info.php ====

https://mtgox.com/api/0/info.php

returns info about your account, funds, fees, API privileges . . .

==== 0/ticker ====

http://mtgox.com/api/0/data/ticker.php

returns the current ticker :

<source lang="php">
{"ticker":
{
"high":5.70653,
"low":5.4145,
"avg":5.561388723,
"vwap":5.610932845,
"vol":55698,
"last":5.56915,
"buy":5.51326,
"sell":5.5672
}
}
</source>

the time frame for high, low, vol, avg, vwap . . . is sliding 24 hours

what is vwap ?

please see http://en.wikipedia.org/wiki/VWAP

=== API version 0 examples ===

==== all api shell type CLI ====

python : http://www.goxsh.info/

perl : http://pastebin.com/vEpgw5nW

==== other ====

https : http://stackoverflow.com/questions/7046370/https-request-with-boost-asio-and-openssl

https://github.com/sje397/mtgox-plasmoid

module perl : http://search.cpan.org/~mndrix/Finance-MtGox-0.02/

==== gather data ====

https://github.com/Lexiks/MyBitBoard

==== gettrade ====

bash : https://bitcointalk.org/index.php?topic=39402.0

perl : http://pastebin.com/raw.php?i=pmhMXZJu

==== ticker ====

http://pastebin.com/pd0ZR4WY

=== Methods API version 1===

==== Multi Currency Ticker ====

https://mtgox.com/api/1/BTCUSD/public/ticker
https://mtgox.com/api/1/BTCEUR/public/ticker

returns the current ticker for the selected currency :

<source lang="php">
{
"result":"success",
"return":
{
"high": {"value":"5.70653","value_int":"570653","display":"$5.70653","currency":"USD"},
"low": {"value":"5.4145","value_int":"541450","display":"$5.41450","currency":"USD"},
"avg": {"value":"5.561119626","value_int":"556112","display":"$5.56112","currency":"USD"},
"vwap": {"value":"5.610480461","value_int":"561048","display":"$5.61048","currency":"USD"},
"vol":
{
"value":"55829.58960346",
"value_int":"5582958960346",
"display":"55,829.58960346\u00a0BTC",
"currency":"BTC"
},
"last_local":{"value":"5.5594","value_int":"555940","display":"$5.55940","currency":"USD"},
"last_orig":{"value":"5.5594","value_int":"555940","display":"$5.55940","currency":"USD"},
"last":{"value":"5.5594","value_int":"555940","display":"$5.55940","currency":"USD"},
"buy":{"value":"5.53587","value_int":"553587","display":"$5.53587","currency":"USD"},
"sell":{"value":"5.56031","value_int":"556031","display":"$5.56031","currency":"USD"}
}
</source>

note : last_local include only the last trade in the selected currency, last_orig include data of the original last trade ( currency,price in currency . . . ),last can be a conversion of the last trde in another currency

==== Multi Currency depth ====

https://mtgox.com/api/1/BTCPLN/public/depth?raw

https://mtgox.com/api/1/BTCAUD/public/depth?raw

==== Multi currency trades ====

https://mtgox.com/api/1/BTCPLN/public/trades?raw

https://mtgox.com/api/1/BTCAUD/public/trades?raw

to get only the trades since a given trade id, you can add the parameter since=<trade_id>

https://mtgox.com/api/1/BTCUSD/public/trades?since=0

https://mtgox.com/api/1/BTCEUR/public/trades?since=1316312781670700

For multi currency,also returns the primary value,"Y" or "N", the primary currency is always the buyers currency

A trade can appear in more than one currency, to ignore duplicates, use only the trades having primary =Y

example of returned data :
<source lang="php">
{"date":1316312781,
"price":"3.5599",
"amount":"3.6900096",
"price_int":"355990",
"amount_int":"369000960",
"tid":"1316312781670700",
"price_currency":"EUR",
"item":"BTC",
"trade_type":"bid",
"primary":"Y",
"properties":"limit,mixed_currency"
}
</source>

==== Cancelled Trades ====

https://mtgox.com/api/1/BTCUSD/public/cancelledtrades

returns a list of all the cancelled trades this last month, list of trade ids in json format .

==== Full Depth ====

https://mtgox.com/api/1/BTCUSD/public/fulldepth

returns full depth

== Websocket API ==
ported on 7/10/2011 from http://forum.bitcoin.org/index.php?topic=5855.0

===Connecting===

You can connect via: ws://websocket.mtgox.com/mtgox

The WebSocket protocol version used is that described in [http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00 draft-ietf-hybi-thewebsocketprotocol-00] (aka draft-00).

===Channels===

The websocket will subscribe you to some channels automatically:

{| class="wikitable"
|-
! Channel ID !! Description
|-
| dbf1dee9-4f2e-4a08-8cb7-748919a71b21 || trades (each time a trade happens, you get something here)
|-
| d5f06780-30a8-4a48-a2f8-7ed181b4a13f || the mtgox ticker (lots of updates, with often the same data)
|-
| 24e67e0d-1cad-4cc0-9e7a-f8523ef460fe || depth information in realtime (price + amount + type... type=1=Ask, type=2=Bid)
|}

Additionally each user has a "own" channel which streams informations about orders (new order, deleted order, etc) and trades only the user's trades).

Each message is a JSON-encoded object, with at least "op" element. The "op" element contains the operation to be done (for outgoing messages), or the type of message (for incoming messages).

===Possible outgoing commands===

'''unsubscribe''' Stop receiving messages from a channel (parameter "channel")

===Incoming Data===

====Ticker====
<source lang="javascript">
{
"channel":"d5f06780-30a8-4a48-a2f8-7ed181b4a13f",
"op":"private",
"origin":"broadcast",
"private":"ticker",
"ticker":{
"buy":0.9515,
"high":1,
"low":0.91,
"sell":0.9697,
"vol":34349
}
}
</source>

'''ticker''' contains the following:

{| class="wikitable"
|-
! Name !! Value
|-
| buy || highest bid as float
|-
| sell || lowest ask as float
|-
| high || maximum rate since last close as float
|-
| low || minimum rate since last close as float
|-
| vol || traded volume since last close
|}

====Trade====

<source lang="javascript">{
"channel":"dbf1dee9-4f2e-4a08-8cb7-748919a71b21",
"op":"private",
"origin":"broadcast",
"private":"trade",
"trade":{
"amount":2.71,
"amount_int":"271000000",
"date":1310279340,
"item":"BTC",
"price":14.43,
"price_currency":"USD",
"price_int":"1443000",
"tid":"1310279340877902",
"trade_type":"bid",
"type":"trade"
}
}
</source>

'''trade''' contains the following:

{| class="wikitable"
|-
! Name !! Value
|-
| amount || the traded amount in item (BTC), float, deprecated
|-
| amount_int || the traded amount * 1E8
|-
| date || unix timestamp of trade
|-
| item || What was this trade about
|-
| price || price per unit, float, deprecated
|-
| price_int || price in smallest unit as integer (5 decimals of USD, 3 in case of JPY)
|-
| price_currency || currency in which trade was completed
|-
| tid || Trade id (big integer, which is in fact trade timestamp in microseconds)
|-
| trade_type || Did this trade result from the execution of a bid or a ask?
|-
|}

====Depth====

Changes to the market depth data are broadcast so an up-to-date market depth can be kept by clients.

<source lang="javascript">{
"channel":"24e67e0d-1cad-4cc0-9e7a-f8523ef460fe",
"depth":{
"currency":"USD",
"item":"BTC",
"price":"14.43",
"price_int":"1443000",
"type":1,
"type_str":"ask",
"volume":"-2.71",
"volume_int":"-271000000"
},
"op":"private",
"origin":"broadcast",
"private":"depth"
}</source>

'''depth''' contains the following:

:{| class="wikitable"
|-
! Name !! Value
|-
| currency || the currency affected
|-
| item || the item (BTC)
|-
| price || price as a float, deprecated
|-
| price_int || the price at which volume change happened (5 decimal for USD, 3 for JPY)
|-
| type || 1=ask, 2=bid. deprecated, use type_str
|-
| type_str || type of order at this depth, either "ask" or "bid"
|-
| volume || the volume change as float, deprecated
|-
| volume_int || volume change * 1E8

|}

=== examples ===

==== ticker ====
javascript, using hookio :

http://www.youtube.com/watch?v=KD5ljtNK72U

http://github.com/hookio

http://github.com/cronopio/hook.io-mtgox

Another node.js project, using plain websockets (largely based on cronopio's work) :

https://github.com/dlanod/node-mtgox-websocket-client

==== arbitrage ====
https://github.com/goteppo/ArBit

==== websocket ====
https://github.com/cronopio/hook.io-ws

https://github.com/dlanod/node-mtgox-websocket-client

Help:Accounts explained

2011-11-08T10:04:34Z

Dooglus: 'sendfrom' won't overdraw default account; 'sendtoaddress' may

== Introduction ==

You can have different [[address|addresses]] in order to receive payments. Think of addresses as multiple postboxes around the outside of your house. Bitcoin allows accounts too. Each account owns a bunch of addresses. Taking our earlier analogy, you can imagine separate accounts as different houses. You (Bitcoin user) receive all the mail (balance shown in Bitcoin). Mail goes to a postbox (address) at one of your houses (accounts).

The balance you see displayed is a total from all your accounts.

== Accounts ==

Bitcoin version 0.3.18 and later implements several RPC methods to maintain separate account balances in a single Bitcoin wallet. The accounts feature makes it easy to create web services that maintain a separate bitcoin balance for each customer.

== Account Names ==

Accounts are named with arbitrary strings; you may use any [http://www.json.org/ JSON] string other than "*" (JSON strings are sent and returned as UTF-8 encoded Unicode).

Bitcoin creates two accounts automatically: it implicitly creates a default account with the empty string as its name, and it explicitly creates an account named '''Your Address''' when a new wallet is created.

== The Default Account ==

The default account is named with the empty string ("" in JSON). Generated coins are always credited to the default account, and the ''sendtoaddress'' method always debits the default account.

== Accounts and Receiving Addresses ==

Each account is associated with zero or more receiving addresses, and every receiving address is associated with exactly one account. Coins sent to a receiving address in the wallet are credited to the associated account.

Accounts are associated with receiving addresses by using the ''getaccountaddress'', ''getnewaddress'' or ''setaccount'' methods.

''getaccountaddress'' will return the same address until coins are received on that address; once coins have been received, it will generate and return a new address.

''getnewaddress'' always generates and returns a new address.

''setaccount'' changes the account associated with an existing address. Coins previously received on that address (if any) will be debited from the previous account's balance and credited to the address' new account. Note that doing so may make the previous account's balance negative.

Use the ''getaddressesbyaccount'' method to list all addresses associated with an account.

== Sending ==

The ''sendfrom'' method sends coins and debits the specified account. It does **not** change Bitcoin's algorithm for selecting which coins in the wallet are sent-- you should think of the coins in the wallet as being mixed together when they are received. There is no way to ask Bitcoin to "create a payment transaction using the coins received from these previously received transactions."

The ''sendtoaddress'' method works like ''sendfrom'', but always debits the default account.

The send will fail if the account has insufficient funds, with two exceptions:

- 'sendtoaddress' always succeeds if there are sufficient funds in the
server's wallet. For example, if your wallet account balances were 100 BTC in account
'foo' and 0 BTC in the default account, then the balances after ''sendtoaddress
15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC 10.00'' would be 100 in account 'foo' and -10.00 in
the default account (and the overall server balance would go from 100 to 90 BTC). On
the other hand, using 'sendfrom' to send from the default account with a zero balance
will fail with message "Account has insufficient funds".

- The check for sufficient funds is done before paying transaction fees (if any); if a
[[transaction fee]] is needed, and there are sufficient funds in the wallet, then the
transaction fee will be paid and debited from the account. For example, if account
'foo' contains 10 bitcoins, you ''sendfrom foo 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC 10'',
and the transaction costs 0.01, 'foo's balance will be -0.01 bitcoins.

== Account -> Account Transfers ==

Use the ''move'' method to transfer balances from one account to another. Moves from the default account to any other account always succeed; moves from any other account will fail if the account has insufficient funds. Moves are not broadcast to the network, and never incur transaction fees; they just adjust account balances in the wallet.

== Account Balance and History==

The ''getbalance'' method returns the bitcoin balance for either the entire wallet (if no argument is given) or for a particular account.

The ''listtransactions <account> [N]'' method returns the last N (default 10) transactions that affected the account's balance. "listtransactions '*' [N]" will return the last N transactions for all accounts.

== Typical Uses ==

This section describes how typical web site code running on a web server uses the JSON-RPC API to keep track of customers' accounts.
* Customer '''creates an account''' on the website: web server either assigns them a unique customer id number or uses their email address or other unique identifier, calls ''getaccountaddress "userid"'' and tells the customer to send to that address to fund their account.
* Customer '''receives coins''' to fund their account: web server isn't involved.
* Customer is shown their '''current balance''': ''getbalance "userid" 6'' to get their 'confirmed' balance, and subtracts it from ''getbalance "userid" 0'' to get their 'unconfirmed' balance.
* Show the customer an **itemized list** of transactions: ''listtransactions "userid"''
* Customer '''sends coins''' to another bitcoin address: ''sendfrom "userid" <address> <amount>''
* Customer '''transfers coins''' to another customer: ''move "userid1" "userid2" <amount>''
* You '''make a sale''', paid for with bitcoins in the customer's account: ''move "userid" "" <amount> 6 "purchased item"'', and if it succeeds, send them the product.
* Customer is '''charged a fee''' for use of the service: ''move "userid" "FEES" <amount>'' (using special accounts like "FEES" can make your application's logic much simpler)
* Customer '''purchases bitcoins''' from you: ''move "AVAILABLE" "userid" <amount>'' (assuming the bitcoins you are selling are kept track of in an "AVAILABLE" account)

[[Category:Technical]]
[[Category:Developer]]

Difficulty

2011-10-07T00:58:50Z

Dooglus: typo

''See also: [[target]]''

=== What is "difficulty"? ===

Difficulty is a measure of how difficult it is to find a new [[block]] compared to the easiest it can ever be.

=== How often does the difficulty change? ===

Every 2016 [[block|blocks]].

=== What is the formula for difficulty? ===

difficulty = maximum_target / current_target

(target is a 256 bit number)

===How is difficulty stored in blocks?===

Each block stores a packed representation (called "Bits") for its actual hexadecimal [[target]]. The target can be derived from it via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

So the difficulty at 0x1b0404cb is therefore:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983

Here;s a fast way to calculate difficulty. It uses a modified taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:

<source lang="cpp">
#include <iostream>
#include <cmath>

inline float fast_log(float val)
{
int * const exp_ptr = reinterpret_cast <int *>(&val);
int x = *exp_ptr;
const int log_2 = ((x >> 23) & 255) - 128;
x &= ~(255 << 23);
x += 127 << 23;
*exp_ptr = x;

val = ((-1.0f/3) * val + 2) * val - 2.0f/3;
return ((val + log_2) * 0.69314718f);
}

float difficulty(unsigned int bits)
{
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));
}

int main()
{
std::cout << difficulty(0x1b0404cb) << std::endl;
return 0;
}
</source>

Unfortunately I don't have much use for it in libbitcoin. Maybe some miner will find it useful.

To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:

<source lang="python">
import decimal, math
l = math.log
e = math.e

print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)
</source>

=== What is the current difficulty? ===
[http://blockexplorer.com/q/getdifficulty Current difficulty], as output by BitCoin's getDifficulty.

[http://blockexplorer.com/q/estimate Estimated next difficulty]

[http://bitcoin.sipa.be Graphs]

=== What is the maximum difficulty? ===

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)

=== Can the difficulty go down? ===
Yes it can. See discussion in [[target]].

=== What is the minimum difficulty? ===
The minimum difficulty, when the target is at the maximum allowed value, is 1.

=== What network hash rate results in a given difficulty? ===
The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is
0xffff * 2**208
and for difficulty D is
(0xffff * 2**208)/D

The expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208)
or just
D * 2**48 / 0xffff

The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was
D * 2**48 / 0xffff / 600
over the previous 2016 blocks. Can be further simplified to
D * 2**32 / 600
without much loss of accuracy.

At difficulty 1, that is around 7 Mhashes per second.

At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.

=== How soon might I expect to generate a block? ===
(The [https://www.bitcointalk.org/index.php?topic=1682.0 eternal question].)

The average time to find a block can be approximated by calculating:
time = difficulty * 2**32 / hashrate
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.

For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"
23.85
and find that it takes just under 24 hours on average.

* Any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts your hardware can make per second.
* You need to know the difficulty (above) and your khash/sec rate (reported by the client).
** [[Mining Hardware Comparison]] has some stats that may help you predict what you could get.
* Visit a calculator or perform the maths yourself,
** http://www.alloscomp.com/bitcoin/calculator.php
* Remember it's just probability! There are no guarantees you will win every N days.

==Related Links==

* [http://btcserv.net/bitcoin/history/ Bitcoin Difficulty History]

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

[[pl:Trudność]]

Help:FAQ

2011-08-09T18:59:23Z

Dooglus: /* Do I need to configure my firewall to run bitcoin? */ link testnet

Here you will find answers to the most commonly asked questions.

== General ==
=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).
A Bitcoin isn't tangible. It is just a number associated with a [[Address|Bitcoin Address]]. See also an [[Introduction|easy intro]] to bitcoin.

=== How can I get Bitcoins? ===

There are a variety of ways to acquire Bitcoins:

* Accept Bitcoins as payment for goods or services.
* There are several services where you can [[buying bitcoins|trade them]] for traditional currency.
* Find a local trader on [http://tradebitcoin.com tradebitcoin] (or somewhere else) and trade with him in cash.
* Create a new [[block]] (currently yields 50 Bitcoins).
* Participate in a [[Pooled mining|mining pool]].

=== Can I buy Bitcoins with Paypal? ===

While it's possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most major exchanges do not allow funding through Paypal. This is due to repeated cases where someone pays for Bitcoins with Paypal, receives their Bitcoins, and then fraudulently complains to Paypal that they never received their goods. Paypal too often sides with the fraudulent buyer in this case, and so exchangers no longer allow this method of funding.

Buying Bitcoins from individuals with this method is still possible, but requires mutual trust. In this case, Bitcoin seller beware.

=== Where can I find a forum of Bitcoin users? ===

There is no longer an "official" forum for Bitcoin. The [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] includes links to some forums.

=== How are new Bitcoins created? ===

[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[controlled inflation|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of coins will approach 21,000,000 BTC over time.

Blocks should be generated every 10 minutes, on average. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon in advance by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody creating a block is based on the calculation speed of the system that they are using compared to the aggregate calculation speed of all the other systems generating blocks on the network.

=== What's the current total number of Bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are Bitcoins? ===

Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises.

=== What do I call the various denominations of Bitcoins? ===

There is a lot of discussion about the naming of these fractions of Bitcoins. The leading candidates are:

* 1 BTC = 1 Bitcoin
* 0.01 BTC = 1 cBTC = 1 Centi-Bitcoin (also referred to as Bitcent)
* 0.001 BTC = 1 mBTC = 1 Milli-Bitcoin (also referred to as mbit (pronounced em-bit) or millibit)
* 0.000 001 BTC = 1 μBTC = 1 Micro-Bitcoin (also referred to as ubit (pronounced yu-bit) or microbit)

The above follows the accepted international SI units for thousandths, millionths and billionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged. This is a worldwide currency.

One exception is the "satoshi" which is smallest denomination currently possible

* 0.000 000 01 BTC = 1 Satoshi (pronounced sa-toh-shee)

which is so named in honour of Satoshi Nakamoto the pseudonym of the inventor of Bitcoin.

For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].

Further discussion on this topic can be found on the forums here:

* [http://forum.bitcoin.org/index.php?topic=14438.msg195287#msg195287 We need names]
* [http://forum.bitcoin.org/index.php?topic=8282.0 What to call 0.001 BTC]

=== How does the halving work when the number gets really small? ===

The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created.

The calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by 2 and rounded down. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.

Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.

=== How long will it take to generate all the coins? ===

The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999.

=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===

Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").

The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.

=== If every transaction is broadcast via the network, does BitCoin scale? ===
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.

With some modifications to the software, full BitCoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a couple of racks of machines using todays hardware). It's worth noting that the MasterCard network is structured somewhat like BitCoin itself - as a peer to peer broadcast network.

Learn more about [[Scalability]].

==Economy==
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===
Bitcoins have value because they are accepted as payment by many. See the [[Trade|list of Bitcoin-accepting sites]].

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants – a price tag is a promise to exchange goods for a specified amount of currency.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.

=== What if someone bought up all the existing Bitcoins? ===
What if somebody bought up all the gold in the world? Well, by attempting to buy it all, the buyer would just drive the prices up until he runs out of money.

Not all Bitcoins are for sale. Just as with gold, no one can buy a Bitcoin that isn't available for sale.

=== Won't Bitcoin's deflationary tendencies cause a deflationary spiral? ===
See the article [[Deflationary spiral]].

=== Doesn't Bitcoin unfairly benefit early adopters? ===
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.

In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.

=== Is Bitcoin a Ponzi scheme? ===
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.

A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters profit from the usefulness of a stable and widely accepted p2p currency.

The fact that early adopters benefit more doesn't alone make anything a ponzi scheme. Apple stocks aren't ponzi even though the early investors got rich.

=== Is Bitcoin a bubble? ===
Yes, in the same way as the euro and dollar are. They only have value in exchange and no value in use. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.

==Sending and Receiving Payments==

=== Why do I have to wait 10 minutes before I can spend money I received? ===

10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case.

Blocks (shown as "confirmations" in the GUI) are how the BitCoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!

Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. If that made no sense to you, don't worry. Reading [http://www.bitcoin.org/bitcoin.pdf the technical paper] should make things clearer.

=== Do you have to wait 10 minutes in order to buy or sell things with BitCoin? ===

No, it's reasonable to sell things without waiting for a confirmation as long as the transaction is not of high value.

When people ask this question they are usually thinking about applications like supermarkets or snack machines, as discussed in [http://www.bitcoin.org/smf/index.php?topic=423.msg3819#msg3819 this thread from July 2010]. Zero confirmation transactions still show up in the GUI, but you cannot spend them. You can however reason about the risk involved in assuming you ''will'' be able to spend them in future. In general, selling things that are fairly cheap (like snacks, digital downloads etc) for zero confirmations will not pose a problem if you are running a well connected node.

=== I sent some bitcoins and they haven't arrived yet! Where are they? ===

Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. First of all, check the current max block count by going [http://blockexplorer.com/q/getblockcount here] and comparing that to the number in the bottom right hand corner of your client. If these numbers are different by more than 1 or 2 then you need to wait for your block chain to download. If not, then it's possible that your transaction hasn't been included in a block yet. You can check pending transactions in the network by going [http://bitcoincharts.com/bitcoin/ here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. Bear in mind that if the transaction is based on a coin that was in a recent transaction then it will take longer to transfer e.g. someone just sent you a coin, if you send that again, it will take a while to transfer unless you put a large (0.01) fee on it. Transactions with 0 fees might take hours or days to be included in a block.

=== Why does my Bitcoin address keep changing? ===

Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.

===How much will the transaction fee be?===

Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.

The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.

Because the fee is related to the amount of data that makes up the transaction and not to the amount of bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (e.g., as small payments from a mining pool) then fees when sending will be higher than if your activity follows a more normal consumer or business transaction pattern.

==Networking==
=== Do I need to configure my firewall to run bitcoin? ===

Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. Bitcoin will also try to connect to IRC (tcp port 6667) to meet other nodes to connect to. [[Testnet]] uses tcp port 18333 instead of 8333.

If you want to restrict your firewall rules to a few ips and/or don't want to allow IRC connection, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]]. If your provider blocks the common IRC ports, note that lfnet also listens on port 7777. Connecting to this alternate port currently requires either recompiling Bitcoin, or changing routing rules. For example, on Linux you can evade a port 6667 block by doing something like this:

echo 173.246.103.92 irc.lfnet.org >> /etc/hosts
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"

=== How does the peer finding mechanism work? ===
Bitcoin finds peers primarily by connecting to an IRC server (channel #bitcoin on irc.lfnet.org). If a connection to the IRC server cannot be established (like when connecting through TOR), an in-built node list will be used and the nodes will be queried for more node addresses.

==Mining==
===What is mining?===
Mining is the process of spending computation power to find valid blocks and thus create new Bitcoins.

Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets 50 newly generated Bitcoins. If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.

===Why was the "Generate coin" option of the client software removed?===

In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of mining is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.

===Is mining used for some useful computation?===
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.

===Is it not a waste of energy?===
Spending energy on creating a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.

===Why don't we use calculations that are also useful for some other purpose?===
To provide security for the Bitcoin network, the calculations involved need to have some very specific features. These features are incompatible with leveraging the computation for other purposes.

===How does the proof-of-work system help secure Bitcoin?===
To give a general idea of the mining process, imagine this setup:

payload = <some data related to things happening on the Bitcoin network>
nonce = 1
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )

The work performed by a miner consists of repeatedly increasing "nonce" until
the hash function yields a value, that has the rare property of being below a certain
target threshold. (In other words: The hash "starts with a certain number of zeroes",
if you display it in the fixed-length representation, that is typically used.)

As can be seen, the mining process doesn't compute anything special. It merely
tries to find a number (also referred to as nonce) which - in combination with the payload -
results in a hash with special properties.

The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given
the payload and a specific nonce, only a single call of the hashing function
is needed to verify that the hash has the required properties. Since there is no
known way to find these hashes other than brute force, this can be used as a "proof of work"
that someone invested a lot of computing power to find the correct nonce for this payload.

This feature is then used in the Bitcoin network to secure various aspects. An attacker
that wants to introduce malicious payload data into the network, will need to do the
required proof of work before it will be accepted. And as long as honest miners have more
computing power, they can always outpace an attacker.

Also see [http://en.wikipedia.org/wiki/SHA2 SHA2] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] on Wikipedia.

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works

==See Also==

* [[Man page]]
* [[Introduction]]

[[de:FAQ]]
[[zh-cn:FAQ]]
[[fr:FAQ]]

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

Help:FAQ

2011-08-09T18:58:35Z

Dooglus: /* Do I need to configure my firewall to run bitcoin? */ show testnet port

Here you will find answers to the most commonly asked questions.

== General ==
=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”).
A Bitcoin isn't tangible. It is just a number associated with a [[Address|Bitcoin Address]]. See also an [[Introduction|easy intro]] to bitcoin.

=== How can I get Bitcoins? ===

There are a variety of ways to acquire Bitcoins:

* Accept Bitcoins as payment for goods or services.
* There are several services where you can [[buying bitcoins|trade them]] for traditional currency.
* Find a local trader on [http://tradebitcoin.com tradebitcoin] (or somewhere else) and trade with him in cash.
* Create a new [[block]] (currently yields 50 Bitcoins).
* Participate in a [[Pooled mining|mining pool]].

=== Can I buy Bitcoins with Paypal? ===

While it's possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most major exchanges do not allow funding through Paypal. This is due to repeated cases where someone pays for Bitcoins with Paypal, receives their Bitcoins, and then fraudulently complains to Paypal that they never received their goods. Paypal too often sides with the fraudulent buyer in this case, and so exchangers no longer allow this method of funding.

Buying Bitcoins from individuals with this method is still possible, but requires mutual trust. In this case, Bitcoin seller beware.

=== Where can I find a forum of Bitcoin users? ===

There is no longer an "official" forum for Bitcoin. The [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] includes links to some forums.

=== How are new Bitcoins created? ===

[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[controlled inflation|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of coins will approach 21,000,000 BTC over time.

Blocks should be generated every 10 minutes, on average. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon in advance by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody creating a block is based on the calculation speed of the system that they are using compared to the aggregate calculation speed of all the other systems generating blocks on the network.

=== What's the current total number of Bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are Bitcoins? ===

Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises.

=== What do I call the various denominations of Bitcoins? ===

There is a lot of discussion about the naming of these fractions of Bitcoins. The leading candidates are:

* 1 BTC = 1 Bitcoin
* 0.01 BTC = 1 cBTC = 1 Centi-Bitcoin (also referred to as Bitcent)
* 0.001 BTC = 1 mBTC = 1 Milli-Bitcoin (also referred to as mbit (pronounced em-bit) or millibit)
* 0.000 001 BTC = 1 μBTC = 1 Micro-Bitcoin (also referred to as ubit (pronounced yu-bit) or microbit)

The above follows the accepted international SI units for thousandths, millionths and billionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged. This is a worldwide currency.

One exception is the "satoshi" which is smallest denomination currently possible

* 0.000 000 01 BTC = 1 Satoshi (pronounced sa-toh-shee)

which is so named in honour of Satoshi Nakamoto the pseudonym of the inventor of Bitcoin.

For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].

Further discussion on this topic can be found on the forums here:

* [http://forum.bitcoin.org/index.php?topic=14438.msg195287#msg195287 We need names]
* [http://forum.bitcoin.org/index.php?topic=8282.0 What to call 0.001 BTC]

=== How does the halving work when the number gets really small? ===

The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created.

The calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by 2 and rounded down. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.

Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.

=== How long will it take to generate all the coins? ===

The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999.

=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===

Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").

The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.

=== If every transaction is broadcast via the network, does BitCoin scale? ===
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.

With some modifications to the software, full BitCoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a couple of racks of machines using todays hardware). It's worth noting that the MasterCard network is structured somewhat like BitCoin itself - as a peer to peer broadcast network.

Learn more about [[Scalability]].

==Economy==
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===
Bitcoins have value because they are accepted as payment by many. See the [[Trade|list of Bitcoin-accepting sites]].

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants – a price tag is a promise to exchange goods for a specified amount of currency.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.

=== What if someone bought up all the existing Bitcoins? ===
What if somebody bought up all the gold in the world? Well, by attempting to buy it all, the buyer would just drive the prices up until he runs out of money.

Not all Bitcoins are for sale. Just as with gold, no one can buy a Bitcoin that isn't available for sale.

=== Won't Bitcoin's deflationary tendencies cause a deflationary spiral? ===
See the article [[Deflationary spiral]].

=== Doesn't Bitcoin unfairly benefit early adopters? ===
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.

In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.

=== Is Bitcoin a Ponzi scheme? ===
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.

A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters profit from the usefulness of a stable and widely accepted p2p currency.

The fact that early adopters benefit more doesn't alone make anything a ponzi scheme. Apple stocks aren't ponzi even though the early investors got rich.

=== Is Bitcoin a bubble? ===
Yes, in the same way as the euro and dollar are. They only have value in exchange and no value in use. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.

==Sending and Receiving Payments==

=== Why do I have to wait 10 minutes before I can spend money I received? ===

10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case.

Blocks (shown as "confirmations" in the GUI) are how the BitCoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!

Why ten minutes specifically? It is a tradeoff chosen by Satoshi between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. If that made no sense to you, don't worry. Reading [http://www.bitcoin.org/bitcoin.pdf the technical paper] should make things clearer.

=== Do you have to wait 10 minutes in order to buy or sell things with BitCoin? ===

No, it's reasonable to sell things without waiting for a confirmation as long as the transaction is not of high value.

When people ask this question they are usually thinking about applications like supermarkets or snack machines, as discussed in [http://www.bitcoin.org/smf/index.php?topic=423.msg3819#msg3819 this thread from July 2010]. Zero confirmation transactions still show up in the GUI, but you cannot spend them. You can however reason about the risk involved in assuming you ''will'' be able to spend them in future. In general, selling things that are fairly cheap (like snacks, digital downloads etc) for zero confirmations will not pose a problem if you are running a well connected node.

=== I sent some bitcoins and they haven't arrived yet! Where are they? ===

Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. First of all, check the current max block count by going [http://blockexplorer.com/q/getblockcount here] and comparing that to the number in the bottom right hand corner of your client. If these numbers are different by more than 1 or 2 then you need to wait for your block chain to download. If not, then it's possible that your transaction hasn't been included in a block yet. You can check pending transactions in the network by going [http://bitcoincharts.com/bitcoin/ here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. Bear in mind that if the transaction is based on a coin that was in a recent transaction then it will take longer to transfer e.g. someone just sent you a coin, if you send that again, it will take a while to transfer unless you put a large (0.01) fee on it. Transactions with 0 fees might take hours or days to be included in a block.

=== Why does my Bitcoin address keep changing? ===

Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.

===How much will the transaction fee be?===

Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.

The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.

Because the fee is related to the amount of data that makes up the transaction and not to the amount of bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (e.g., as small payments from a mining pool) then fees when sending will be higher than if your activity follows a more normal consumer or business transaction pattern.

==Networking==
=== Do I need to configure my firewall to run bitcoin? ===

Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. Bitcoin will also try to connect to IRC (tcp port 6667) to meet other nodes to connect to. Testnet uses tcp port 18333 instead of 8333.

If you want to restrict your firewall rules to a few ips and/or don't want to allow IRC connection, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]]. If your provider blocks the common IRC ports, note that lfnet also listens on port 7777. Connecting to this alternate port currently requires either recompiling Bitcoin, or changing routing rules. For example, on Linux you can evade a port 6667 block by doing something like this:

echo 173.246.103.92 irc.lfnet.org >> /etc/hosts
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"

=== How does the peer finding mechanism work? ===
Bitcoin finds peers primarily by connecting to an IRC server (channel #bitcoin on irc.lfnet.org). If a connection to the IRC server cannot be established (like when connecting through TOR), an in-built node list will be used and the nodes will be queried for more node addresses.

==Mining==
===What is mining?===
Mining is the process of spending computation power to find valid blocks and thus create new Bitcoins.

Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets 50 newly generated Bitcoins. If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.

===Why was the "Generate coin" option of the client software removed?===

In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of mining is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.

===Is mining used for some useful computation?===
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.

===Is it not a waste of energy?===
Spending energy on creating a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.

===Why don't we use calculations that are also useful for some other purpose?===
To provide security for the Bitcoin network, the calculations involved need to have some very specific features. These features are incompatible with leveraging the computation for other purposes.

===How does the proof-of-work system help secure Bitcoin?===
To give a general idea of the mining process, imagine this setup:

payload = <some data related to things happening on the Bitcoin network>
nonce = 1
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )

The work performed by a miner consists of repeatedly increasing "nonce" until
the hash function yields a value, that has the rare property of being below a certain
target threshold. (In other words: The hash "starts with a certain number of zeroes",
if you display it in the fixed-length representation, that is typically used.)

As can be seen, the mining process doesn't compute anything special. It merely
tries to find a number (also referred to as nonce) which - in combination with the payload -
results in a hash with special properties.

The advantage of using such a mechanism consists of the fact, that it is very easy to check a result: Given
the payload and a specific nonce, only a single call of the hashing function
is needed to verify that the hash has the required properties. Since there is no
known way to find these hashes other than brute force, this can be used as a "proof of work"
that someone invested a lot of computing power to find the correct nonce for this payload.

This feature is then used in the Bitcoin network to secure various aspects. An attacker
that wants to introduce malicious payload data into the network, will need to do the
required proof of work before it will be accepted. And as long as honest miners have more
computing power, they can always outpace an attacker.

Also see [http://en.wikipedia.org/wiki/SHA2 SHA2] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] on Wikipedia.

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works

==See Also==

* [[Man page]]
* [[Introduction]]

[[de:FAQ]]
[[zh-cn:FAQ]]
[[fr:FAQ]]

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

Miner fees

2011-07-01T00:57:30Z

Dooglus: /* Technical info */ confirm priority threshold

[[File:fee.png|thumb|Receiving a transaction fee of 0.44 BC]]
Transaction fees may be included with any transfer of bitcoins from one address to another. At the moment, many [[transactions]] are typically processed in a way where no fee is expected at all, but for transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected.

The transaction fee is processed by and received by the bitcoin miner. When a new bitcoin block is generated with a successful hash, the information for all of the transactions is included with the block and all transaction fees are collected by that user creating the block, who is free to assign those fees to himself.

Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction. On the other hand, nobody mining new bitcoins necessarily needs to accept the transactions and include them in the new block being created. The transaction fee is therefore an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated.

It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.

It works like this:
* Whoever sends the transaction is often able to guess an appropriate fee based on their own fee rules. The [[Original Bitcoin client|original client]] will always assess the transaction, and if a fee will typically be expected, it will not allow you to send the transaction without the calculated fee.
* The user is prompted to confirm the fee before the transaction is sent.
* The sender makes a transaction with more coins in the ''In'' portion than the ''Out'' portion so that there are “leftovers” not assigned to any address.
* Whoever ends up publishing the [[block]] which contains this transaction will take these (and any other) leftover coins. They are included with their normal generated coins and is an extra bonus for creating the block.
* If a generating node receives a transaction that should include a transaction fee but doesn't, they may refuse to include it in their blocks. It might be included in a later block if someone is willing to accept it. Generators can't force a certain fee on transactions -- they can only accept or reject the transaction's “fee offer”.
[[File:lfm_fee.png|thumb|This balance is made entirely of 0.01 BTC cents. Since sending them requires a lot of data, a very large fee is required.]]

Different bitcoin clients and different versions have different rules for determining which transactions to accept and how large of a fee to send.

Current default rules for the original Bitcoin client (Bitcoin 0.3.20)
* 0.01 BTC fee if sending any transaction less than 0.01 BTC. This is to help prevent DoS attacks against the network. Remember: fees are not network-enforced, so it's still ''possible'' to send these small transactions without the fee -- you just have to generate the blocks that contain them yourself (after modifying Bitcoin).
* 0.01 BTC fee per kilobyte of transaction, but:
** If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
** If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
* Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.
* If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.

Note that if you want to send a transaction with less than the default rules, or if you are a miner and want to include them in your blocks, you may need to peer with the [[Free transaction relay policy|Free transaction relay network]].

An advantage for bitcoin users to include a transaction fee is that the likelihood of getting a transaction included into the next block is going to be higher than if a transaction fee is not included. This is a trade off of time vs. money put forward on the transaction fees, as you can be patient with a low or non-existent fee included in a transaction, or you can make sure that the transaction is processed immediately by including a higher fee than is typical.

The rules are far from set in stone, and the network can support many different rules simultaneously. If there are 10 generating nodes that never require a transaction fee and your client is modified to never send any transaction fee, then your transactions will eventually be picked up by one of those free nodes when they generate a block, though it will probably take a very long time. In the far future, different rules about transaction fees among generating nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours.

As an example, clients that have block generation turned off don't know what the current blocksize is, and will therefore never pay a fee on transactions under 10 kilobytes. If you notice that your sent transactions take a very long time to accrue confirmations, this is possibly the cause. If this happens a lot (probably because the network is under attack), run Bitcoin with the -paytxfee switch: -paytxfee=0.01 will force a minimum fee of 0.01 per kilobyte for all sent transactions, which will prioritize your transactions over all free transactions.
[[File:feesend.png|thumb|Sending a transaction when the sender doesn't have enough money to actually pay the fee]]

ArtForz, who makes up a large percentage of the network's CPU power, never charged transaction fees (even for micro-transactions) for a period of several months.

==Technical info==

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

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

==See Also==

* [[Free transaction relay policy]]

[[Category:Technical]]
[[Category:Vocabulary]]
[[Category:Mining]]

Satoshi Nakamoto

2011-02-01T13:52:44Z

Dooglus: /* Possible Motives */ formatting

[[File:Satoshi-nakamoto.gif|thumb|200px|right|Picture of Satoshi Nakamoto.]]

'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial author of the [[Original Bitcoin client]]. He has said in a p2p foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much is known about him. He has been working on Bitcoin for more than two years.<ref> [http://www.bitcoin.org/smf/index.php?topic=453.msg4068#msg4068]</ref>

==Possible Motives==

He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".

Some interesting quotes:
<blockquote>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of
freedom for several years.

Governments are good at cutting off the heads of a centrally controlled
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be
holding their own. [http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html]</blockquote>

<blockquote>It's very attractive to the libertarian viewpoint if we can explain it
properly. I'm better with code than with words though. [http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html]</blockquote>

==Possible identity==

His identity and/or nationality are in doubt. While the few bits of information available<ref name="p2p_f_profile"/> about him point to Japan, he never wrote a single line of Japanese, the Bitcoin client has no Japanese version and there is no Japanese page on [http://bitcoin.org bitcoin.org].

He is entirely unknown outside of Bitcoin as far as anyone can tell, and his PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason".

==External links==
* [http://www.bitcoin.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]
* [http://sourceforge.net/users/s_nakamoto SourceForge page]

==Notes==
<references/>
[[Category:Bitcoiners]]

Difficulty

2011-01-28T22:30:45Z

Dooglus: /* How soon might I expect to generate a block? */ show maths for estimating time to find a block

Difficulty

2011-01-28T20:29:26Z

Dooglus: show how to calculate network hashing rate from current difficulty

Buying bitcoins

2011-01-19T07:44:45Z

Dooglus: /* Small amounts */ spelling

One issue currently facing a newcomer to bitcoin is, how do I get some? While there is the [[bitcoin faucet]] that can get you started with a small fraction of a coin, when getting larger amounts the user faces an abundance of choice. This page will cut through the clutter, and help direct you to the right exchanger for your needs.

==Large amounts==

For large amounts of bitcoin (USD 1000 or more), you probably would get the best rate if you deposit funds via bank wire, ACH, Euro bank transfer, or via [[Liberty Reserve]] into a major exchange. The following exchanges are currently available that take currency deposits:

* [[MtGox]]
* [[Bitcoin Central]]
* Other [[:Category:Exchanges|Exchanges]]

==Small amounts==

For smaller amounts, bank transfer fees or Liberty Reserve conversion fees are usually too expensive. Thus other methods are usually a better choice. The following exchanges will enable you to acquire smaller amounts of bitcoin at reasonable rates:

* [[CoinPal]] accepts [[PayPal]] for purchases of small lots of bitcoin.
* [[Bitcoin 4 cash|Bitcoin 4 Cash]] will sell you bitcoins in exchange for cash in the mail.
* [[Bitcoin Morpheus]] will sell you bitcoins in exchange for cash in the mail.
* [[bitcoin-otc]] IRC trading marketplace will usually have people willing to deal for small and larger amounts using various payment methods, including PayPal, [[Dwolla]], Linden Dollars, etc.

==eWallet==

Some [[:Category:Services|services]] hold your bitcoins in an [[eWallet]] and provide funding methods.

* [[YouTipIt]] Add funds with PayPal.

[[Category:Exchanges]]
[[Category:Introduction]]

Block chain

2011-01-19T07:42:51Z

Dooglus: spelling

[[File:blockchain.png|thumb|Blocks in the main chain (black) are the longest series of blocks that go from the genesis block (green) to the current block. Orphan blocks (purple) are blocks that are not in the longest chain.]]

Every [[block]] contains a [[hash]] of the previous block. This has the effect of creating a chain of blocks from the [[genesis block]] to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. The blocks thus form a history of the bitcoin state, with which address each bitcoin was assigned at a given time, it is not possible to change the contents of any block without invalidating the successive blocks (because its hash would change).

Each block contains a [[Proof-of-work]] that protects the block chain. Generators will build on the valid chain that contains the most work (blocks don't necessarily contain the same amount of work).

When two blocks are generated referencing the same previous block the block chain forks. This can happen for a number of reasons. If two blocks are generated simultaneously, the one that is built on by the next block will form the future chain. More serious forks can occur in a bug is found in the client which allows an invalid block chain to form, the chain will be recognised as invalid by future versions. As long as such invalid chains are recognized as such by at least 50% of computation power, the old block chain will be abandoned when more work has been put into the new one. Malicious clients attempting to fork the block chain (and thus alter transaction history) will not succeed unless they can perform work faster than normal clients (this is very unlikely).

Blocks in shorter chains (or invalid chains) are called "orphan blocks", and while they are stored, they are not used for anything. When a block becomes an orphan block, all of its valid transactions are re-added to the pool of queued transactions and will be included in another block. The 50 BTC reward for the orphan block will be lost, which is why a network-enforced 100-block maturation time for generations exists.

Because a block can only reference one previous block, it is impossible for two forked chains to merge.

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

Bitcoin symbol

2011-01-19T07:41:20Z

Dooglus: grammer, capitalisation

There is no official Bitcoin symbol as of December 2010, however the ''BTC'' abbreviation is the most universally accepted form.

== Unicode symbol ==

There is a discussion over [http://www.bitcoin.org/smf/index.php?topic=369.0 which Unicode symbol might be the best suited] for bitcoin.

It has lead to the following options:

* ฿
** Pro: Gives a currency-like look (it is the symbol for an existing currency, the Thai Baht, but other currency symbols often get reused, like the $); displayed correctly on all known OSes
** Cons: It is already a currency, and might confuse people
* ☃
** Cons: Wait, what?
* Ⓑ ⓑ
** Cons: Does not display properly for everyone
* ᴃ
* ␢
* β
* ¤
* Ƅ
* ∄
* ℬ
* ઘ
** Cons: No visible relation to Bitcoin
* ϭ
** Cons: No visible relation to Bitcoin
* [[Image:Bitcoin Symbol Suggestion circled struck-through B.png|20px]]
** Cons: Does not exist in the Unicode standard
* [[Image:Bitcoin Symbol Suggestion rotated power.png|20px]]
** Cons: Does not exist in the Unicode standard
* ⓢ