Bitcoin Wiki - User contributions [en]

P2Pool

2014-06-16T11:46:29Z

Burrito: /* External Links */ forgot close brak

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[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 30 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 and avoids the risk of hard to detect theft by pool operators.

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 average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

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 (= 24 hours of shares), 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 25BTC) 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 ===

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: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''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.8.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
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man"<br />
'''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?"<br />
'''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 95% confidence).

'''Q:''' "What do I do if my efficiency is low?"<br />
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. 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. 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. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS?<br />
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?!<br />
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?!<br />
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects?<br />
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block?<br />
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now!<br />
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees?<br />
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated?<br />
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?<br />
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain?<br />
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work?<br />
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* 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.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== 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-seamless 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 bitcoin
-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
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /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
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR: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 0.11.1-8-ged9359d)

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/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
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>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Cointerra Terraminer IV (very low stale rate, maybe the lowest of any mining asic)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

== 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 pool 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://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

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://127.0.0.1:9332/patron_sendmany/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.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==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
* [http://p2pool.info/ p2pool.info] stats page (appears broken since May 2014 and as of June 2014 - you can use http://ANY.NODE:9332/static/graphs.html )
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2014-06-16T11:45:35Z

Burrito: /* External Links */ oops, nowiki tags didn't work.

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[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 30 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 and avoids the risk of hard to detect theft by pool operators.

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 average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

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 (= 24 hours of shares), 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 25BTC) 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 ===

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: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''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.8.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
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man"<br />
'''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?"<br />
'''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 95% confidence).

'''Q:''' "What do I do if my efficiency is low?"<br />
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. 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. 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. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS?<br />
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?!<br />
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?!<br />
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects?<br />
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block?<br />
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now!<br />
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees?<br />
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated?<br />
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?<br />
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain?<br />
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work?<br />
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* 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.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== 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-seamless 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 bitcoin
-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
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /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
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR: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 0.11.1-8-ged9359d)

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/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
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>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Cointerra Terraminer IV (very low stale rate, maybe the lowest of any mining asic)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

== 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 pool 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://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

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://127.0.0.1:9332/patron_sendmany/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.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==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
* [http://p2pool.info/ p2pool.info] stats page (appears broken since May 2014 and as of June 2014 - you can use http://ANY.NODE:9332/static/graphs.html
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2014-06-16T11:44:52Z

Burrito: /* External Links */ Note the brokenness of p2pool.info - state alternative (using any p2pool node's graphs)

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[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 30 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 and avoids the risk of hard to detect theft by pool operators.

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 average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

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 (= 24 hours of shares), 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 25BTC) 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 ===

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: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''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.8.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
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man"<br />
'''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?"<br />
'''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 95% confidence).

'''Q:''' "What do I do if my efficiency is low?"<br />
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. 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. 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. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS?<br />
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?!<br />
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?!<br />
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects?<br />
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block?<br />
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now!<br />
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees?<br />
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated?<br />
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?<br />
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain?<br />
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work?<br />
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* 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.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== 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-seamless 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 bitcoin
-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
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /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
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR: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 0.11.1-8-ged9359d)

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/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
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>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Cointerra Terraminer IV (very low stale rate, maybe the lowest of any mining asic)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

== 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 pool 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://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

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://127.0.0.1:9332/patron_sendmany/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.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==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
* [http://p2pool.info/ p2pool.info] stats page (appears broken since May 2014 and as of June 2014 - you can use <nowki>http://ANY.NODE:9332/static/graphs.html</nowiki>
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]

P2Pool

2014-06-16T11:42:57Z

Burrito: /* External Links */ Add another public list of P2Pool nodes

Links: http://p2pool.in/ - https://github.com/forrestv/p2pool - https://en.bitcoin.it/wiki/P2Pool - https://bitcointalk.org/index.php?topic=18313

[[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 30 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 and avoids the risk of hard to detect theft by pool operators.

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 average returns above 100% of the expected reward.
However, it should be noted that there are other pools (such as [[BitPenny]] and [[Eligius]]) which can provide this same level of decentralization.

== 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 thirty seconds, just as Bitcoin regulates it to generate one block every ten minutes.
This means that finding shares becomes more difficult (resulting in higher variance) the more people mine on P2Pool, though large miners have the option to raise their difficulty, and so reduce the impact of their mining on P2Pool's minimum difficulty.

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 (= 24 hours of shares), 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 25BTC) 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 ===

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: edit bitcoin.conf to include:
rpcuser=USER
rpcpassword=LONG_RANDOM_SECRET_VALUE
server=1
**'''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.8.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
** bfgminer -O u:p -o http://127.0.0.1:9332/ --submit-stales

Dependencies if running from source:
* Python 2.6 or higher (but not 3.x)
* python-argparse
* Twisted (Ubuntu package python-twisted)

=== Frequently Asked Questions ===

'''Q:''' "Why does my miner report so many longpoll events when mining on p2pool? - P4Man"<br />
'''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?"<br />
'''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 95% confidence).

'''Q:''' "What do I do if my efficiency is low?"<br />
'''A:''' Make sure the computers you're running P2Pool and the miner on have enough memory and CPU time. 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. 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. Decrease the load on your internet connection or enable QoS (Quality of Service) on your router.

'''Q:''' What is PPLNS?<br />
'''A:''' Pay-Per-Last-N-Shares is a payout method that is completely resistant to pool hoppers.

'''Q:''' Why am I not getting very many shares?!<br />
'''A:''' The P2Pool difficulty is hundreds of times higher than on other pools. It can take time to get a share. P2Pool displays an estimate of how long you have to wait in the console output.

'''Q:''' Why does my miner say it has found a lot of shares but p2pool say I have only found a few?!<br />
'''A:''' The real P2Pool difficulty is hundreds of times higher than on normal pools, but p2pool essentially lies to your miner and tells it to work on relatively easy shares so that it submits shares every few seconds instead of every few hours. P2Pool then ignores any submitted shares that don't match the real share difficulty. By doing this, P2Pool can more accurately report your local hash rate and you can see if you are having problems with too many stale shares quickly

'''Q:''' Why am I getting so many rejects?<br />
'''A:''' You're using an incompatible miner. See the miners section here, increase your FPS on the miner, decrease the intensity, upgrade your miner, or try a different miner.

'''Q:''' What stops the pool operator or the block finder from stealing a block?<br />
'''A:''' A block solution is only worth anything because its hash matches Bitcoin's target. Altering anything within the block will change its hash and make it worthless. If you are concerned about the pool operator stealing a block, you should try to inspect the source code of each new version.

'''Q:''' Why does it say "Generated?" I want to spend my coins now!<br />
'''A:''' P2Pool includes payouts in generation transactions, which must mature (taking 120 blocks or 20 hours) before they can be spent. The reason for this is that a block could be orphaned, which would make its payout invalid and could reverse transactions.

'''Q:''' Do I get paid transaction fees?<br />
'''A:''' Yes. They are split among P2Pool miners.

'''Q:''' What are these payments I'm getting that aren't generated?<br />
'''A:''' These are subsidies that people who support the idea of P2Pool send to miners.

'''Q:''' Cool Subsidies sound like an awesome idea! How do I send some BTC to these awesome miners?<br />
'''A:''' See end of this page.

'''Q:''' Do I really need the WHOLE blockchain?<br />
'''A:''' Yes. Your node needs to be able to independently make decisions about what transactions to mine.

'''Q:''' How do merged mining payments work?<br />
'''A:''' Merged mining is handled entirely by namecoind, so you're solo mining and payouts will go into namecoind's wallet.

=== 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 bfgminer?) helps a lot with reducing stales.

* bfgminer, cgminer, and ufasoft work perfectly without any extra options.
* 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.

====Tips to configure bfgminer to reduce stale/doa:====
* "gpu-threads" : "1", (2 by default)
* "queue" : "0", (1 by default)

Because of fast longpooling in p2pool it is better not NOT fetch work ahead.

On non-dedicated machines intensity=3 allows normal usage of PC, set it to 7 or more to get full hashrate.

On most cards best is diablo and phatk kernel, looks like poclbm kernel have unstable rate.

=== 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-seamless 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 bitcoin
-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
* Appending "/1000" to a miner's username will increase the difficulty of producing a P2Pool share to at most 1000. This is useful to large miners because doing this can make it easier for small miners while minimally impacting the large miners themselves. See [https://bitcointalk.org/index.php?topic=18313.msg816322#msg816322 recommended values].
** Appending "+1" (for example) after that will make P2Pool always give your miners work with a difficulty of 1

=== Web interface ===

Lots of data and useful tools are available at http://127.0.0.1:9332/something:
* /static/ - Lots of information from shares to graphs to payouts.
* /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
* /web/log - Some different stats collected over the last day

=== Included README ===
<pre>Requirements:
Generic:
Bitcoin >=0.6.0rc4 or Bitcoin >=0.5.4 (for BIP16 support) or Litecoin
Python
Twisted
python-argparse (for Python <=2.6)

Linux:
sudo apt-get install python-zope.interface python-twisted python-twisted-web
sudo apt-get install python-argparse # if on Python 2.6 or older

Windows:
Install Python 2.7: http://www.python.org/getit/
Install Twisted: http://twistedmatrix.com/trac/wiki/Downloads
Install Zope.Interface: http://pypi.python.org/pypi/zope.interface/3.8.0
Unzip the files into C:\Python27\Lib\site-packages

Running P2Pool:
To use P2Pool, you must be running your own local bitcoind. For standard
configurations, using P2Pool should be as simple as:

python run_p2pool.py

Then run your miner program, connecting to 127.0.0.1 on port 9332 with any
username and password.

If you are behind a NAT, you should enable TCP port forwarding on your
router. Forward port 9333 to the host running P2Pool.

Run "python run_p2pool.py --help" for additional options.

Notes for Litecoin:
Requirements:
In order to run P2Pool with the Litecoin network, you would need to build and install the
ltc_scrypt module that includes the scrypt proof of work code that Litecoin uses for hashes.

Linux:
cd litecoin_scrypt
sudo python setup.py install

Windows:
Install MinGW: http://www.mingw.org/wiki/Getting_Started
Install Python 2.7: http://www.python.org/getit/

cd litecoin_scrypt
C:\Python27\python.exe setup.py build --compile=mingw32 install

If you run into an error with unrecognized command line option '-mno-cygwin', see this:
http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-o

Running P2Pool:
Run P2Pool with the "--net litecoin" option.
Run your miner program, connecting to 127.0.0.1 on port 9327.
Forward port 9338 to the host running P2Pool.

Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
the Bitcoin network. To avoid problems, add these lines to litecoin.conf
and restart litecoind:
rpcport=10332
port=10333
</pre>

=== Option Reference ===
<pre>
usage: run_p2pool.py [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[-w PORT or ADDR: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 0.11.1-8-ged9359d)

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/)
--give-author DONATION_PERCENTAGE
donate this percentage of work towards the development
of p2pool (default: 0.5)
--iocp use Windows IOCP API in order to avoid errors due to
large number of sockets being open
--irc-announce announce any blocks found on
irc://irc.freenode.net/#p2pool
--no-bugreport disable submitting caught exceptions to the author
--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
--max-conns CONNS maximum incoming connections (default: 40)

worker interface:
-w PORT or ADDR:PORT, --worker-port PORT or ADDR:PORT
listen on PORT on interface with ADDR for RPC
connections from miners (default: all interfaces,
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>

== Interoperability table ==
P2pool works fine with most hardware. This lists some of the hardware confirmed to work and any special configuration required.

* ASICminer blade 10GH/s (Requires adding +1 to username or proxy)
* Avalon 110nm 60-110 GH/s (All batches)
* Avalon based 55nm 200 GH/s (specific makers?)
* Avalon prototype 55nm 120GH/s (~ 20 exist)
* Cointerra Terraminer IV (very low stale rate, maybe the lowest of any mining asic)
* Icarus FPGA
* Bitfury strikes back H-card and M-card ([https://bitcointalk.org/index.php?topic=18313.msg4424081#msg4424081 instructions])
* Bitmain Antminer S1 180GH/s ([https://github.com/AntMiner/AntGen1/tree/master/firmware Requires 20131226 firmware.])
* BFL SC Jalapeno, SC Single 30, 50, & 60 GH/s

(Various GPU and most FPGAs other than BFL single FPGAs work fine too)

== 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 pool 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://127.0.0.1:9332/patron_sendmany/10)"
</pre>

You can replace "" with "accountname" if you want to pay from some specific bitcoind account, and you need to replace 127.0.0.1 with the address of your P2Pool node if you're not running one locally.

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://127.0.0.1:9332/patron_sendmany/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.

==Sponsors==

Thanks to:

* The [https://bitcoinfoundation.org/ Bitcoin Foundation] for its generous support of P2Pool
* The [https://litecoin.org/ Litecoin Project] for its generous donations to P2Pool

==See Also==

* [[Comparison of mining pools]]
* [[Pooled Mining]]
* [[P2Pool code documentation]]

==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
* [http://p2pool.info/ p2pool.info] stats page
* [http://p2pool.hostv.pl p2pool.hostv.pl] Public list of P2Pool BTC/LTC nodes.
* [http://p2pool-nodes.info/ p2pool-nodes.info] Another public list of P2Pool (BTC) nodes.
* [http://whatisp2pool.com whatisp2pool.com] An easy introduction to mining and P2Pool.

==References==
<references />

[[Category:Pool Operators]]

Alerts mailing list

2014-06-07T22:03:43Z

Burrito: Guy who edited last (Name matches with Gary Mulder's email and he created the page), barring any malintent, implies official confirmation that this is no longer offered. Past tensing everything.

The Bitcoin [[Protocol specification]] supports the broadcast of [[Alerts]]. In the past, an unofficial email relay was provided that rebroadcasts these [[block chain]] related alerts. To subscribe via email send an email to '''bitcoin-unofficial-alerts+subscribe@googlegroups.com''' [mailto:bitcoin-unofficial-alerts+subscribe@googlegroups.com] and you should receive an email asking you to verify your subscription.

Alternatively, you can browse to the Google Group for the list [https://groups.google.com/forum/#!forum/bitcoin-unofficial-alerts]. By default Google Groups does not send emails, so when you sign up you will likely want to choose to get notifications via email.

==Verify alerts and obtain the latest status information==
If you receive an alert you should '''immediately verify it is official''' by running "bitcoind getinfo" (but see notes below), go to bitcoin.org [http://www.bitcoin.org] to obtain more details and background, or join the #bitcoin [[IRC channels]] on freenode to obtain the latest information.

==Notes==
*Alerts are broadcast to a specified range of Bitcoin versions.
*The email relay uses a specially patched version of bitcoind that should report and therefore relay ''any'' alert broadcast for ''any'' version.
*You will therefore have to verify whether or not the alert is actually relevant to your particular version of Bitcoin client.
*Alerts are also independent of blocks or transactions, and have a defined time-to-live.
*The email relay polls bitcoind every six minutes.

==Feedback==
Please send any comments or requests to Gary Mulder [mailto:flyingkiwiguy@gmail.com].

[[Category:Services]]
[[Category:Developer]]
[[Category:ECommerce]]
[[Category:Defunct products or services]]

Thin Client Security

2014-06-07T21:58:16Z

Burrito: s/blockchain/block chain/

Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.

== Block Height vs. Depth ==

It is important to distinguish between block height verification and block depth verification.

A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization|block chain reorganization]] producing a new longer fork which excludes the transaction (i.e. [[Orphan_Block|orphaning]] its block).

See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

== Full-Chain Clients ==

The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisions below.

=== Block '''Height''' as a Transaction Validity Check ===

A full-chain client trusts the [[Protocol_rules#Blocks well-formed|difficultywise-longest]] block chain it can find. Any transaction on the difficultywise-longest well-formed chain is considered valid. Therefore, the validity of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being invalidated due to the emergence of a longer fork.

==== [[bitcoind|bitcoin-qt]] ====

==== [https://github.com/conformal/btcd btcd] ====

== Header-Only Clients ==

These client downloads a complete copy of the headers for all blocks in the entire block chain. This means that the download and storage requirements scale linearly with the amount of time since bitcoin was invented; it would be preferable to have the scaling be logarithmic or even constant.

=== Simplified Payment Verification (SPV) ===

This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

==== Block '''Depth''' as a Transaction Validity Check ====

As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep in the chain does not have inputs which were already spent further back in the chain. Therefore, the validity of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.

This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. The thick client uses "X blocks deep" (aka "confirmations") only once it has already decided that a transaction is valid (i.e. no [[Double-spending|double-spends]]). At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.

It is very important to understand how the same property ("X blocks deep") is used to verify two different properties in the thick client and SPV cases. '''The thick client never uses block depth as a measure of transaction validity; the SPV client does'''.

This is a concern in a situation where an SPV client is subjected to a double-spend attack by somebody who controls its network connection. For example, suppose you are at a wi-fi cafe and are paying for something using your smartphone -- the cafe owner controls your network connection. Satoshi acknowledges this implicitly when he writes that "the verification is reliable as long as honest nodes control the network" -- to be completely pedantic, this means that the verification is reliable as long as honest nodes control '''the part of the network that the SPV client is able to communicate with'''. In an attack-by-ISP scenario this may not be a sufficiently strong security property. The attacker would not need to overpower "the rest of the network" because the client is unable to communicate with it.

==== [[BitCoinJ|bitcoinj]] ====

Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].

A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:

* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.

==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====

Simplified Payment Verification is the verification mechanism used in picocoin.

The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.

==== [[Electrum]] ====

ThomasV [https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&action=historysubmit&diff=42844&oldid=36519 claims] that "Electrum, it is doing SPV since 2012".

=== Unused Output Tree in the Block chain (UOT) ===

There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the block chain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate block chain compression] is a variant of this.

If such UOT hashes were included in the block chain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal block chain rules and additionally has an Unused Output Tree which is accurate and truthful". This is still a long way from the low level of trust involved in the thick client, but it is a major improvement over all existing proposals.

It is unlikely that bitcoin would ever arrive at a state where every single block had a UOT, since this would require upgrading 100% of the miners on the network, or else convincing enough miners to reject blocks which do not contain a UOT. The latter strategy risks creating block chain forks, which can be expensive (in reward terms) to miners. Therefore, any UOT strategy would need to cope with the fact that not every block contains a UOT.

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block well-formedness criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the block chain.

== Server-Trusting Clients ==

These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.

All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.

Clients with a checkpoint (even a very old one) that download and validate the headers for the whole block chain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.

=== [[BCCAPI]] ===

== Other ==

* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com
* The [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.

<references>

[[Category:Technical]]
[[category:Clients]]
[[Category:Security]]

Browser-based wallet

2014-06-07T20:59:14Z

Burrito: /* Things to be aware of */ Hint at client-side security difficulties

A '''browser-based wallet''' or '''wallet service''' is an online account with an external provider where bitcoins can be stored. Examples include accounts on currency exchange [[:Category:Markets|Markets]], online [[:Category:Services|Services]] and with ecommerce transaction processors. This definition also includes [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]].

<span style="color:red">Warning: When storing your bitcoins with a browser-based wallet on a third-party website, you are trusting that the operator will not abscond with your bitcoins, and that operator maintains secure systems that protect against theft, internal or external. It is recommended that you obtain the real-world identity of the website operator, ensure that sufficient recourse is available and avoid services that do not use an offline wallet ([[cold storage]]) for bitcoins that are not needed for daily transactions. Storing significant quantities of bitcoins on third party websites is not recommended.</span> (Note: some [[Browser-based_wallet#Hybrid_e-wallets|Hybrid e-wallets]] might be exempt from this warning, and adequately safe for storing large amount of Bitcoins. In any case, do your own homework and learn how each site operates).

==Benefits==
* Use of a browser-based wallet provider may help improve [[anonymity]] against third-parties who watch your IP address use.
* An account with a wallet service can generally be established in just minutes.
* Some bitcoin users store some or all of their bitcoins in a browser-based wallet to avoid having to worry about keeping a local wallet [[Securing_your_wallet|secure]].
* Since withdrawals can be made to any Bitcoin address, simply using the withdrawal feature to withdraw to an address that is not yours is functionally equivalent to sending a Bitcoin payment when running the Bitcoin client locally.
* Some services offer instant, internal transfers. This allows transactions to complete without having to wait for block confirmations.

==Things to be aware of==

When bitcoins are stored online, the provider retains full control of those amounts. You are trusting a third party to maintain your Bitcoin balance on your behalf. You would also need to trust the software implementation of the service, as well as your own browser. In comparison, if you run the Bitcoin software yourself, you are in full control of your coins so long as the wallet file stored on your computer is kept secret and secure.

Other relevant things:

* You typically have less anonymity with respect to those who run the online wallet site.
* If a payment is made from an online wallet, the last-sent-to [[address]] (often [https://iwilcox.me.uk/2014/no-from-address incorrectly called a 'from' address]) is an address for the wallet provider and not an address reserved specifically for the sender. This is because the wallet service provider may service the payment from any coins in its possession - your balance is not associated with any particular coins, any more than your balance at your local bank is associated with any specific bills. Thus if the recipient were to "return" any bitcoins to the last-sent-to address, the sender would not receive those bitcoins — but last-sent-to addresses are [https://iwilcox.me.uk/2014/no-from-address#assumptions completely unsuitable for that anyway].

* Not all wallet providers reserve a bitcoin address for the account holder indefinitely. Bitcoin addresses generally work best when one is assigned for each use. There is the risk of showing an address from a wallet provider in a directory or on a web page (for donations, as an example) as there is the possibility that at the future date when those bitcoins are sent that the intended recipient still has the wallet account. The same concern applies should the wallet provider cease operations.

* While there are ways for the wallet provider to [https://iwilcox.me.uk/2014/proving-bitcoin-reserves demonstrate that they operate with full reserves], the practice is not widespread and doesn't protect against security breaches or the owner suddenly absconding with all funds.

* Transactions to a Bitcoin address from the same wallet provider are usually completed internally and, if so, will not be processed on the Bitcoin P2P network. Auditing tools such as the [[Block Explorer]] will not show any activity for this transaction.
** Some wallet providers allow amounts below 0.01 BTC to be sent if the transaction is to another account holder on the same service. This allows an inexpensive and immediate method to detect if the recipient is using the same wallet provider.

* The wallet service provider's wallet may be vulnerable to security breaches, loss, or theft. Because Bitcoin transactions are irreversible, there may be limited or no recovery if a provider's master wallet is compromised. Wallet providers who implement preventative controls - such as keeping their reserves in an [[offline wallet]] - are likely to be safer.

==Hybrid e-wallets==

After several online bitcoin wallets were hacked, a second wave of online Bitcoin wallets entered the market. Hybrid wallets generally use Javascript in the user's browser to manage private keys and create payments.

These wallets differed from traditional online wallet services because the user actually owns the private keys inside their wallet. This approach has several advantages:

* The user can look up their account balance in the blockchain and which guarantees their account balance is correct.
* Users can easily export their private keys out of a wallet to use with another bitcoin client or wallet provider; if they take backups of the code and wallet data, this may even be possible if the provider disappears.
* The users' keys are stored encrypted on the server, offering some protection for security breaches if strongly encrypted.
* As each address has only one user, it's less likely that [https://iwilcox.me.uk/2014/no-from-address misguided attempts to "return" coins] to their last-sent-to address will result in loss of coins.

However, there are limits on what this model can achieve:

* A single server compromise or abuse of trust can still result in losses for many users if the site serves maliciously modified Javascript.
* Unless users make use of the backup/export facility, they're no less exposed to wallet data loss or confiscation by the provider.
* The user's browser still presents a relatively large attack surface for exploits.
* Facilities for obtaining entropy in the browser of a grade suitable for strong cryptography are currently poor, and custom entropy code almost never undergoes qualified review, so any keys or nonces created at the browser end may be weak.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]
* [[Bitcoin faucet]]
* List of [[:Category:HybridEWallets|HybridEWallets]]
* List of [[:Category:eWallets|eWallets]]

Help:Getting started

2014-06-07T20:55:45Z

Burrito: Link to the page about browser-based wallets. It contains lots of 'things to be aware of'.

<span style="color:red">WARNING: This wiki and the links it contains can be edited by anyone, always verify that the URL to the site you are visiting is correct. Before trusting or sending your bitcoins to any website you should always search on additional resources such as google, [https://bitcointa.lk bitcointalk forums] or [http://reddit.com/r/bitcoin reddit] to see what other users are saying about the service.</span>

* Get started buying bitcoins at [[Coinbase_(business)|Coinbase]] or [[Bitstamp]]
* Start by watching [http://weusecoins.com/ this 2 minute vid].
* Learn why it [http://bitcoin.stackexchange.com/questions/2834/what-are-the-perceived-advantages-of-bitcoin-as-a-store-of-value could be a good investment]
* Learn why it's objectively [http://bitcoin.stackexchange.com/questions/305/what-are-the-perceived-advantages-of-bitcoin-as-a-means-of-exchange better as a means of exchange].
* Get a [[Clients|client]] and try it out yourself.
* Use an [[Browser-based wallet|online wallet]] that you trust.
* Explore bitcoin with a [[:Category:Block chain browsers|block chain browser]] such as [https://www.blockchain.info Blockchain.info]
* [http://bitcoin.stackexchange.com/ Ask questions]
* [http://bitcoin.stackexchange.com/questions/118/how-much-bitcoin-will-i-mine-right-now-with-hardware-x Can I generate Free Money on my computer?] - TL;DR - Not really.
* [https://en.bitcoin.it/wiki/FAQ Read the FAQ]
* [[Buying Bitcoins (the noob version)|Where can I buy bitcoins?]] (Hint: [http://bitcoin.stackexchange.com/questions/2293/how-can-i-buy-bitcoin-via-a-credit-card-or-paypal You can't buy them with Paypal or credit cards])
* [http://bitcoinx.io/ Where to buy and store your bitcoins]

If you're looking for how to get started with Bitcoin-Qt, [[Getting started installing bitcoin-qt|this is the article you're looking for]].

==See Also==

* [[Introduction|Bitcoin Introduction]]
* [[Bonus_Programs|Bonus Programs]]
* [[Trade|Bitcoin Businesses]]

Testnet

2014-05-27T18:52:14Z

Burrito: Clarify more that testnet is separate and distinct

The '''testnet''' is an alternative Bitcoin [[block chain]], to be used for testing. Testnet coins are separate and distinct from actual bitcoins, and are never supposed to have any value. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.

Run bitcoin or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file).

There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. '''Testnet3''' is the current test network. It was introduced with the 0.7 release, introduced a third genesis block, a new rule to avoid the "difficulty was too high, is now too low, and transactions take too long to verify" problem, and contains blocks with edge-case transactions designed to test implementation compatibility.

==Differences==
* Default Bitcoin network protocol listen port is 18333 (instead of 8333)
* Default RPC connection port is 18332 (instead of 8332)
* Bootstrapping uses different DNS seeds.
* A different value of ADDRESSVERSION field ensures no testnet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)
* The protocol message header bytes are 0x0B110907 (instead of 0xF9BEB4D9)
* Minimum [[difficulty]] of 1.0 on testnet is equal to difficulty of 0.5 on mainnet. This means that the mainnet-equivalent of any testnet difficulty is half the testnet difficulty. In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value.
* A new genesis block
* The IsStandard() check is disabled so that non-standard transactions can be experimented with.

==Genesis Block==

Testnet uses a different genesis block to the main network. You can find it [https://www.biteasy.com/testnet/blocks/000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 here] or [http://blockexplorer.com/testnet/b/0 here].
The testnet was reset with a new genesis block for the 0.7 bitcoin release.

==External links==
* [https://bitcointalk.org/?topic=4483.0 Test Network forum topic]
* [http://faucet.xeno-genesis.com/ Mojocoin Testnet3 Faucet]
* [http://tpfaucet.appspot.com/ TP's TestNet Faucet]
* [http://faucet.luis.im/ luis.im Mojocoin Testnet3 Faucet]
* [http://testnet.btclook.com/ BTCLook Testnet Explorer]
* [https://www.biteasy.com/testnet/blocks Biteasy.com Testnet Blockexplorer]
* [http://pool.qdoop.net:18331/chain/Testnet3 Testnet3 ABE based Block Explorer]
* [http://blockexplorer.com/testnet Testnet Block Explorer]
* [https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ Testnet-In-A-Box self-contained testnet]
* [https://github.com/freewil/bitcoin-testnet-box Forked/Updated testnet-box]
* [http://tbtc.blockr.io/ Bitcoin Testnet on Blockr.io]

[[Category:Technical]]
[[Category:Developer]]

Protocol documentation

2014-05-26T14:46:22Z

Burrito: Found two (Github is great) not sure which one works. Adding both.

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Protocol documentation

2014-05-26T14:44:19Z

Burrito: remove mostly empty section linking to mostly empty article. Replace with external link to final page of interest.

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]
* [https://github.com/lbotsch/wireshark-bitcoin Bitcoin dissector for Wireshark]

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Protocol documentation

2014-05-26T14:36:55Z

Burrito: Better link

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

== Wireshark dissector ==
A [[Bitcoin Dissector|dissector]] for Wireshark is being developed.

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Protocol documentation

2014-05-26T14:32:01Z

Burrito: add to see-also section: * [https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs Developer Reference on bitcoin.org]

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

== Wireshark dissector ==
A [[Bitcoin Dissector|dissector]] for Wireshark is being developed.

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-reference#remote-procedure-calls-rpcs Developer Reference on bitcoin.org]

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Alerts mailing list

2014-05-18T00:58:14Z

Burrito: Did not automatically relay messages from earlier this year.

The Bitcoin [[Protocol specification]] supports the broadcast of [[Alerts]]. An unofficial email relay is now provided that rebroadcasts these [[block chain]] related alerts. To subscribe via email send an email to '''bitcoin-unofficial-alerts+subscribe@googlegroups.com''' [mailto:bitcoin-unofficial-alerts+subscribe@googlegroups.com] and you should receive an email asking you to verify your subscription.

Alternatively, you can browse to the Google Group for the list [https://groups.google.com/forum/#!forum/bitcoin-unofficial-alerts]. By default Google Groups does not send emails, so when you sign up you will likely want to choose to get notifications via email.

==Verify alerts and obtain the latest status information==
If you receive an alert you should '''immediately verify it is official''' by running "bitcoind getinfo" (but see notes below), go to bitcoin.org [http://www.bitcoin.org] to obtain more details and background, or join the #bitcoin [[IRC channels]] on freenode to obtain the latest information.

==Notes==
*Alerts are broadcast to a specified range of Bitcoin versions.
*The email relay uses a specially patched version of bitcoind that should report and therefore relay ''any'' alert broadcast for ''any'' version.
*You will therefore have to verify whether or not the alert is actually relevant to your particular version of Bitcoin client.
*Alerts are also independent of blocks or transactions, and have a defined time-to-live.
*The email relay polls bitcoind every six minutes.

==Feedback==
Please send any comments or requests to Gary Mulder [mailto:flyingkiwiguy@gmail.com].

[[Category:Services]]
[[Category:Developer]]
[[Category:ECommerce]]
[[Category:Defunct products or services]]

Protocol documentation

2014-05-17T18:39:24Z

Burrito: Little spelling corrections everywhere.

Sources:
* [[Original Bitcoin client]] source

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xfd || 1 || uint8_t
|-
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t
|-
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t
|-
| - || 9 || 0xff followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402)
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1 || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
3B 64 8D 5A - payload checksum

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - checksum of payload

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum payload length: 1.8 Megabytes or 50000 entries):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indices(int top_depth)
{
// Start at max_depth
std::vector<size_t> indices;
// Push last 10 indices first
size_t step = 1, start = 0;
for (int i = top_depth; i > 0; i -= step, ++start)
{
if (start >= 10)
step *= 2;
indices.push_back(i);
}
indices.push_back(0);
return indices;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''getdata''

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Always locked
|-
| < 500000000 || Block number at which this transaction is locked
|-
| >= 500000000 || UNIX timestamp at which this transaction is locked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - checksum of payload

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Block version information, based upon the software version creating this block
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [[BIP_0035|BIP 35]]. Since [[BIP_0037|BIP 37]], only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].

=== alert ===

An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

== Scripting ==

See [[script]].

== Wireshark dissector ==
A [[Bitcoin Dissector|dissector]] for Wireshark is being developed.

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

Securing Your Computer

2014-05-07T01:21:35Z

Burrito: /* Encryption */

If you want to [[Secure Trading|trade securely]], you must observe some security precautions. Along with the concerns of conventional online banking, trading with Bitcoins also requires physically securing your computer.

==Operating System==
Even the best operating system is only as good as it is maintained and configured.

===Updates===
In general, make sure to install all the safety-related updates from the manufacturer. Modern operating systems have an automatic update feature that is essential to activate. This ensures that available updates are always installed as soon as possible. This is important because as soon as the manufacturer patches a security issue, the error usually is already well known in certain circles long before the patch is released.

===Virus Protection===
To minimize the possibility of malicious software like viruses or trojans finding a home in your computer, it is important to install a functioning and current virus scanner.

Also it is important to realize the principle of "more is better" does not apply. Installing two, or even more, virus scanners on a computer can greatly reduce system stability, speed, and usability. For home users, there is a variety of virus scanners that are free for home use that are completely sufficient.

For more detailed information please visit the corresponding [http://en.wikipedia.org/wiki/Antivirus_software Wikipedia article].

===Firewall===
A firewall protects against outside access to your computer and installed applications, preventing unauthorized access to the network. Since no virus scanner can detect all potential pests, a firewall is therefore a useful protection against trojans, for if one does happen to get installed, it will be unable to transmit passwords or similar information.

If you do not have a well-configured hardware firewall, or do not know if you are behind one, it is absolutely necessary to install and configure a software firewall (one typically comes built-in to the operating system). A software firewall is a useful addition to a hardware firewall, since there is a possibility that another computer within your network is already infected, or has some other nefarious intention.

Also, a firewall is only as good as it is configured. The rule "the stricter the better" definitely applies. It should only allow applications that you know and trust to access the network. Some firewalls will recognize the ports used by particular applications to communicate with the outside world. If this is not the case, you should consult your firewall's documentation for direction on how to open a port. The port that Bitcoin uses is port 8333.

For more detailed information, please visit the corresponding [http://en.wikipedia.org/wiki/Firewall_(computing) Wikipedia article].

==Theft==
To ensure [[Secure Trading|secure trading]], the physical components of your computer, as well as any media (USB stick, external hard drive, etc) on which your wallet is stored, must be secured.

===Anti-theft===
Many laptops and even some desktop computers can be secured with a cable designed to prevent theft. Such cables are named after the largest manufacturer of security cables, Kensington, and are designed to connect to the computer's "Kensington Security Slot". Use of such a security cable allows a computer to be "chained" to an immovable object such as a heating pipe, or a specially mounted bracket. This will not make theft impossible, but makes theft incredibly difficult without the proper set of tools.

===Encryption===
Since computers can not always be chained up everywhere, and even the best security cable is not immune to bolt cutters, it is important that the medium on which you store your [[wallet]] be encrypted. For example, [http://www.truecrypt.org TrueCrypt] is an open source program and can be used to encrypt your media.

Although the computer might have been stolen, at least the thief does not have access to your wallet and cannot send Bitcoins in your name. Despite being encrypted and safe from prying eyes, your wallet is still irretrievably lost, which makes it important to regularly keep a [[backup]] of your wallet.

With processors always getting faster, brute force attacks on passwords are getting easier and easier. To stem this advance in password-breaking, a good-length (>12 characters), complex password with special characters should be used. [http://www.truecrypt.org TrueCrypt] itself even recommends the use of at least 20 characters.

Users need to be informed, understand, and be up-to-date with the concepts behind password cracking in order to know the nature of the password they should choose. [http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/ This Ars Technica article] is very informative about this. In some cases and some algorithms, an extremely long ''random'' password with many types of ''random'' characters is required. Even passwords like [http://arstechnica.com/security/2013/10/izmy-p55w0rd-saph/ these] aren't immune.

==See Also==
*[[Securing your wallet]]
*[[Secure Trading]]

[[de:Sichern des Computers]]

[[Category:Instructional]]

Securing Your Computer

2014-05-07T01:18:57Z

Burrito: /* Encryption */

If you want to [[Secure Trading|trade securely]], you must observe some security precautions. Along with the concerns of conventional online banking, trading with Bitcoins also requires physically securing your computer.

==Operating System==
Even the best operating system is only as good as it is maintained and configured.

===Updates===
In general, make sure to install all the safety-related updates from the manufacturer. Modern operating systems have an automatic update feature that is essential to activate. This ensures that available updates are always installed as soon as possible. This is important because as soon as the manufacturer patches a security issue, the error usually is already well known in certain circles long before the patch is released.

===Virus Protection===
To minimize the possibility of malicious software like viruses or trojans finding a home in your computer, it is important to install a functioning and current virus scanner.

Also it is important to realize the principle of "more is better" does not apply. Installing two, or even more, virus scanners on a computer can greatly reduce system stability, speed, and usability. For home users, there is a variety of virus scanners that are free for home use that are completely sufficient.

For more detailed information please visit the corresponding [http://en.wikipedia.org/wiki/Antivirus_software Wikipedia article].

===Firewall===
A firewall protects against outside access to your computer and installed applications, preventing unauthorized access to the network. Since no virus scanner can detect all potential pests, a firewall is therefore a useful protection against trojans, for if one does happen to get installed, it will be unable to transmit passwords or similar information.

If you do not have a well-configured hardware firewall, or do not know if you are behind one, it is absolutely necessary to install and configure a software firewall (one typically comes built-in to the operating system). A software firewall is a useful addition to a hardware firewall, since there is a possibility that another computer within your network is already infected, or has some other nefarious intention.

Also, a firewall is only as good as it is configured. The rule "the stricter the better" definitely applies. It should only allow applications that you know and trust to access the network. Some firewalls will recognize the ports used by particular applications to communicate with the outside world. If this is not the case, you should consult your firewall's documentation for direction on how to open a port. The port that Bitcoin uses is port 8333.

For more detailed information, please visit the corresponding [http://en.wikipedia.org/wiki/Firewall_(computing) Wikipedia article].

==Theft==
To ensure [[Secure Trading|secure trading]], the physical components of your computer, as well as any media (USB stick, external hard drive, etc) on which your wallet is stored, must be secured.

===Anti-theft===
Many laptops and even some desktop computers can be secured with a cable designed to prevent theft. Such cables are named after the largest manufacturer of security cables, Kensington, and are designed to connect to the computer's "Kensington Security Slot". Use of such a security cable allows a computer to be "chained" to an immovable object such as a heating pipe, or a specially mounted bracket. This will not make theft impossible, but makes theft incredibly difficult without the proper set of tools.

===Encryption===
Since computers can not always be chained up everywhere, and even the best security cable is not immune to bolt cutters, it is important that the medium on which you store your [[wallet]] be encrypted. For example, [http://www.truecrypt.org TrueCrypt] is an open source program and can be used to encrypt your media.

Although the computer might have been stolen, at least the thief does not have access to your wallet and cannot send Bitcoins in your name. Despite being encrypted and safe from prying eyes, your wallet is still irretrievably lost, which makes it important to regularly keep a [[backup]] of your wallet.

With processors always getting faster, brute force attacks on passwords are getting easier and easier. To stem this advance in password-breaking, a good-length (>12 characters), complex password with special characters should be used. [http://www.truecrypt.org TrueCrypt] itself even recommends the use of at least 20 characters.

Users need to be informed, understand, and be up-to-date with the concepts behind password cracking in order to know the nature of the password they should choose. [http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/ This Ars Technica article] is very informative about this. In some cases and some algorithms, an extremely long ''random'' password with many types of ''random'' characters is required.

==See Also==
*[[Securing your wallet]]
*[[Secure Trading]]

[[de:Sichern des Computers]]

[[Category:Instructional]]

Securing Your Computer

2014-05-07T01:18:46Z

Burrito:

If you want to [[Secure Trading|trade securely]], you must observe some security precautions. Along with the concerns of conventional online banking, trading with Bitcoins also requires physically securing your computer.

==Operating System==
Even the best operating system is only as good as it is maintained and configured.

===Updates===
In general, make sure to install all the safety-related updates from the manufacturer. Modern operating systems have an automatic update feature that is essential to activate. This ensures that available updates are always installed as soon as possible. This is important because as soon as the manufacturer patches a security issue, the error usually is already well known in certain circles long before the patch is released.

===Virus Protection===
To minimize the possibility of malicious software like viruses or trojans finding a home in your computer, it is important to install a functioning and current virus scanner.

Also it is important to realize the principle of "more is better" does not apply. Installing two, or even more, virus scanners on a computer can greatly reduce system stability, speed, and usability. For home users, there is a variety of virus scanners that are free for home use that are completely sufficient.

For more detailed information please visit the corresponding [http://en.wikipedia.org/wiki/Antivirus_software Wikipedia article].

===Firewall===
A firewall protects against outside access to your computer and installed applications, preventing unauthorized access to the network. Since no virus scanner can detect all potential pests, a firewall is therefore a useful protection against trojans, for if one does happen to get installed, it will be unable to transmit passwords or similar information.

If you do not have a well-configured hardware firewall, or do not know if you are behind one, it is absolutely necessary to install and configure a software firewall (one typically comes built-in to the operating system). A software firewall is a useful addition to a hardware firewall, since there is a possibility that another computer within your network is already infected, or has some other nefarious intention.

Also, a firewall is only as good as it is configured. The rule "the stricter the better" definitely applies. It should only allow applications that you know and trust to access the network. Some firewalls will recognize the ports used by particular applications to communicate with the outside world. If this is not the case, you should consult your firewall's documentation for direction on how to open a port. The port that Bitcoin uses is port 8333.

For more detailed information, please visit the corresponding [http://en.wikipedia.org/wiki/Firewall_(computing) Wikipedia article].

==Theft==
To ensure [[Secure Trading|secure trading]], the physical components of your computer, as well as any media (USB stick, external hard drive, etc) on which your wallet is stored, must be secured.

===Anti-theft===
Many laptops and even some desktop computers can be secured with a cable designed to prevent theft. Such cables are named after the largest manufacturer of security cables, Kensington, and are designed to connect to the computer's "Kensington Security Slot". Use of such a security cable allows a computer to be "chained" to an immovable object such as a heating pipe, or a specially mounted bracket. This will not make theft impossible, but makes theft incredibly difficult without the proper set of tools.

===Encryption===
Since computers can not always be chained up everywhere, and even the best security cable is not immune to bolt cutters, it is important that the medium on which you store your [[wallet]] be encrypted. For example, [http://www.truecrypt.org TrueCrypt] is an open source program and can be used to encrypt your media.
Although the computer might have been stolen, at least the thief does not have access to your wallet and cannot send Bitcoins in your name. Despite being encrypted and safe from prying eyes, your wallet is still irretrievably lost, which makes it important to regularly keep a [[backup]] of your wallet.
With processors always getting faster, brute force attacks on passwords are getting easier and easier. To stem this advance in password-breaking, a good-length (>12 characters), complex password with special characters should be used. [http://www.truecrypt.org TrueCrypt] itself even recommends the use of at least 20 characters.
Users need to be informed, understand, and be up-to-date with the concepts behind password cracking in order to know the nature of the password they should choose. [http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/ This Ars Technica article] is very informative about this. In some cases and some algorithms, an extremely long ''random'' password with many types of ''random'' characters is required.

==See Also==
*[[Securing your wallet]]
*[[Secure Trading]]

[[de:Sichern des Computers]]

[[Category:Instructional]]

Bitomat

2014-05-07T01:09:15Z

Burrito:

Bitomat was the first Polish [[currency exchange|exchange]] offering PLN support. The service was acquired by [[MtGox]]. See [[Bitomat#History|history]] for details.

Traders deposit funds (PLN or BTC) to the site and then place orders to buy and sell. Bitomat acts as an escrow.

Funds are credited after each transaction immediately to accounts wherein they can be withdrawn off-site.

Usually it takes just a few minutes to transfer PLN from/to bank account (as long as its [http://en.wikipedia.org/wiki/MBank mBank] bank account).

==History==
The exchange went online on April 4, 2011<ref>[http://bitcoin.pl/forum/viewtopic.php?f=7&t=166 Request for public beta feedback on Polish Bitcoin forum]</ref>.

The exchange went offline on July 26th, 2011 and on July 31, 2011 the site returned but carried the message that a system failure occurred: "all data stored has been lost!, Including records concerning bitcoin portfolio and its backups (backups)". Additionally, the message contained the solicitation: "Www.bitomat.pl service is on sale". A few days later the site reopened and trading resumed.

The service was acquired by Mt. Gox on August 11, 2011<ref>[http://support.mtgox.com/entries/20357051-mt-gox-the-world-s-largest-bitcoin-exchange-to-acquire-bitomat-pl-compensate-loss-of-bitcoins Mt.Gox, The World’s Largest Bitcoin Exchange to Acquire Bitomat.pl, Compensate Loss Of Bitcoins]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://bitomat.pl Bitomat PL exchange] website (PL)
* [http://bitcoin.pl/forum/viewtopic.php?f=7&t=166 forum] (PL)

==References==
<references/>
[[Category:Defunct products or services]]

Category:Defunct products or services

2014-05-07T01:06:33Z

Burrito:

List of articles regarding products, services, or software, that are defunct, dead, inactive, broken, or not applicable to today's Bitcoin ecosystem. The latter case includes things like GPU mining software, but excludes things like cryptographic or math concepts which aren't being used anywhere.

The intention is not necessarily for all these pages to be deleted, just to make it easier to assess which ones should be deleted.

Category:Defunct products or services

2014-05-07T01:05:53Z

Burrito:

List of articles regarding products, services, or software, that are defunct, dead, inactive, broken, or not applicable to today's Bitcoin ecosystem. The latter case includes things like GPU mining software, but excludes things like cryptographic or concepts which aren't being used anywhere.

The intention is not necessarily for all these pages to be deleted, just to make it easier to assess which ones should be deleted.

User:Burrito/unSYSTEM

2014-05-07T00:27:34Z

Burrito:

This is a draft.

'''unSYSTEM''' is a software development working group dedicated to creating popular tools that promote privacy, independence, and integrity in contradistinction to those used for mass surveillance and suppression. unSYSTEM styles itself as working outside the "tainted spheres of legitimacy" and helping others do the same.

== Projects ==

User:Burrito/unSYSTEM

2014-05-07T00:22:37Z

Burrito: This is a draft.

Bitcoin-python

2014-05-07T00:10:10Z

Burrito:

Friendly bitcoin API binding for Python.

bitcoin-python is a set of Python libraries that allows easy access to the Bitcoin peer-to-peer cryptocurrency client API.

This software is Open Source.

==Documentation==
Documentation can be found here, or in the source archive. It is built using Sphinx:

http://laanwj.github.com/bitcoin-python/doc/

==PIP==

The library can also be found in the Python package repository

https://pypi.python.org/pypi/bitcoin-python/0.3

This means that it can be installed using '''pip install bitcoin-python'''.

== Project status ==

According to [https://pypi.python.org/pypi/bitcoin-python/0.3 the PyPI page], bitcoin-python is not actively maintained. The page suggests using [https://github.com/petertodd/python-bitcoinlib python-bitcoinlib] instead, which offers far more features.

The PyPI page for bitcoin-python leaves open the opportunity for anyone to take up the maintainer role for bitcoin-python, if they contact the developer.

==See Also==
* [[Original Bitcoin client]]

==External Links==
* [https://github.com/laanwj/bitcoin-python bitcoin-python] project

[[Category:API Bindings]]
[[Category:Open Source]]
[[Category:Frontends]]
[[Category:Defunct_products_or_services]]

Bitcoin Consultancy

2014-05-07T00:00:46Z

Burrito: Maybe some of this stuff should be moved to Unsystem's page, if there is one?

An organization offering software development and consulting.
Provides open source software and consulting to advance the development of bitcoin.

The service develops sectors of bitcoin and strengthens bitcoin's position as a proper means of conducting commerce.

The service was begun in April, 2011<ref>[http://bitcoinconsultancy.com/#jmp_aboutus About Us] page on on company website</ref>.

==Open Source Projects==
The service develops a number of [[:Category:Open Source|open source]] software projects.

* [https://gitorious.org/intersango/ Intersango] exchange software (used by [[Britcoin]] and [[Intersango]] exchanges)
* [[Freecoin]] bitcoin client
* [[Spesmilo]] RPC client (broken)
* [[Witcoin]] (dead - parked domain)
* [https://bitcointalk.org/index.php?topic=30646.0 libbitcoin]
* [https://bitcointalk.org/index.php?topic=50721.0 subvertx]
* Python version of bitcoin 
* [https://github.com/genjix/kartludox Kartludox] open source poker client 

==External Links==

* [http://bitcoinconsultancy.com Bitcoin Consultancy] website (dead link on 7 May 2014)

==References==
<references />

[[Category:Consulting]]

Erik Voorhees

2014-05-06T23:48:26Z

Burrito:

* Operates [[SatoshiDice]] and Paysius
* Currently employed by [[BitInstant]]

[[Category:People]]

Brasil Bitcoin Market

2014-05-06T23:33:40Z

Burrito:

Formerly a [[currency exchange]] site serving those trading between bitcoins and the following currencies:

* BRL (Brazilian Real)

The language supported by the site is Portugese.

The service was first seen in September, 2011.

Payments were sent and received through, MoIP (Money over IP) which transacts using the bank wire network.

As of February 2012, Brasil Bitcoin Market has not been in operation since November 10, 2011.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==References==
<References />

[[Category:Defunct products or services]]

Category:Defunct products or services

2014-05-06T23:29:25Z

Burrito:

List of articles regarding products, services, or software, that are defunct, dead, inactive, broken, or not applicable to today's Bitcoin ecosystem. The latter case includes things like GPU mining software.

The intention is not necessarily for all these pages to be deleted, just to make it easier to assess which ones should be deleted.

BTC Buy

2014-05-06T23:28:20Z

Burrito:

Formerly a seller of prepaid virtual gift cards, and wireless refills in exchange for Bitcoins.

==History==

The site was launched on June 8, 2011<ref>[http://forum.bitcoin.org/index.php?topic=12506.0 BTC Buy (www.btcbuy.info): trade BTC for gift cards]</ref>.

On April 3, 2013 the prepaid gift cards and wireless services were discontinued due to regulatory concerns. The service will pivot to other goods that are not associated with transmission of money.

As of May 2014, the blog was deleted and no new information was posted on its Twitter feed.

==External Links==
* [http://twitter.com/#!/btcbuy @BTCBuy] on Twitter
* [http://blog.btcbuy.info BTC Buy blog]

==References==
<references />
[[Category:Defunct products or services]]

Bitcoin Jobs

2014-05-06T23:23:41Z

Burrito: Site directs to Tumblr page since [between November 2013 and Feburary 2014] according to Wayback Machine.

'''Bitcoin Jobs''' is a collaborative job board.

Job listings include work that compensates with bitcoins or are Bitcoin related in some other way.

Listings have included full-time and part-time listings however most Bitcoin jobs are targeted to the freelancer.

Users can submit a:
* Text post with Title and Post
* Photo post with Photo (with optional link) and Caption
* Link post with Title, URL and Description
* Quote post with Quote and Source
* Video post with Embed code and Caption

==See Also==

* [http://www.bitcoinjobmarket.com/ BitCoin Job Market] Post and find jobs payable in Bitcoin.
* [[Work For Bitcoin]] Full functional and free freelance website.
* [[:Category:Freelancers|Freelancers]]
* [[BitGigs]] task-sized jobs board
* [[Bitcoiners]] job board and freelancer directory
* [http://www.rugatu.com/ Rugatu Q&A Community] Ask questions with bitcoin, or have a bitcoin freelance job.
* [[BTCworkers]] Bitcoin freelancing board with payment escrow.

==External Links==

* [http://www.bitcoinjobs.com BitcoinJobs.com] web site
* Twitter: [http://twitter.com/bitcoinjobs @BitcoinJobs]
* [http://www.bitcoinjobs.com/submit Submit a job listing]

[[Category:For Hire]]
[[Category:Defunct products or services]]

Category:Defunct products or services

2014-05-06T23:18:12Z

Burrito:

List of articles regarding products, services, or software, that are defunct, dead, inactive, no longer developed, or not applicable to today's Bitcoin ecosystem. The latter case includes things like GPU mining software.

The intention is not necessarily for all these pages to be deleted, just to make it easier to assess which ones should be deleted.

Spesmilo

2014-05-06T23:15:39Z

Burrito: /* Screenshots */ Heading/section appears empty.

[[File:Spesmilo_english.png|thumb|400px|right]]
[[File:Spesmilo_esperanto.png|thumb|400px|right]]

Python-based RPC front-end for bitcoind/Bitcoin-Qt, which is no longer maintained or active. Reported to be broken as-of bitcoind version 0.6.
Principal authors: [[User:genjix|genjix]] and [[User:Luke-Jr|Luke-Jr]]

==Features==
* Multilingual: American, Dutch, English, Esperanto, or French.
* Supports both Decimal and [[Tonal BitCoin|Tonal]] Bitcoins (and autodetection)
* Supports [[URI Scheme|bitcoin: URIs]]
* Can connect to remote JSON-RPC
* Can run local "embedded" bitcoind

==Current version (0.0.1.beta1)==
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_i386_windows.exe Windows installer] -- Requires Administrator to install or you will get an error
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_source.tbz2 Source code]

===Gentoo install===
layman -o https://gitorious.org/bitcoin/gentoo/blobs/raw/master/overlay.xml -f -a bitcoin
emerge -a spesmilo #(you may need to keyword some packages)

===Quick start (from source)===
# Dependencies: PySide, ImageMagick
make local
make
./spesmilo

To install:
make install

To install with bitcoin: URI support for KDE:
make install KDESERVICEDIR="/usr/share/kde4/services"

<gallery>
{{ns:file}}:Spesmilo-tonal.png|Tonal preference
{{ns:file}}:Spesmilo-decimal.png|Decimal preference
</gallery>

==External Links==

* [https://bitcointalk.org/index.php?topic=3451.0 Forum thread]
* [http://gitorious.org/bitcoin/spesmilo Gitorious repository]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/GPLv3]]
[[Category:Open Source]]
[[Category:Mobile]]
[[Category:Defunct products or services]]

Spesmilo

2014-05-06T23:15:00Z

Burrito:

[[File:Spesmilo_english.png|thumb|400px|right]]
[[File:Spesmilo_esperanto.png|thumb|400px|right]]

Python-based RPC front-end for bitcoind/Bitcoin-Qt, which is no longer maintained or active. Reported to be broken as-of bitcoind version 0.6.
Principal authors: [[User:genjix|genjix]] and [[User:Luke-Jr|Luke-Jr]]

==Features==
* Multilingual: American, Dutch, English, Esperanto, or French.
* Supports both Decimal and [[Tonal BitCoin|Tonal]] Bitcoins (and autodetection)
* Supports [[URI Scheme|bitcoin: URIs]]
* Can connect to remote JSON-RPC
* Can run local "embedded" bitcoind

==Current version (0.0.1.beta1)==
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_i386_windows.exe Windows installer] -- Requires Administrator to install or you will get an error
* [http://luke.dashjr.org/programs/bitcoin/files/Spesmilo_0.0.1.beta1_source.tbz2 Source code]

===Gentoo install===
layman -o https://gitorious.org/bitcoin/gentoo/blobs/raw/master/overlay.xml -f -a bitcoin
emerge -a spesmilo #(you may need to keyword some packages)

===Quick start (from source)===
# Dependencies: PySide, ImageMagick
make local
make
./spesmilo

To install:
make install

To install with bitcoin: URI support for KDE:
make install KDESERVICEDIR="/usr/share/kde4/services"

==Screenshots==
<gallery>
{{ns:file}}:Spesmilo-tonal.png|Tonal preference
{{ns:file}}:Spesmilo-decimal.png|Decimal preference
</gallery>

==External Links==

* [https://bitcointalk.org/index.php?topic=3451.0 Forum thread]
* [http://gitorious.org/bitcoin/spesmilo Gitorious repository]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:License/GPLv3]]
[[Category:Open Source]]
[[Category:Mobile]]
[[Category:Defunct products or services]]

Category:Defunct products or services

2014-05-06T23:14:27Z

Burrito: Created page with "List of articles regarding products, services, or software, that are defunct, dead, inactive, no longer developed, or not applicable to today's Bitcoin ecosystem. The latter c..."

Bitcoinica

2014-05-06T22:59:08Z

Burrito:

Was an online service that enabled leveraged speculation in its contract-for-difference (CFD) market against the Bitcoin to USD (BTC/USD) exchange rate.

==History==

The service was launched on September 8, 2011<ref>[https://bitcointalk.org/index.php?topic=42267.0 Bitcoinica - Advanced Bitcoin Trading Platform]</ref>. On March 1st, 2012 the site suffered a significant financial loss when a web hosting had an internal security breach that gave the attacker access to a wallet in which Bitcoinica stored funds. More than 43K bitcoins were stolen by the attacker. The operator provided a statement that reserves were sufficient to cover the loss<ref>[http://bitcointalk.org/index.php?topic=66979.0 Bitcoinica lost 43,554 BTC from Linode compromise, suspicious TXIDs publicized]</ref>.

Announced on April 20, 2012 was that Bitcoinica had "reorganized" and was now operated as Bitcoinica LP and had become a registered Financial Services Provider<ref>[http://bitcointalk.org/index.php?topic=77523.msg861805#msg861805 Bitcoinica is now a registered Financial Services Provider!]</ref>.

On May 11, 2012 Bitcoinica suffered for the second time a security incident in which a large amount of coins were stolen from its hot wallet<ref>[http://bitcointalk.org/index.php?topic=81045.0 Bitcoinica site is taken offline for security investigation]</ref>.

On August 1, 2012 the Wendon Group investment fund as creditor to Bitcoinica LP announced that it will appoint a receiver under New Zealand law<ref>[http://bitcointalk.org/index.php?topic=97272.0 Bitcoinica Consultancy abandons customers. Bitcoinica to enter Liquidation]</ref>.

==References==
<references />
[[Category:Defunct products or services]]

Bitomat

2014-05-06T22:57:07Z

Burrito:

Bitomat was the first Polish [[currency exchange|exchange]] offering PLN support. The service was acquired by [[MtGox]]. See [[Bitomat#History|history]] for details.

Traders deposit funds (PLN or BTC) to the site and then place orders to buy and sell. Bitomat acts as an escrow.

Funds are credited after each transaction immediately to accounts wherein they can be withdrawn off-site.

Usually it takes just a few minutes to transfer PLN from/to bank account (as long as its [http://en.wikipedia.org/wiki/MBank mBank] bank account).

==History==
The exchange went online on April 4, 2011<ref>[http://bitcoin.pl/forum/viewtopic.php?f=7&t=166 Request for public beta feedback on Polish Bitcoin forum]</ref>.

The exchange went offline on July 26th, 2011 and on July 31, 2011 the site returned but carried the message that a system failure occurredL: "all data stored has been lost!, Including records concerning bitcoin portfolio and its backups (backups)". Additionally, the message contained the solicitation: "Www.bitomat.pl service is on sale". A few days later the site reopened and trading resumed.

The service was acquired by Mt. Gox on August 11, 2011<ref>[http://support.mtgox.com/entries/20357051-mt-gox-the-world-s-largest-bitcoin-exchange-to-acquire-bitomat-pl-compensate-loss-of-bitcoins Mt.Gox, The World’s Largest Bitcoin Exchange to Acquire Bitomat.pl, Compensate Loss Of Bitcoins]</ref>.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://bitomat.pl Bitomat PL exchange] website (PL)
* [http://bitcoin.pl/forum/viewtopic.php?f=7&t=166 forum] (PL)

==References==
<references/>
[[Category:Defunct products or services]]

Main Page

2014-05-06T22:54:57Z

Burrito: Looks like it's not protected afterall?

{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">Welcome to the [[Bitcoin]] wiki,</div>
<div style="top:+0.2em; font-size:95%;">for all your Bitcoin information needs.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles. Anti-spam protection from [[Special:CryptoPayment]]</div>
'''[[:Category:Stubs|This wiki]] is maintained by the Bitcoin community.'''
|}

| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[http://bitcoin.org Bitcoin.org]</span>
| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[[Forums]]</span>
| style="width:13%; font-size:120%; padding-right: 40px;" |
* <span class="plainlinks">[[IRC channels|Chatrooms]]</span>
|}


{| id="mp-upper" style="width: 100%; margin:6px 0 0 0; background:none; border-spacing: 0px;"
| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f6e5f1; vertical-align:top; color:#000;" |
{| id="mp-left" style="vertical-align:top; background:#f6e5f1;"
! style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Bitcoin</h2>
|-
| style="color:#000;" | <div id="mp-tfa" style="padding:2px 5px">{{MainPage_Intro}}</div>
|-
! style="padding:2px" | <h2 id="mp-dyk-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Why</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-dyk">{{MainPage_Reasons}}</div>
|}
| style="border:1px solid transparent;" |

| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f6e5f1; vertical-align:top;"|
{| id="mp-right" style="width:100%; vertical-align:top; background:#f6e5f1;"
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Topic central</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_Topics}}</div>
|-
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">FAQ</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_FAQ}}</div>
|}
|}

== Other pages ==

* '''[[mw:Help:Formatting|Help]]''' - Documentation on wiki editing.
* '''[[Bitcoin.it Wiki|About]]''' - Information on this site.
* '''[http://dump.bitcoin.it/ Dumps]''' Backup this wiki.

Languages needing translation work: {{Main Page interwikis}}</noinclude>__NOTOC____NOEDITSECTION__

Main Page

2014-05-06T22:54:37Z

Burrito:

{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">Welcome to the [[Bitcoin]] wiki,</div>
<div style="top:+0.2em; font-size:95%;">for all your Bitcoin information needs.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles. Anti-spam protection from [[Special:CryptoPayment]]</div>
'''[[:Category:Stubs|This wiki]] is maintained by the Bitcoin community.'''
|}

| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[http://bitcoin.org Bitcoin.org]</span>
| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[[Forums]]</span>
| style="width:13%; font-size:120%; padding-right: 40px;" |
* <span class="plainlinks">[[IRC channels|Chatrooms]]</span>
|}


{| id="mp-upper" style="width: 100%; margin:6px 0 0 0; background:none; border-spacing: 0px;"
| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f6e5f1; vertical-align:top; color:#000;" |
{| id="mp-left" style="vertical-align:top; background:#f6e5f1;"
! style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Bitcoin</h2>
|-
| style="color:#000;" | <div id="mp-tfa" style="padding:2px 5px">{{MainPage_Intro}}</div>
|-
! style="padding:2px" | <h2 id="mp-dyk-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Why</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-dyk">{{MainPage_Reasons}}</div>
|}
| style="border:1px solid transparent;" |

| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f6e5f1; vertical-align:top;"|
{| id="mp-right" style="width:100%; vertical-align:top; background:#f6e5f1;"
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Topic central</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_Topics}}</div>
|-
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">FAQ</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_FAQ}}</div>
|}
|}

== Other pages ==

* '''[[mw:Help:Formatting|Help]]''' - Documentation on wiki editing.
* '''[[Bitcoin.it Wiki|About]]''' - Information on this site.
* '''[http://dump.bitcoin.it/ Dumps]''' Backup this wiki.

Languages needing translation work: {{Main Page interwikis}}</noinclude>__NOTOC____NOEDITSECTION__

Bitp.it

2014-05-06T22:41:37Z

Burrito:

Bitp.it (pronounced bit pit) was a Bitcoin mining pool where members could work together to solve blocks.

First launched June 12th, 2011, bitp.it chose to forgo the conventional route of pushpool due to it's numerous bugs and lack of scalability.

Its owners disappeared suddenly at the end of 2011, taking all pool balances with them.

==Overview==

Bitp.it utilized the ESMPPS reward scheme to ensure fair payment in a PPS fashion, while avoiding the risk of paying out more than the pool.
==See Also==
* [[Comparison of mining pools]]
* [[Pooled Mining]]
==External Links==
* [https://pool.bitp.it bitp.it] web site
* [http://forum.bitcoin.org/index.php?topic=12181.0 bitp.it forum]

==References==
<references />
[[Category:Pool Operators]]
[[Category:Defunct products or services]]

CryptoNote

2014-05-06T22:39:15Z

Burrito: /* External links = */

CryptoNote is an open-source technology that allows creation of completely anonymous CPU-based cryptocurrencies. It proposes concepts and features, which haven't become mainstream in the altcoins yet. The only known digital currency to be based on CryptoNote is [[Bytecoin|Bytecoin [BCN]]].

== Features ==

=== Untraceable payments ===

Unlike traditional cryptocurrencies that mostly use unambiguous signatures to verify the transfer, CryptoNote utilizes ring signature. Ring signature is a more sophisticated scheme, which in fact may demand several different public keys for verification. In this case the transaction is signed by a group of users. Thus, the verifier may only identify that one of them was a signer, but not who exactly that was. The public key of a user may appear in a large number of ring signatures even if it was already used to sign her own transaction.

=== Unlinkable transactions ===

CryptoNote automatically creates multiple unique one-time addresses for each of the payments, which are created from the single public key. Even though the payment is sent to a public address, in the block chain it appears as if sent to a one-time address.

The sender uses randam data and the public address of the receiver to calculate this one-time key of the payment. The redemption of the funds requires the receiver's private key, so only the latter may receive the money sent to the one-time address. Moreover, no third party can discover the link between the one-time key and the receiver's public address.

=== Double-spending proof ===

In spite of being anonymous, CryptoNote's ring signatures restrict the double-spending attempt by linking the transactions with the same private key. The protocol uses the key image, derived from a private key through a one-way function. All the users keep the list of all the used key images, which are checked against a new transaction. In case there is a duplicate key image, the transaction is rejected as a double-spending attempt. However, the identity of the sender would still be unknown, since it is impossible to get the private key from its image.

=== Block chain analysis resistance ===

CryptoNote creates an obstacle for an analyst by using ring signatures and one-time addresses covered above. Every address of the payment is a unique one-time key, which is created from both the sender's and the receiver's data, and the usage of ring signature hides the exact outputs that have been spent for the input. Therefore, each next transaction increases the number of possible senders and hides the actual connection even more.

=== Adaptive limits ===

There are no hard constants and magic numbers in CryptoNote. Each limit (e.g., max block size, or min fee amount) is re-calculated based on the historical data of the system. Moreover, the difficulty and the max block size are automatically adjusted with each new block.
The main idea of the algorithm is to sum all the work that nodes have performed during the last 720 blocks and divide it by the time they have spent to accomplish it. The measure of the work is the corresponding difficulty value for each of the blocks.

=== Smooth emission ===

The coins are emitted smoothly, as the reward changes with each new block. This allows a predictable steady growth of money supply determined by the formula<ref>hhttps://cryptonote.org/inside.php#smooth-emission</ref>:

BaseReward = (MSupply - A) >> 18
MSupply = 2^64 - 1 (atomic units)

=== Egalitarian proof of work ===

CryptoNote uses [[CryptoNight]] hashing algorithm as its proof-of-work. Its main feature is that it is suitable only for the ordinary PCs, since CryptoNight utilizes built-in CPU instructions, which are too expensive to implement in the special purpose devices. Therefore, unlike Bitcoin, it allows preserving the equality among various users and prohibits centralization of the network in the hands of several miners.
The proof of work mechanism is actually a voting system. Users vote for the right order of the transactions, for enabling new features in the protocol and for the honest money supply distribution.

== Origins ==

Little is known about CryptoNote's origins. The official website uses supposedly fake names for the team members, while the white paper's author is Nicolas van Saberhagen, which is also likely to be a pseudonym. The white paper "CryptoNote v 2.0" is dated back to October 2013<ref>https://cryptonote.org/whitepaper.pdf</ref>.

The developers have mentioned at CryptoNote's official forum that the team actually consists of cryptographers, developers, and economists, but their identities have to be concealed currently<ref>https://forum.cryptonote.org/viewtopic.php?f=3&t=21#p61</ref>. It was also mentioned that CryptoNote's team and Bytecoin's team have been developing the technology and the currency in a cooperation, but separated soon after the launch<ref>https://forum.cryptonote.org/viewtopic.php?f=3&t=21#p73</ref>.

CryptoNote has have been under development for some time before Bytecoin's launch on the clearnet in March 2014, but there is no evidence of the exact years of R&D. CryptoNote's website mentions "2011—2014" in the footer.

== Implementation ==

The first alternate currency to be based on CryptoNote is [[Bytecoin]]. CryptoNote forum has a separate branch for those who would like to implement the protocol in another altcoin<ref>https://forum.cryptonote.org/viewtopic.php?f=6&t=7</ref>. However, the reference code is still Bytecoin<ref>https://forum.cryptonote.org/viewtopic.php?f=6&t=6#p8</ref>.

== Philosophy ==

CryptoNote philosophy has several key points: privacy as a fundamental human right; government's influence and control remission as an aim.
The economy should be separated from politics, communities should set new transparent principles, and impartial cryptographic algorithms should control its implementation.

== See also ==

* [[Bytecoin]]
* [[CryptoNight]]

== External links ==

* [https://cryptonote.org CryptoNote website]
* [https://forum.cryptonote.org Official forum]
* [https://github.com/amjuarez/bytecoin Reference code]
* [https://cryptonote.org/whitepaper.pdf White paper]
* [https://forum.cryptonote.org/viewtopic.php?f=3&t=30&sid=fe71718a7198f8ccc9e1319e0b1864b6]

== References ==

<references/>

[[Category:Alternative cryptocurrencies]]
[[Category:Digital currencies]]
[[Category:Anonymity]]

P2Pool code documentation

2014-05-06T22:38:24Z

Burrito:

'''Ignore this page for the minute.''' Is just a scratch pad for documenting the p2pool code.
Feel free to add or correct errors if you are familiar with code.

Will tidy up once initial pass done.



==Overview==
The code consists of a number of main tasks.
# Communicate with bitcoind. This mainly gets work - i.e. the latest block and all transactions that need including in the next block. The other communication is for checking the payout address is OK, and publishing newly found blocks to the bitcoin network.
# Store and track p2pool shares. We need to track what shares have been published by us and other users. We need this as to calculate the block generation transaction we need to know who created the previous 8640 shares (fewer if blocks being created in less than 8 hours).
# Communicate with miners. We need to respond the their get work requests with a block header to try to "solve". Also need to handle LongPolling which is a way to inform miners instantly when they need to stop solving the current block header and solve a new one.
# Communicate with p2pool network. We need to connect to other members of the pool and publish and receive shares.
# Web status pages. Web pages that give users details on status of pool.

==Files==
{| border=1
|+ '''Files'''
|-
!Files Name
!Description
|-
|p2pool/main.py
|Main startup and initialisation code
|-
|p2pool/data.py
|P2Pool data structures
|-
|p2pool/networks.py
|Definitions of P2Pool networks (eg. Bitcoin, Bitcoin-testnet, Litecoin, ...)
|-
|p2pool/p2p.py
|P2Pool P2P protocol implementation
|-
|p2pool/web.py
|P2Pool web interface
|-
|p2pool/bitcoin/
|Code related to Bitcoin and its clones. Contains nothing specific to P2Pool
|-
|p2pool/util/pack.py
|Handling of over the wire data structures
|-
|p2pool/util/variable.py
|Code to allow monitoring of when variables change and triggering events
|-
|[[p2pool_util_forest|p2pool/util/forest.py]]
|Contains Tracker class and other classes to track shares and which share is head/tail.
|-
|p2pool/util/skiplist.py]
|Base class for TrackerSkipList and DistanceSkipList.
|}

==p2pool/main.py==
Makes extensive use of twisted.defer. This allows it to "yield" to allow long running network code to complete.
Read up on Python Generators and this before progressing!

Contains main startup code.

===Function run()===
This is the initially executed function.
# Parses arguments
# Reads user/password from bitcoin config file
# Sets up log file
# Sets up logger that reports errors to http://u.forre.st/p2pool_error.cgi (If you are concerned this is a privacy issue add --no-bugreport to command line.)
Finally it adds the main function to the Twister Reactor and start the reactor. (i.e. runs the function main!).

===Function main()===
This does all the startup tasks.
# Tests connection to bitcoind.
# Prints hash of latest block to show bitcoind is up to date.
# Tests connection to p2pool network.
# Gets address to use for payout either from file or bitcoind.
# Validates address and checks local bitcoind owns it.
# Create a "tracker" and loads know shares from files in data/bitcoin/sharesX where X is a number.
# poll_bitcoind then gets work from bitcoind (i.e. block header to hash). Does this by calling getwork function explained below.
# The work_poller() function then polls bitcoind every 15 seconds for new work.
# Check for work from peers. This is new code to try to reduce stales. It gets new block headers from peers if they arrive before they arrive from bitcoind.
# Set up merged work for merged mining.
# Sets up combined work.
# Sets up Longpoll to trigger when current_work changes (transitions).
# Creates Node class that handles connections to other p2pool nodes (see p2p.py also).
# Read p2pool node address from addrs file else use bootstrap addresses.
# Create node object and start it connecting/sending/receiving data.
# Setup loop to save shares to disk every 60 seconds.
# Create tunnel through routers using upnp if enabled.
# Start listening for workers using WorkerBridge Class (e.g. cgminers).
# Create web_root and start web server. This is the monitoring web pages. (see web.py)
# Start IRC connection for announcing blocks.
# Start Status process that output to screen data every 3 seconds.

====Function main/submit_block====
This is a critical function that watches for tracker.verified shares being added. If they meet the difficulty requirements it then submits the block to bitcoind using BOTH the p2p connection and the JSONRPC connection.

The _ function that calls it also send the share that contains the block solution out over the p2pool network to propagate the solution asap and so reduce orphans.

====Class main/WorkerBridge ====
This is the main communication between p2pool process and the workers (mining processes running cgminer or similar).
=====get_user_details=====
This allows clients to connect. Also parses out if this client wants a higher than normal pseudoshare difficulty.
=====get_work=====
This is the main method.
Creates a new share to solve from current data.
Create a "BlockAttempt" which is a bitcoin header for the miner to find a nonce for.
returns the BlockAttempt and a got_response function.

got_response is called when miner finds a solution. It checks that the solution is valid. If below block target we found a block. If below share target we found a share.

'''More debugging in here would be useful to find the "10%" issue'''

===Function getWork()===
This connects to the bitcoind process using the jsonrpc proxy. It calls the getmemorypool function (see [[API_reference_(JSON-RPC)|Bitcoin json-rpc API document]] and [[Original_Bitcoin_client/API_Calls_list|getmemorypool document]]) This returns all the data needed to create a new block (except the nounce obviously!).

getwork then unpacks this into a dictionary containing the header info, the transactions
, the merkel branch/root and the coinbase flags. This is everything that a miner needs to calculate a valid nonce/block.

===Class Node===
This also covers code in p2pool/p2p.py.
It is dependant on p2pool/util/p2protocol.py which is the Twisted.protocol class that handles low level network communication and passes on messages to the handle_xxx methods of the Client and Server factories and Node class.
This class is the main class that handles all the p2pool connections and message handling. It is the core of the p2p network for p2pool.

Is initialised with best_share_hash variable so it can update/monitor it, port, store of peer addresses.

Initially it starts up the client factory that connects to other nodes and a server factory that allows incoming connections.

Then it checks it has enough node addresses, if not asks random peers to send it 8 more addresses.

====Method Node.handle_shares====
Passes new shares onto tracker.
Update peer_heads
Calls compute_work if a new share.

==p2pool/data.py==
Contains the main data structures used in p2pool.
These are:
===hash_link_type===
Serialized SHA256 engine state, used to prove that a coinbase transaction contains some data near the end without sending the entire transaction.
{| border=1
|+ '''hash_link_type'''
|-
!Field
!Type
!Description
|-
|state
|String(32)
|?
|-
|extra_data
|String(0)
|Comments say this is a hack
|-
|length
|VarInt
|?
|}
===small_block_header===
Bitcoin block header, excluding the merkle root. Included in shares, where the merkle root is computed implicitly from the coinbase transaction and the merkle branch.
{| border=1
|+ '''small_block_header'''
|-
!Field
!Type
!Description
|-
|version
|VarInt
|?
|-
|previous_block
|None or Int(256)
|?
|-
|timestamp
|Int(32)
|?
|-
|bits
|FloatingInteger(32)
|?
|-
|nonce
|Int(32)
|?
|}

===share_data_type===
Information contained within a share that is only relevant to P2Pool and that the client has control over (i.e. its value isn't fixed by the protocol rules).
{| border=1
|+ '''share_data_type'''
|-
!Field
!Type
!Description
|-
|previous_share_hash
|None or int(256)
|?
|-
|coinbase
|VarString
|coinbase script
|-
|nonce
|Int(32)
|internal P2Pool nonce
|-
|pubkey_hash
|Int(160)
|pubkey hash of Bitcoin address that this share's payouts will go to
|-
|subsidy
|Int(64)
|total block value
|-
|donation
|Int(16)
|donation to authors. 0 = 0%, 65535 = 100%
|-
|stale_info
|String(32)
|Flag that tells whether the node that generated this share's last share was orphaned or dead. Used to compute pool statistics. Enum (orphan, dao, unk253, unk252...???
|-
|desired_version
|VarInt
|Vote for P2Pool version. Used to trigger upgrade warnings on other nodes
|}

===share_info_type===
Information contained within a share that is only relevant to P2Pool
{| border=1
|+ '''share_info_type'''
|-
!Field
!Type
!Description
|-
|share_data
|share_data_type (see above)
|?
|-
|far_share_hash
|none or int(256)
|Hash of 100th parent of this share. Not currently used for anything, but has applications in timestamping and more secure sharechain bootstrapping
|-
|max_bits
|Float Int
|Maximum share target allowed
|-
|bits
|Float Int
|Share target this share was mined at
|-
|timestamp
|Int(32)
|?
|}

===share_common_type===
Data common to both of the following two types of shares.
{| border=1
|+ '''share_common_type'''
|-
!Field
!Type
!Description
|-
|min_header
|small_block_header_type
|Block header of mined share
|-
|share_info
|share_info_type
|see above
|-
|ref_merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|Merkle branch from hash(ref_type) to ref hash. Currently always empty in generated shares, but could be used by new merged mining implementations
|-
|hash_link
|hash_link_type
|Lets you compute the generation transaction hash as a function of this and the ref hash
|}

===share1a_type===
This is a share that isn't a block solution.
{| border=1
|+ '''share1a_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|merkle_link
|ComposedType(branch:List(Int), index:VarInt)
|Merkle branch from generation transaction hash to block header's merkle root
|}

===share1b_type===
This is a share that is a block solution.
{| border=1
|+ '''share1b_type'''
|-
!Field
!Type
!Description
|-
|common
|share_common_type
|?
|-
|other_txs
|List(bitcoin_data.tx_type)
|List of transactions included in the block besides the generation transaction
|}
===ref_type===
Internal data structure, hashed to determine the "reference hash" at the end of generation transaction.
{| border=1
|+ '''ref_type'''
|-
!Field
!Type
!Description
|-
|identifier
|str(4)
|Value different for every P2Pool instance (Bitcoin, Bitcoin-testnet, Litecoin...)
|-
|share_info
|share_info_type
|see above
|}
===Class share===
Class used to store shares.
====Method generate_transaction====
Returns the share_info and the generation transations. These are all the transactions that pay the other p2pool users the generated coins and fees.
It include 2 special transactions
# The donation sent to the developers.
# A transaction that is not valid, but just has a value of zero and the hash of the share info. This is to prove that when a share is found it was whilst looking for a real p2pool block. This is computed from the ref_type data structure.

==p2pool/util/pack.py==
I think this handles all the binary data types used in the bitcoin protocol to send data over the network wire.
These are nasty as very low level and many big endian/little endian complications.
The p2pool network protocol uses these also.
Do not think you need to really understand this unless making changes at this low level.

==p2pool/__init__.py==
At bottom has DEBUG flag. Change to true to get more output. (running p2pool with --debug does this)
Other than that just returns version number from git if it can.

Phoenix miner

2014-05-06T22:37:46Z

Burrito:

A miner that can work with memory underclocked to 300MHz and scans whole 32bit nonce space.

This free, open-source software is available under the X11 license and was released by Bitcoin community members Jedi95 and CFSworks on April 25, 2011<ref>[http://bitcointalk.org/?topic=6458.0 Phoenix - New efficient, fast, modular miner **BFI_INT support!**]</ref>. In addition to connecting via RPC and RPC (long polling), this miner will connect via [[MultiMiner Protocol]] (MMP) which is used by the [[MultiMiner Server]].

Phoenix2 superceded the original Phoenix miner<ref>[http://bitcointalk.org/index.php?topic=75786 Phoenix 2 Miner]</ref>.

==External Links==

* [https://github.com/phoenix2/phoenix Phoenix] project on GitHub

==References==
<references />

[[Category:Miners]]
[[Category:Open Source]]
[[Category:Defunct products or services]]

Bit-Bank

2014-05-06T22:34:46Z

Burrito:

Formerly an [[eWallet]] service.

The service allowed users to deposit bitcoins directly into an online account, as well as generate addresses to give out to others.

The site also gave every user a unique URL (accessible at http://bit-bank.org/user/name where ''name'' is the username), which allowed the user to give this URL out to others online, granting them the ability to deposit bitcoins into their account.

==History==

At some point before April 18th, 2012 this service was taken offline.

==See Also==

[[Category:EWallets]]
[[Category:Defunct products or services]]

Avalon2

2014-05-06T22:30:30Z

Burrito: Grammar corrections only.

Avalon2 is the second machine of [[Avalon]] project. It uses 55nm ASIC chips.

= Pictures =
== A3255 ==
[[File:A3255 ASIC.jpg | 320px]]

== PCB ==
[[File:Avlaon2-modular-pcb-3d.png | 320px]][[File:Avlaon2-modular-front.jpg | 320px]] [[File:Avlaon2-modular-back.JPG | 320px]]

[[File:Avlaon2-modular-connector-and-fpga.JPG | 320px]] [[File:Avlaon2-modular-a3255.JPG | 320px]] [[File:Avlaon2-modular-power-chip.JPG | 320px]]

[[File:Avlaon2-modular-fan-connector.jpg | 320px]]

== Single modular ==
[[File:Avalon2-single-modular-all-1.jpg | 320px]] [[File:Avalon2-single-modular-all-2.jpg | 320px]] [[File:Avalon2-single-modular-all.JPG | 320px]]

[[File:avalon2-single-modular-set.jpg | 320px]] [[File:avalon2-modular-with-case-con.jpg | 320px]] [[File:avalon2-modular-with-case.jpg | 320px]]

[[File:avalon2-modular-top-side.jpg | 320px]] [[File:avalon2-modular-connector-side.jpg | 320px]] [[File:avalon2-modular-FAN-side.jpg | 320px]]

[[File:avalon2-single-modular-connector-back.jpg | 320px]] [[File:avalon2-single-modular-connector-front.jpg | 320px]]

== Avalon2 parts ==
[[File:avalon2-3modular-connector-back.jpg | 320px]] [[File:avalon2-3modular-connector-front.jpg | 320px]]

[[File:avalon2-usb-serial-connector.jpg | 320px]] [[File:avalon2-usb-serial-connector-BACK.jpg | 320px]] [[File:avalon2-how-to-connector.jpg | 320px]]

[[File:avalon2-fan1.jpg | 320px]] [[File:avalon2-fan.jpg | 320px]]

== Avalon2 ==
[[File:avlaon2-front-without-face.jpg | 320px]] [[File:avalon2-back.jpg | 320px]] [[File:avalon2-top-1.jpg | 320px]]

[[File:avalon2-details-1.jpg | 320px]] [[File:avalon2-details-2.jpg | 320px]] [[File:avalon2-details-3.jpg | 320px]]

[[File:avalon2-power.jpg | 320px]] [[File:avalon2-power-usb.jpg | 320px]] [[File:avalon2-top.jpg | 320px]]

= User manual =
== TP LINK WR703N ==
The USB on the AR9331 has bugs. If you want use serial console, please use the direct serial console on 703N (the '''/dev/ttyATH0'''). It's far more stable than USB-serial converter. You may want add a USB hub between machine and 703n

== Raspberry Pi ==
[[File:13_ports_usb_hub.png | 320px | thumb | The 13 ports USB HUB ]]

* The default firmware IP address is '''192.168.0.100''', you can access it by http://192.168.0.100
* You may need update the address/DNS to your local configuration. DO NOT FORGET your IP address.
* If the Raspberry Pi can access internet, cgminer should automatic start

* 8GB Memory card: http://item.jd.com/632744.html
* Reflash: sudo dd if=openwrt-brcm2708-sdcard-vfat-ext4.img of=/dev/sdb bs=4M #/dev/sdb is your memory card
* USB Hub, [http://item.jd.com/511117.html UNITEK Y-2132 USB2.0 13ports]
* USB WiFi, [http://item.jd.com/509932.html EDUP EP-N8508GS]

== Manual by others ==
* [http://www.cybtc.com/article-565-1.html 彩云比特中文评测]
* [https://bitcointalk.org/index.php?topic=493358.0 Guide - Dogie's Comprehensive Avalon Avalon2 Setup + Silencer Mod]

== Overclock ==
* Chip Freq: 1700, Voltage: 10750 --> 119GHs
Extra cooling is recommended, GJPMiningco recommends removing the slide panel that covers the heatsink and adding some fans that blow down into the heatsink - at least 3 fans evenly spaced along the heatsink.

= The Avalon2 =
== Power supply ==
[[File:Avalon2 power supply.jpg | 300px]]

== Specification ==
315GH/s, 1020W@220V in normal mode.
210GH/s, 420W@220V in ECO mode.

== Avalon2 Single Modular ==
Module hash speed: ~105GHS
Chip operating speed: 1.5GHS
Chip working voltage: 1.0V
Typical values DH: ~2%
Module Power: 24.5A@12V, 294W (excluding fan power consumption). 0.1A @ 5V, 0.5A @ 3.3V.
Power Module conversion efficiency: >= 87%
Design Operating temperature: 85C (chip temperature), 60C (PCB, temperature sensor measurements)
Fan: 4PIN PWM speed control, report fan speed back.
Include: Single modular, USB Connector
=== LEDS ===
From bottom (FPGA) to top is 1 to 8:
1, 2, 3, 4, 5: Blink when found nonce
6, 7, Data transfer
8: Error or under testing

= Design Files =
* A3255 ASIC Datasheet: http://downloads.canaan-creative.com/hardware/A3255/datasheet/
* The Hardware design files: http://downloads.canaan-creative.com/hardware/A3255/avalon2

= Source code =

== Debug port ==
[[File:Avalon3 Debug Port.jpg | 320px]]

* [https://github.com/BitSyncom/mm/ MM(Miner Manager)]]
* [https://github.com/BitSyncom/cgminer/tree/avalon2 The cgminer Avalon2 support]
* [https://github.com/BitSyncom/luci/tree/cgminer-webui-avalon2/applications/luci-cgminer OpenWrt LUCI page]
* [https://github.com/BitSyncom/cgminer-openwrt-packages OpenWrt cgminer package, files and config]
* [https://github.com/BitSyncom/avalon-extras/blob/master/scripts/build-avalon-image.sh Build script file]

= Firmware =

== [http://downloads.canaan-creative.com/software/avalon2/2014-04-23 20140423] ==
* Update '''CGminer from 4.0.0 to 4.3.0''' (You may want read document on '''--config''' options)
* Update OpenWrt to '''r40351''' (Linux version 3.10.34)
* Fix a bug that may cause hashrate lose.
* Support 703N, 1043ND-V2 and RaspBerry Pi
* Detect Avalon power good signal in cgminer
* Display GHS(not MHS) on cgminer status page
* Add some text for support both Avalon2 and Avalon3
* Support frequency setting for Avalon2 and Avalon3 chips on cgminer configuration page
* Support voltage setting for Avalon2 and Avalon3 chips on cgminer configuration page

== [http://downloads.canaan-creative.com/software/avalon2/2014-04-11 20140411] ==
* Here: http://downloads.canaan-creative.com/software/avalon2/2014-04-11
* Update OpenWrt

== [http://downloads.canaan-creative.com/software/avalon2/2014-03-20 20140320] ==
* Here: http://downloads.canaan-creative.com/software/avalon2/2014-03-20/
* MM('''201401-1f7d08b0'''): read the power good single back.
** Poweron five small module one by one. good for PSU.
* Update cgminer to '''4.0.0'''
* Add devs information on status page.

== [http://downloads.canaan-creative.com/software/avalon2/2014-01-23/ 20140123] ==
* Here: http://downloads.canaan-creative.com/software/avalon2/2014-01-23/
* MM('''201401-a3cb3950'''): Include the first stable version of MM firmware
* Include the RPi OpenWrt firmware
* Include the 703N OpenWrt firmware
* Support fixed fan speed, support A3255 frequency from 1G to 2G, support adjust voltage for 0.65v to 1.1v
* Display all modules status include 2 fan, 2 temperature sensors, voltage and frequency
* Voltage display as encode mode. needs to be changed to human readable
* Include an ASIC cores testing python script

== [http://downloads.canaan-creative.com/software/avalon2/ NEXT] ==
* NOTICE: Only for testing

= Test plan =
* Test 10 avalon2 single module with one host (703N or RPi)

= Testing on ASIC cores =
* The Avalon2 MM firmware support testing. no needs particular firmware.
* The host test program is here: https://github.com/BitSyncom/avalon-extras/blob/master/scripts/avalon2-a3255-modular-test.py
* Run avalon2-a3255-modular-test.py for testing. you may update your serial port at -s option.

= Donation =
* Ngzhang0: [https://blockchain.info/address/1kBGUHDxmSAegACRB6fcE2vrnVAfPJarW 1kBGUHDxmSAegACRB6fcE2vrnVAfPJarW]
* Con Kolivas: [https://blockchain.info/address/15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ]
* Kanoi: [https://blockchain.info/address/1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb]
* Xiangfu: [https://blockchain.info/address/19BT2rcGStUK23vwrmF6y6s3ZWpxzQQn8x 19BT2rcGStUK23vwrmF6y6s3ZWpxzQQn8x]

= Links =
* 55nm open design contest: http://avalon-asics.com/avalon-gen2-55nm-open-source-design-contest/
* Documents release by Avalon: http://downloads.canaan-creative.com/hardware/A3255/
* [[Avalon2 prototype]] by using Avalon1 hardware design

[[zh-cn:阿瓦隆2]]

[[Category:Hardware]]

User:Burrito/Using Bitcoin

2014-05-06T22:24:07Z

Burrito: /* See also */

This is a draft.

TODO:
* New screenshots
* How to start the client in Testnet mode
* Testnet faucets
* Fix titles (top level heading should be <nowiki>==, not =</nowiki>)

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
Current releases of Bitcoin Core have a different user interface than the versions used in this article.

This article could use an update. See the discussion for this article for more.

Even when this article gets updated, it is likely to get oudated again very quickly.
</div>

This page is a detailed tutorial to help new users understand and use bitcoin. After you read this page, you'll know the basics of what bitcoin is, how to get and install the Bitcoin Core client, where to get coins, and how to use the client to send and receive transactions.

If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.

=What is Bitcoin=

Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each group of transactable coins is assigned to the owner's public key, and is transferable via cryptographically signed messages.

=Getting started=

In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]].

==Download and install the client==

First, download the bitcoin client from https://bitcoin.org/en/download . Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.

===Issues with Linux package repositories===
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and thus may be harmful to use. For Debian unstable (Sid), users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. Users of any Linux distribution can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.

==Starting the client and connecting to the network==

[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client.

When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours. Using [https://bitcointalk.org/index.php?topic=145386.0 the bootstrap.dat file] is a more efficient method for initial sync, but is optional.

At this point, it is recommended to encrypt your wallet before receiving any bitcoins. Encrypting later may leave earlier addresses vulnerable to theft in the case that the system is compromised. This can be done from the Settings menu using the Encrypt Wallet function.

==Client features==

Your first bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.

The status bar at the bottom will display some important information if you hover your cursor over its icons. You will see the encryption status of your wallet, then the number of bitcoin nodes your client is connected to, and finally, the number of blocks your client has in its chain.

=Using bitcoin=

In this section, you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations.





==Bitcoin addresses==

In order for someone to pay you, they need to know your Bitcoin address.

You can create as many new addresses as you like. Using a different address each time helps to preserve your [[anonymity]].

Bitcoin addresses include a checksum, which means that it is generally not possible for transactions to be sent to an address with a typo in them - the address would be invalid.(Though with care you can craft a valid but nonexistent address.)




==Generating bitcoins==

In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2014, the competition for bitcoin mining has become intense, sop you are only likely to achieve anything with specialized hardware.

== Buying Bitcoins ==

Bitcoins can be bought from individuals, on trading exchanges or from other online services. See the main page about [[Buying bitcoins|Buying bitcoins]] for more information.

= Points to remember =

* You don't need to be online to receive bitcoins.
* You can create as many new addresses as you like. Using a different address for each transaction helps keep you [[Anonymity|anonymous]], and will help you with accounting too, allowing you to distinguish between what different transactions were for.
* You can be [[Anonymity|anonymous]] with adequate precautions.
* [[Base58Check encoding|You cannot send BTC to an invalid address]]. Typos are not a worry as the payment will refuse to send.
* The [[Wallet|wallet]] file holds the keys that allow spending and thus the computer should be [[Securing_your_wallet|protected]] from the risk of loss and theft.
* Leaving Bitcoin Core open improves connectivity for the network and ensures that you don't fall behind on the block chain. Also see [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|the FAQ about port forwarding]]

= Technical =
== Block chain ==
The [[block chain]] is a never-ending story of every transaction throughout the network from day 1 (genesis). The first time you run Bitcoin, it is downloaded and verified on your computer. Every new transaction is added to the end of this chain and verified by the network to be valid.

== Addresses ==
Whenever you send money in Bitcoin, you are actually sending a cryptographically signed message, associating this money with the recipient's address. This effectively transfers ownership to the recipient. Once they own the bitcoins, they are free to transfer it to another person.

A wallet is a collection of addresses. You can create as many new addresses as you wish; not reusing addresses makes you more anonymous, because then people cannot see how many bitcoins you received. Your wallet contains the secret keys used for spending that money, and must be [[Securing your wallet|backed-up regularly]]. If you lose control of the wallet then you no longer possess the money.

== Generating ==
New coins are mined through generating hashes. These generators (called miners) are rewarded for the computationally intensive task of incorporating your transactions into the block-chain. This reward halves every 210000 blocks, or approximately every 4 years. The reward will keep halving until it effectively reaches zero, at which point 21 million coins will be in circulation.

In addition to the standard block reward, the miner also receives the sum of the [[transaction fees]] for their block.

=See also=

* [[Getting started]] A brief tutorial for the impatient
* An [[Introduction|introduction]] into more of Bitcoin's key concepts, not covered here.
* [[IRC channels|A list of chatrooms]] where you may be able to find more answers to your questions.
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin subreddit]
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin Beginners subreddit], a community aimed at answering the questions of newbies (e.g. #bitcoin for general questions about structure, usage, and the network).
* [https://bitcointalk.org/ The Bitcoin Forum], another place you may be able to find answers to questions.
* [https://bitcoin.stackexchange.com/ Bitcoin Stack Exchange], mainly aimed at technical questions. Please use the search feature before asking.

[[Category:Introduction]]

[[de:Erste Schritte]]
[[zh-cn:入门]]

User:Burrito/Using Bitcoin

2014-05-06T22:22:09Z

Burrito:

This is a draft.

TODO:
* New screenshots
* How to start the client in Testnet mode
* Testnet faucets
* Fix titles (top level heading should be <nowiki>==, not =</nowiki>)

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
Current releases of Bitcoin Core have a different user interface than the versions used in this article.

This article could use an update. See the discussion for this article for more.

Even when this article gets updated, it is likely to get oudated again very quickly.
</div>

This page is a detailed tutorial to help new users understand and use bitcoin. After you read this page, you'll know the basics of what bitcoin is, how to get and install the Bitcoin Core client, where to get coins, and how to use the client to send and receive transactions.

If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.

=What is Bitcoin=

Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each group of transactable coins is assigned to the owner's public key, and is transferable via cryptographically signed messages.

=Getting started=

In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]].

==Download and install the client==

First, download the bitcoin client from https://bitcoin.org/en/download . Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.

===Issues with Linux package repositories===
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and thus may be harmful to use. For Debian unstable (Sid), users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. Users of any Linux distribution can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.

==Starting the client and connecting to the network==

[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client.

When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours. Using [https://bitcointalk.org/index.php?topic=145386.0 the bootstrap.dat file] is a more efficient method for initial sync, but is optional.

At this point, it is recommended to encrypt your wallet before receiving any bitcoins. Encrypting later may leave earlier addresses vulnerable to theft in the case that the system is compromised. This can be done from the Settings menu using the Encrypt Wallet function.

==Client features==

Your first bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.

The status bar at the bottom will display some important information if you hover your cursor over its icons. You will see the encryption status of your wallet, then the number of bitcoin nodes your client is connected to, and finally, the number of blocks your client has in its chain.

=Using bitcoin=

In this section, you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations.





==Bitcoin addresses==

In order for someone to pay you, they need to know your Bitcoin address.

You can create as many new addresses as you like. Using a different address each time helps to preserve your [[anonymity]].

Bitcoin addresses include a checksum, which means that it is generally not possible for transactions to be sent to an address with a typo in them - the address would be invalid.(Though with care you can craft a valid but nonexistent address.)




==Generating bitcoins==

In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2014, the competition for bitcoin mining has become intense, sop you are only likely to achieve anything with specialized hardware.

== Buying Bitcoins ==

Bitcoins can be bought from individuals, on trading exchanges or from other online services. See the main page about [[Buying bitcoins|Buying bitcoins]] for more information.

= Points to remember =

* You don't need to be online to receive bitcoins.
* You can create as many new addresses as you like. Using a different address for each transaction helps keep you [[Anonymity|anonymous]], and will help you with accounting too, allowing you to distinguish between what different transactions were for.
* You can be [[Anonymity|anonymous]] with adequate precautions.
* [[Base58Check encoding|You cannot send BTC to an invalid address]]. Typos are not a worry as the payment will refuse to send.
* The [[Wallet|wallet]] file holds the keys that allow spending and thus the computer should be [[Securing_your_wallet|protected]] from the risk of loss and theft.
* Leaving Bitcoin Core open improves connectivity for the network and ensures that you don't fall behind on the block chain. Also see [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|the FAQ about port forwarding]]

= Technical =
== Block chain ==
The [[block chain]] is a never-ending story of every transaction throughout the network from day 1 (genesis). The first time you run Bitcoin, it is downloaded and verified on your computer. Every new transaction is added to the end of this chain and verified by the network to be valid.

== Addresses ==
Whenever you send money in Bitcoin, you are actually sending a cryptographically signed message, associating this money with the recipient's address. This effectively transfers ownership to the recipient. Once they own the bitcoins, they are free to transfer it to another person.

A wallet is a collection of addresses. You can create as many new addresses as you wish; not reusing addresses makes you more anonymous, because then people cannot see how many bitcoins you received. Your wallet contains the secret keys used for spending that money, and must be [[Securing your wallet|backed-up regularly]]. If you lose control of the wallet then you no longer possess the money.

== Generating ==
New coins are mined through generating hashes. These generators (called miners) are rewarded for the computationally intensive task of incorporating your transactions into the block-chain. This reward halves every 210000 blocks, or approximately every 4 years. The reward will keep halving until it effectively reaches zero, at which point 21 million coins will be in circulation.

In addition to the standard block reward, the miner also receives the sum of the [[transaction fees]] for their block.

=See also=

* [[Getting started]] A brief tutorial for the impatient
* An [[Introduction|introduction]] into more of Bitcoin's key concepts, not covered here.
* [[IRC channels|A list of chatrooms]] where you may be able to find more answers to your questions.
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin subreddit]
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin Beginners subreddit], a community aimed at answering the questions of newbies.
* [https://bitcointalk.org/ The Bitcoin Forum], another place you may be able to find answers to questions.
* [https://bitcoin.stackexchange.com/ Bitcoin Stack Exchange], mainly aimed at technical questions. Please use the search feature before asking.

[[Category:Introduction]]

[[de:Erste Schritte]]
[[zh-cn:入门]]

User:Burrito/Using Bitcoin

2014-05-06T22:21:27Z

Burrito: This is a draft.

This is a draft.

TODO:
* New screenshots
* How to start the client in Testnet mode
* Testnet faucets

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
Current releases of Bitcoin Core have a different user interface than the versions used in this article.

This article could use an update. See the discussion for this article for more.

Even when this article gets updated, it is likely to get oudated again very quickly.
</div>

This page is a detailed tutorial to help new users understand and use bitcoin. After you read this page, you'll know the basics of what bitcoin is, how to get and install the Bitcoin Core client, where to get coins, and how to use the client to send and receive transactions.

If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.

=What is Bitcoin=

Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each group of transactable coins is assigned to the owner's public key, and is transferable via cryptographically signed messages.

=Getting started=

In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]].

==Download and install the client==

First, download the bitcoin client from https://bitcoin.org/en/download . Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.

===Issues with Linux package repositories===
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and thus may be harmful to use. For Debian unstable (Sid), users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. Users of any Linux distribution can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.

==Starting the client and connecting to the network==

[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client.

When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours. Using [https://bitcointalk.org/index.php?topic=145386.0 the bootstrap.dat file] is a more efficient method for initial sync, but is optional.

At this point, it is recommended to encrypt your wallet before receiving any bitcoins. Encrypting later may leave earlier addresses vulnerable to theft in the case that the system is compromised. This can be done from the Settings menu using the Encrypt Wallet function.

==Client features==

Your first bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.

The status bar at the bottom will display some important information if you hover your cursor over its icons. You will see the encryption status of your wallet, then the number of bitcoin nodes your client is connected to, and finally, the number of blocks your client has in its chain.

=Using bitcoin=

In this section, you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations.





==Bitcoin addresses==

In order for someone to pay you, they need to know your Bitcoin address.

You can create as many new addresses as you like. Using a different address each time helps to preserve your [[anonymity]].

Bitcoin addresses include a checksum, which means that it is generally not possible for transactions to be sent to an address with a typo in them - the address would be invalid.(Though with care you can craft a valid but nonexistent address.)




==Generating bitcoins==

In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2014, the competition for bitcoin mining has become intense, sop you are only likely to achieve anything with specialized hardware.

== Buying Bitcoins ==

Bitcoins can be bought from individuals, on trading exchanges or from other online services. See the main page about [[Buying bitcoins|Buying bitcoins]] for more information.

= Points to remember =

* You don't need to be online to receive bitcoins.
* You can create as many new addresses as you like. Using a different address for each transaction helps keep you [[Anonymity|anonymous]], and will help you with accounting too, allowing you to distinguish between what different transactions were for.
* You can be [[Anonymity|anonymous]] with adequate precautions.
* [[Base58Check encoding|You cannot send BTC to an invalid address]]. Typos are not a worry as the payment will refuse to send.
* The [[Wallet|wallet]] file holds the keys that allow spending and thus the computer should be [[Securing_your_wallet|protected]] from the risk of loss and theft.
* Leaving Bitcoin Core open improves connectivity for the network and ensures that you don't fall behind on the block chain. Also see [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|the FAQ about port forwarding]]

= Technical =
== Block chain ==
The [[block chain]] is a never-ending story of every transaction throughout the network from day 1 (genesis). The first time you run Bitcoin, it is downloaded and verified on your computer. Every new transaction is added to the end of this chain and verified by the network to be valid.

== Addresses ==
Whenever you send money in Bitcoin, you are actually sending a cryptographically signed message, associating this money with the recipient's address. This effectively transfers ownership to the recipient. Once they own the bitcoins, they are free to transfer it to another person.

A wallet is a collection of addresses. You can create as many new addresses as you wish; not reusing addresses makes you more anonymous, because then people cannot see how many bitcoins you received. Your wallet contains the secret keys used for spending that money, and must be [[Securing your wallet|backed-up regularly]]. If you lose control of the wallet then you no longer possess the money.

== Generating ==
New coins are mined through generating hashes. These generators (called miners) are rewarded for the computationally intensive task of incorporating your transactions into the block-chain. This reward halves every 210000 blocks, or approximately every 4 years. The reward will keep halving until it effectively reaches zero, at which point 21 million coins will be in circulation.

In addition to the standard block reward, the miner also receives the sum of the [[transaction fees]] for their block.

=See also=

* [[Getting started]] A brief tutorial for the impatient
* An [[Introduction|introduction]] into more of Bitcoin's key concepts, not covered here.
* [[IRC channels|A list of chatrooms]] where you may be able to find more answers to your questions.
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin subreddit]
* [https://www.reddit.com/r/bitcoinbeginners The Bitcoin Beginners subreddit], a community aimed at answering the questions of newbies.
* [https://bitcointalk.org/ The Bitcoin Forum], another place you may be able to find answers to questions.
* [https://bitcoin.stackexchange.com/ Bitcoin Stack Exchange], mainly aimed at technical questions. Please use the search feature before asking.

[[Category:Introduction]]

[[de:Erste Schritte]]
[[zh-cn:入门]]

IRC channels

2014-05-06T20:03:37Z

Burrito: Dead link.

Most of the following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:

==Bitcoin Project==
{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bc-news}} || RSS News related to Bitcoin.
|-
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion.
|-
| {{Freenode IRC|bitcoin-bots}} || Bot and bot-related discussion; trading bots, IRC bots, utility bots.
|-
| {{Freenode IRC|bitcoin-court}} || [[Bitcoin Court]] Settles disputes between parties.
|-
| {{Freenode IRC|bitcoin-dev}} || Bitcoin software development. ([http://bitcoinstats.com/irc/bitcoin-dev/logs/ history])
|-
| {{Freenode IRC|bitcoin-gaming}} || Bitcoin gamers hangout.
|-
| {{Freenode IRC|bitcoin-gentoo}} || Gentoo community.
|-
| {{Freenode IRC|bitcoin-marketing}} || Marketing and promotion of bitcoin
|-
| {{Freenode IRC|bitcoin-police}} || [[Bitcoin Police]] Investigates incidents related to Bitcoin.
|-
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.
|-
| {{Freenode IRC|bitcoin-pricetalk}} || ALL Discussion Remotely Related to Bitcoin Price goes here
|-
| {{Freenode IRC|bitcoin-tweets}} || Automated announce of bitcoin-related tweets.
|-
| {{Freenode IRC|bitcoin-watch|text=[[Bitcoin-Watch|#bitcoin-watch]]}} || Streaming Bitcoin transactions, including market data.
|}

===Local communities===

{| class="wikitable"
| {{Freenode IRC|bitcoin-otc-eu}} || European OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-ru}} || Russian OTC trading marketplace.
|-
| {{Freenode IRC|bitcoin-otc-uk}} ||United kingdom OTC Trading Marketplace.Founder Angus Bates.
|-
| {{Freenode IRC|bitcoin-aus}} || Aussie bitcoin community.
|-
| {{Freenode IRC|bitcoin-br}} || Brazilian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cad}} || Canadian bitcoin community.
|-
| {{Freenode IRC|bitcoin-cn}} || Chinese bitcoin community.
|-
| {{Freenode IRC|bitcoin-dk}} || Danish bitcoin community.
|-
| {{Freenode IRC|bitcoin-de}} || German bitcoin community.
|-
| {{Freenode IRC|bitcoin-il}} || Israeli bitcoin community.
|-
| {{Freenode IRC|bitcoin-nl}} || Dutch bitcoin community.
|-
| {{Freenode IRC|bitcoin-pl}} || Polish bitcoin community.
|-
| {{Freenode IRC|bitcoin-romania}} || Romanian bitcoin community.
|-
| {{Freenode IRC|bitcoin-ve}} || Venezuelan bitcoin community.
|-
| {{Freenode IRC|btc.chat}} || Russian bitcoin community.

|}

==Mining Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|avalon}} || Discussion and support specific to [[Avalon]] mining machine
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-fpga}} || Discussion and support specific to FPGA mining.
|-
| {{Freenode IRC|cgminer}} || Discussion and support specific to [[CGMiner]] mining ASIC/FPGA/GPU.
|-
| {{Freenode IRC|btc.chat.miners}} || Russian discussion of mining specification.
|-
| {{Freenode IRC|eligius}} || [[Eligius]] mining pool community (also support for [[BFGMiner]] and [[Eloipool]])
|-
| {{Freenode IRC|give-me-coins}} || [[Give Me COINS]] mining pool community
|-
| {{Freenode IRC|ozcoin}} || [[Ozco.in]] mining pool community
|-
| <small>[irc://irc.foonetic.net/xkcd-bitcoin IRC] [http://irc.lc/foonetic/xkcd-bitcoin/Miner@@@ Web]</small> #xkcd-bitcoin || [https://en.bitcoin.it/wiki/XKCD_Pool XKCD Pool]
|-
| <small>[irc://irc.quakenet.org/bitcoins.lc IRC] [http://irc.lc/quakenet/bitcoins.lc/Miner@@@ Web]</small> #bitcoins.lc @ Quakenet || [http://www.bitcoins.lc Bitcoins.lc Pool]
|-
| {{Freenode IRC|bithasher}} || Bit Pool Mining
|-
| {{Freenode IRC|p2pool}} || [[P2Pool]] decentralized mining pool
|-
| {{Freenode IRC|btcserv}} || [[Btcserv.net]] Mining Pool Community
|-
| {{Freenode IRC|bitminter}} || [[BitMinter]] Mining Pool Community
|-
| {{Freenode IRC|kncminer}} || [[KNCMiner]] ASIC Mining Hardware Vendor Discussion
|}

==Communities for Exchanges and Trading==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin-assets}} || Discussion of securities and other asset investments. [http://bitcoin-assets.com bitcoin-assets.com].
|-
| {{Freenode IRC|bitcoin-assets-trades}} || Streaming assets market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-auction}} || Live auctions over IRC.
|-
| {{Freenode IRC|bitcoin-market}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-aud}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-bgn}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-brl}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-cad}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-chf}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-eur}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-gbp}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-hkd}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-inr}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-jpy}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-nzd}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-pln}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-rub}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-sek}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-sgd}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-sll}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-thb}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-usd}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-markets-zar}} || Streaming market data (only), no chat.
|-
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter trading marketplace and discussion. ([http://bitcoinstats.com/irc/bitcoin-otc/logs/ history])
|-
| {{Freenode IRC|bitcoin-escrow}} || Third party escrow agents.
|-
| {{Freenode IRC|bitcoin-otc-ticker|bitcoin-otc-ticker}} || Streaming market data form the [[#bitcoin-otc]] order book.
|-
| {{Freenode IRC|bitcoin-otc-ratings|bitcoin-otc-ratings}} || Updates to ratings on the [[#bitcoin-otc]] Web of Trust.
|-
| {{Freenode IRC|bitcoin-pit}} || Only over-the-counter trading.
|-
| {{Freenode IRC|bitcoin-tickers}} || Bitcoin tickers for all bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-aud}} || Bitcoin tickers for AUD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-bgn}} || Bitcoin tickers for BGN bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-brl}} || Bitcoin tickers for BRL bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-cad}} || Bitcoin tickers for CAD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-chf}} || Bitcoin tickers for CHF bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-eur}} || Bitcoin tickers for EUR bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-gbp}} || Bitcoin tickers for GBP bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-hkd}} || Bitcoin tickers for HKD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-inr}} || Bitcoin tickers for INR bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-jpy}} || Bitcoin tickers for JPY bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-nzd}} || Bitcoin tickers for NZD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-pln}} || Bitcoin tickers for PLN bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-rub}} || Bitcoin tickers for RUB bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-sek}} || Bitcoin tickers for SEK bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-sgd}} || Bitcoin tickers for SGD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-sll}} || Bitcoin tickers for SLL bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-thb}} || Bitcoin tickers for THB bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-usd}} || Bitcoin tickers for USD bitcoin markets
|-
| {{Freenode IRC|bitcoin-tickers-zar}} || Bitcoin tickers for ZAR bitcoin markets
|-
| {{Freenode IRC|bitcoin-wot|bitcoin-wot}} || Distributed Web of Trust (WoT) system for [[#bitcoin-otc]].
|-
| {{Freenode IRC|btc.chat.traders}} || Russian community discussion about trades/exchanges.
|-
| {{Freenode IRC|#mtgox-chat}} || [[#MtGox]] chat (Note the pound sign (#) is part of the channel name)
|-
| {{Freenode IRC|mtgox}} || [[MtGox]] support
|-
| {{Freenode IRC|mtgoxlive}} || [[MtGox Live]] real-time view of trading
|-
| {{Freenode IRC|mtgox-news}} || Mt. Gox topics from Twitter.
|-
| {{Freenode IRC|mtgox-rt}} || Mt. Gox real-time tape (executed trades).
|-
| {{Freenode IRC|bitcoin-rt}} || Real-time tape (executed trades).
|-
| {{Freenode IRC|localbitcoins-chat}} || [[LocalBitcoins.com]] exchange support
|-
| {{Freenode IRC|Coinabul}} || [http://Coinabul.com Coinabul]'s customer support and news channel. Selling gold and silver for Bitcoin.
|}

==Related Communities==

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|opentransactions}} || [[Open Transactions]] project.
|-
| {{Freenode IRC|namecoin}} || [[Namecoin]] and the [[Dot-bit]] project.
|-
| {{Freenode IRC|twister}} || [[Twister]], P2P microblogging discussion.
|-
| {{Freenode IRC|darkwallet}} || [[DarkWallet]] and libbitcoin/Obelisk discussion & development channel.
|-
| {{Freenode IRC|electrum}} || [[Electrum]], lightweight bitcoin client.
|-
| {{Freenode IRC|bitcoin-stackexchange}} || Discussion complementing [http://bitcoin.stackexchange.com Bitcoin StackExchange].

|}

[[pl:Kanały IRC]]
[[ro:Canale]]

Using Bitcoin

2014-05-06T19:06:41Z

Burrito: Oops.

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
Current releases of the bitcoin client have a different user interface than the versions used in this article.

This article could use an update. See the discussion for this article for more.
</div>

This page is a detailed tutorial to help new users understand and using bitcoin. After you read this page, you'll know the basics of what bitcoin is and how it is structured, how to get and install the bitcoin client, where to get coins, and how to use the client to send and receive transactions.

If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.

=What is Bitcoin=

Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each coin is assigned to the owner's public key, and is transferrable via cryptographically signed messages.

=Getting started=

In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]].

==Download and install the client==

First, download the bitcoin client from http://bitcoin.org/. Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.

===Issues with Linux package repositories===
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and may be harmful to use. For Debian, users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. You can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.

==Starting the client and connecting to the network==

[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client.

When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours.

==Client features==

Your starting bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.

The status bar at the bottom will display some important information. If you have [[#Generating bitcoins|bitcoin generation (block hashing)]] turned on, on the left the client will display your hash rate. To the right of that, you will see the number of bitcoin nodes your client is connected to, then, the number of blocks your client has in its chain, and finally, the number of transactions you have in your wallet.

=Using bitcoin=

In this section you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations, where to get your first bitcoins (faucet), generation. Tips on keeping wallet safe.

==Getting your first bitcoins==

There are few things more exciting than getting your first bitcoins! So once you have all the blocks downloaded, head on over to the [https://freebitcoins.appspot.com/ bitcoin faucet], fill out the form and put in your bitcoin address, and receive some free bitcoin! (You can do this before finishing the block chain download, but you won't see the coins in your wallet until you finish downloading the blocks... which would put a damper on the whole excitement bit.)

See [http://en.bitcoin.it/wiki/Trade#Samples_and_Marketing_Offers Samples and Marketing Offers] for other free bitcoins and marketing offers.

Once you submit the form successfully, you should see a new transaction in your client within seconds. But it will be grayed out, and have 0/unconfirmed status:
[[File:First btc recv.png|frame|none]]

Once your transaction makes it into the block chain, the confirmation count will grow in step with the number of blocks in the chain. By default, the client stops showing "unconfirmed" after the transaction is 6 blocks deep in the chain:
[[File:Six confirms bitcoin client.png|frame|none]]

==Bitcoin addresses==

You can create as many new addresses as you like. Using a different address each time helps to preserve your [[anonymity]].

You cannot send BTC to an invalid address. Client will refuse to send payment to a misspecified address. (Though with care you can craft a valid but nonexistent address.)




==Generating bitcoins==

In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2013, the competition for bitcoin mining has become intense, so you are unlikely to achieve much without specialized hardware.

=See also=

* [[Getting started]] A brief tutorial for the impatient

[[Category:Introduction]]

Using Bitcoin

2014-05-06T19:05:21Z

Burrito:

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
Current releases of the bitcoin client have a different user interface than the versions used in this article.

This article could use an update. See the discussion for this article for more.
</div>

This page is a detailed tutorial to help new users understand and using bitcoin. After you read this page, you'll know the basics of what bitcoin is and how it is structured, how to get and install the bitcoin client, where to get coins, and how to use the client to send and receive transactions.

If you want to ignore all the details of how the system works, and just want to start using it, see the [[Getting started]] page instead.

=What is Bitcoin=

Bitcoin is a distributed [[digital currency]] based on strong cryptographic principles. Each coin is assigned to the owner's public key, and is transferrable via cryptographically signed messages.

=Getting started=

In this section, you'll learn where to get the client, how to install it on different operating systems, and download the [[block chain]].

==Download and install the client==

First, download the bitcoin client from http://bitcoin.org/. Choose the appropriate link depending on your operating system, and install in the usual manner. For Windows, easiest is probably the executable installer. For Linux, note that the tar.gz contains the binary build, in addition to the source, so if you run a recent distribution, you should be able to just run the binary without compiling yourself.

===Issues with Linux package repositories===
Be warned that the version of Bitcoin Core in some package repositories are severely out of date and may be harmful to use. For Debian, users should use [https://packages.debian.org/source/unstable/bitcoin the package from the 'unstable' repository]. For Ubuntu and derivatives, please use the PPA link [https://bitcoin.org/en/download on bitcoin.org]. Please see [https://launchpad.net/+help-soyuz/ppa-sources-list.html this guide] for details on how to use the PPA. You can also choose to use the static binary or to compile from source (both are in the 'tgz' file on the bitcoin.org download page), although updates will not be automated. Please refer to [https://bitcoin.org/en/download this page] for the latest version number.

==Starting the client and connecting to the network==

[[File:First time run fin.png|400px|thumb|right|Bitcoin is initializing by establishing a connection to other clients and downloading the blocks.]]
Bitcoin comes with a GUI client called "bitcoin", and a CLI (text-mode) client called "bitcoind". It is probably more user-friendly to start with the GUI, so launch the bitcoin client.

When you start for the first time, your bitcoin wallet will be created automatically, and the client will attempt to establish connections to other nodes on the network and start downloading the bitcoin [[block chain]]. You must get all of the blocks in the chain before sending/receiving transactions. [http://blockexplorer.com/q/getblockcount Click here] to see the current number of blocks in the chain. This download may take as long as several hours.

==Client features==

Your starting bitcoin address (you can have as many as you want - we'll talk about [[#Bitcoin addresses|addresses]] later) shows in a text box at the top. Right below it is your total bitcoin balance, which, of course, to start with will be zero. There is a list box below it showing all your transactions, which can be variously filtered with tabs, which again will be empty to start with.

The status bar at the bottom will display some important information. If you have [[#Generating bitcoins|bitcoin generation (block hashing)]] turned on, on the left the client will display your hash rate. To the right of that, you will see the number of bitcoin nodes your client is connected to, then, the number of blocks your client has in its chain, and finally, the number of transactions you have in your wallet.

=Using bitcoin=

In this section you will learn about bitcoin addresses, sending and receiving transactions, the block chain and transaction confirmations, where to get your first bitcoins (faucet), generation. Tips on keeping wallet safe.

==Getting your first bitcoins==

There are few things more exciting than getting your first bitcoins! So once you have all the blocks downloaded, head on over to the [https://freebitcoins.appspot.com/ bitcoin faucet], fill out the form and put in your bitcoin address, and receive some free bitcoin! (You can do this before finishing the block chain download, but you won't see the coins in your wallet until you finish downloading the blocks... which would put a damper on the whole excitement bit.)

See [http://en.bitcoin.it/wiki/Trade#Samples_and_Marketing_Offers Samples and Marketing Offers] for other free bitcoins and marketing offers.

Once you submit the form successfully, you should see a new transaction in your client within seconds. But it will be grayed out, and have 0/unconfirmed status:
[[File:First btc recv.png|frame|none]]

Once your transaction makes it into the block chain, the confirmation count will grow in step with the number of blocks in the chain. By default, the client stops showing "unconfirmed" after the transaction is 6 blocks deep in the chain:
[[File:Six confirms bitcoin client.png|frame|none]]

==Transaction confirmations==

write about [[Blocks|blocks]] and [[Confirmation|confirmations]] here.

thanks to the [[Block chain|block chain]], you don't need to be online for receiving BTC...

==Bitcoin addresses==

You can create as many new addresses as you like. Using a different address each time helps to preserve your [[anonymity]].

You cannot send BTC to an invalid address. Client will refuse to send payment to a misspecified address. (Though with care you can craft a valid but nonexistent address.)




==Generating bitcoins==

In order to generate bitcoins, you will need to perform bitcoin [[mining]]. As of 2013, the competition for bitcoin mining has become intense, so you are unlikely to achieve much without specialized hardware.

=See also=

* [[Getting started]] A brief tutorial for the impatient

[[Category:Introduction]]