Bitcoin Wiki - User contributions [en]

Genesis block

2011-05-30T07:16:04Z

Simapple:

{{stub}}

A '''genesis block''' is the first block of a [[block chain]]. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1.

== Main network genesis block ==
[http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f The block on Bitcoin Block Explorer]

Here is a representation of the genesis block as it appeared in a comment in an old version of Bitcoin ([http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/main.cpp?revision=133&view=markup&pathrev=170 line 1613]). The first section defines exactly all of the variables necessary to recreate the block. The second section is the block in standard printblock format, which contains shortened versions of the data in the first section.

GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime = 1231006505
block.nBits = 0x1d00ffff
block.nNonce = 2083236893

CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
vMerkleTree: 4a5e1e

The coinbase parameter (seen above in hex) contains, along with the normal data, the following text<ref>[http://uk.reuters.com/article/idUKPTIP32510920090103 Reuters' reference on The Financial Times article]</ref>:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This was probably intended as proof that the block was created on or after January 3rd, 2009, as well as a comment on the instability caused by fractional-reserve banking.

The first 50BTC block reward went to [[address]] [http://blockexplorer.com/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa] and has yet to be spent (2011-03-04).

==Notes==
<references/>

[[zh-cn:创世block]]

Genesis block

2011-05-30T07:14:24Z

Simapple:

{{stub}}

A '''genesis block''' is the first block of a [[block chain]]. Modern versions of Bitcoin assign it block number 0, though older versions gave it number 1.

== Main network genesis block ==
[http://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f The block on Bitcoin Block Explorer]

Here is a representation of the genesis block as it appeared in a comment in an old version of Bitcoin ([http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/main.cpp?revision=133&view=markup&pathrev=170 line 1613]). The first section defines exactly all of the variables necessary to recreate the block. The second section is the block in standard printblock format, which contains shortened versions of the data in the first section.

GetHash() = 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
hashMerkleRoot = 0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
txNew.vin[0].scriptSig = 486604799 4 0x736B6E616220726F662074756F6C69616220646E6F63657320666F206B6E697262206E6F20726F6C6C65636E61684320393030322F6E614A2F33302073656D695420656854
txNew.vout[0].nValue = 5000000000
txNew.vout[0].scriptPubKey = 0x5F1DF16B2B704C8A578D0BBAF74D385CDE12C11EE50455F3C438EF4C3FBCF649B6DE611FEAE06279A60939E028A8D65C10B73071A6F16719274855FEB0FD8A6704 OP_CHECKSIG
block.nVersion = 1
block.nTime = 1231006505
block.nBits = 0x1d00ffff
block.nNonce = 2083236893

[[zh-cn:创世block]]
CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
vMerkleTree: 4a5e1e

The coinbase parameter (seen above in hex) contains, along with the normal data, the following text<ref>[http://uk.reuters.com/article/idUKPTIP32510920090103 Reuters' reference on The Financial Times article]</ref>:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This was probably intended as proof that the block was created on or after January 3rd, 2009, as well as a comment on the instability caused by fractional-reserve banking.

The first 50BTC block reward went to [[address]] [http://blockexplorer.com/address/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa] and has yet to be spent (2011-03-04).

==Notes==
<references/>

Block

2011-05-30T06:41:52Z

Simapple:

Data is permanently recorded in the Bitcoin network through '''blocks'''. Each block contains all recent [[transactions]], a [[nonce]] (random number), and the [[hash]] of the previous block. A block is "solved" (published and considered valid by peers) when the SHA-256 hash of the entire block is below the current [[target]]. This is very unlikely to occur after being hashed only once, so the nonce must be incremented and the block re-hashed millions of times until it does.

Bitcoin transactions are broadcast to the [[network]] by the sender, and all peers generating coins collect them and add them to the block they're working on. If the transaction is much larger than the average transaction size, a small [[transaction fee]] may be charged.

The first transaction in the block is special: it creates new [[Bitcoins]] for the person who generated it. Other peers will only accept the block if this transaction is of the correct amount. The number of [[Bitcoins]] generated per block starts at 50 and is halved every 210,000 blocks (about four years).

The network tries to create 6 blocks per hour. Every 2016 blocks (about two weeks), all Bitcoin clients compare the actual number created with this goal and modify the target by the percentage that it varied. This increases (or decreases) the difficulty of generating blocks.

The client accepts the 'longest' chain of blocks as valid. The 'length' of the entire [[block chain]] refers to the chain with the most combined difficulty, not the one with the most blocks. This prevents someone from forking the chain and creating a large number of low-difficulty blocks, and having it accepted by the network as 'longest'.

== Common Questions about Blocks ==

=== How many blocks are there? ===
[http://blockexplorer.com/q/getblockcount Current block count]

=== What is the maximum number of blocks? ===
There is no maximum number, blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

==== Even when all 21 million coins have been generated? ====
Yes. The blocks are for proving that transactions existed at a particular time. Transactions will still occur once all the coins have been generated, so blocks will still be created as long as people are trading Bitcoins.

=== How long will it take me to generate a block? ===
No-one can say exactly. There is a [[Generation Calculator|generation calculator]] that will tell you how long it '''might''' take.

=== What if I'm 1% towards calculating a block and...? ===
There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

=== Where can I find more technical detail? ===
There is more technical detail on the [[block hashing algorithm]] page.

==See Also==

* [http://en.bitcoin.it/wiki/File:Total_bitcoins_over_time_graph.png Total Bitcoins Over Time]

{{fromold|block}}

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

[[fr:Blocs]][[zh-cn:Block]]

Category:Mining

2011-05-30T06:39:08Z

Simapple:

Reprinted from the [[How_bitcoin_works#Bitcoin_mining|How Bitcoin works]] page:

== High Level Description ==
'''Mining''' bitcoins is the process of generating [[blocks]] for the [[block chain]], which is a way of processing and verifying [[transactions]]. Adding a block to the block chain is difficult, requiring time and processing power to accomplish. So what incentive does anyone have to spend the effort to produce a block, if it takes up all these resources? The answer is that the person who manages to produce a block gets a reward. This reward is two-fold. First, the block producer gets a bounty of some number of bitcoins, which is agreed-upon by the network. (Currently this bounty is 50 bitcoins; this value will halve every 210,000 blocks.) Second, any transaction fees that may be present in the transactions included in the block, get claimed by the block producer.

This gives rise to the activity known as "bitcoin mining" - using processing power to try to produce a valid block, and as a result 'mine' some bitcoins. The network rules are such that the difficulty is adjusted to keep block production to approximately 1 block per 10 minutes. Thus, the more miners engage in the mining activity, the more difficult it becomes for each individual miner to produce a block. The higher the total difficulty, the harder it is for an attacker to overwrite the tip of the block chain with his own blocks (which enables him to double-spend his coins. See the [[weaknesses]] page for more details).

Besides being important for maintaining the transaction database, mining is also the mechanism by which bitcoins get created and distributed among the people in the bitcoin economy. The network rules are such that over the next hundred years, give or take a few decades, a total of 21 million bitcoins will be created. Rather than dropping money out of a helicopter, the bitcoins are awarded to those who contribute to the network by creating blocks in the block chain.
[[zh-cn:Category:开采]]

User:Simapple

2011-05-29T11:01:25Z

Simapple: Created page with "bitcoin: 1CLPyRuKK8wLDsG9C2Avuerc54fjYjfWbi zh-cn:User:Simapple"

bitcoin: 1CLPyRuKK8wLDsG9C2Avuerc54fjYjfWbi
[[zh-cn:User:Simapple]]

API reference (JSON-RPC)

2011-05-29T10:37:01Z

Simapple:

== Controlling Bitcoin ==

Run ''bitcoind'' or ''bitcoin -server''. You can control it via the command-line or by [http://json-rpc.org/wiki/specification| HTTP JSON-RPC] commands.

You must create a bitcoin.conf configuration file setting an rpcuser and rpcpassword; see [[Running Bitcoin]] for details.

Now run:
$ ./bitcoind
bitcoin server starting
$ ./bitcoind help
# shows the help text

A [[Original Bitcoin client/API Calls list|list of RPC calls]] will be shown.

$ ./bitcoind getbalance
2000.00000

== JSON-RPC ==

Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a [http://json-rpc.org/wiki/specification| HTTP JSON-RPC] server, but
[http://en.wikipedia.org/wiki/Basic_access_authentication Basic access authentication] must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'.

Bitcoin supports SSL (https) JSON-RPC connections beginning with version 0.3.14. See the [[Enabling SSL on original client daemon|rpcssl wiki page]] for setup instructions and a list of all bitcoin.conf configuration options.

To access the server you should find a [http://json-rpc.org/wiki/implementations|suitable library] for your language.

== Proper money handling ==

See the [[Proper Money Handling (JSON-RPC)|proper money handling page]] for notes on avoiding rounding errors when handling bitcoin values.

== Python ==

[http://json-rpc.org/wiki/python-json-rpc python-jsonrpc] is the official JSON-RPC implementation for Python.
It automatically generates Python methods for RPC calls.
However, due to its design for supporting old versions of Python, it is also rather inefficient.
[[User:jgarzik|jgarzik]] has forked it as [https://github.com/jgarzik/python-bitcoinrpc Python-BitcoinRPC] and optimized it for current versions (at least Python 2.6+, though not 3.x).
Generally, this version is recommended.

While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:

<source lang="python">
from jsonrpc import ServiceProxy

access = ServiceProxy("http://user:password@127.0.0.1:8332")
access.getinfo()
access.listreceivedbyaddress(6)
#access.sendtoaddress("11yEmxiMso2RsFVfBcCa616npBvGgxiBX", 10)
</source>

== Ruby ==

<source lang="ruby">
=begin
Make sure to do:
gem install rest-client

Usage:
h = ServiceProxy.new('http://user:password@127.0.0.1:8332')
puts h.getinfo.call
puts h.getbalance.call 'accname'
=end
require 'json'
require 'rest_client'

class JSONRPCException < RuntimeError
def initialize()
super()
end
end

class ServiceProxy
def initialize(service_url, service_name=nil)
@service_url = service_url
@service_name = service_name
end

def method_missing(name, *args, &block)
if @service_name != nil
name = "%s.%s" % [@service_name, name]
end
return ServiceProxy.new(@service_url, name)
end

def respond_to?(sym)
end

def call(*args)
postdata = {"method" => @service_name, "params" => args, "id" => "jsonrpc"}.to_json
respdata = RestClient.post @service_url, postdata
resp = JSON.parse respdata
if resp["error"] != nil
raise JSONRPCException.new, resp['error']
end
return resp['result']
end
end
</source>

== PHP ==

The [http://jsonrpcphp.org/ JSON-RPC PHP] library also makes it very easy to connect to Bitcoin. For example:

<source lang="php">
require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<pre>\n";
print_r($bitcoin->getinfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";
</source>

== Java ==

The easiest way to tell Java to use HTTP Basic authentication is to set a default Authenticator:

<source lang="java">
final String rpcuser ="...";
final String rpcpassword ="...";

Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication (rpcuser, rpcpassword.toCharArray());
}
});
</source>

Once that is done, any JSON-RPC library for Java (or ordinary URL POSTs) may be used to communicate with the Bitcoin server.

== Perl ==

The JSON::RPC package from CPAN can be used to communicate with Bitcoin. You must set the client's credentials; for example:

<source lang="perl">
use JSON::RPC::Client;
use Data::Dumper;

my $client = new JSON::RPC::Client;

$client->ua->credentials(
'localhost:8332', 'jsonrpc', 'user' => 'password' # REPLACE WITH YOUR bitcoin.conf rpcuser/rpcpassword
);

my $uri = 'http://localhost:8332/';
my $obj = {
method => 'getinfo',
params => [],
};

my $res = $client->call( $uri, $obj );

if ($res){
if ($res->is_error) { print "Error : ", $res->error_message; }
else { print Dumper($res->result); }
} else {
print $client->status_line;
}
</source>

== .NET (C#) ==
The communication with rpc service can be achieved using the standard httprequest/response objects.
A library for serialising and deserialising Json will make your life a lot easier:

* JayRock for .NET 4.0
* Json.Net for .NET 2.0 and above

The following example uses Json.Net:

<source lang="csharp">
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("http://localhost.:8332");
webRequest.Credentials = new NetworkCredential("user", "pwd");
/// important, otherwise the service can't desirialse your request properly
webRequest.ContentType = "application/json-rpc";
webRequest.Method = "POST";

JObject joe = new JObject();
joe.Add(new JProperty("jsonrpc", "1.0"));
joe.Add(new JProperty("id", "1"));
joe.Add(new JProperty("method", Method));
// params is a collection values which the method requires..
if (Params.Keys.Count == 0)
{
joe.Add(new JProperty("params", new JArray()));
}
else
{
JArray props = new JArray();
// add the props in the reverse order!
for (int i = Params.Keys.Count - 1; i >= 0; i--)
{
.... // add the params
}
joe.Add(new JProperty("params", props));
}

// serialize json for the request
string s = JsonConvert.SerializeObject(joe);
byte[] byteArray = Encoding.UTF8.GetBytes(s);
webRequest.ContentLength = byteArray.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();

WebResponse webResponse = webRequest.GetResponse();

... // deserialze the response
</source>

== Command line (cURL) ==

You can also send commands and see results using [http://curl.haxx.se/ cURL] or some other command-line HTTP-fetching utility; for example:

<source lang="bash">
curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }'
-H 'content-type: text/plain;' http://127.0.0.1:8332/
</source>

You will be prompted for your rpcpassword, and then will see something like:

<source lang="javascript">
{"result":{"balance":0.000000000000000,"blocks":59952,"connections":48,"proxy":"","generate":false,
"genproclimit":-1,"difficulty":16.61907875185736,"error":null,"id":"curltest"}
</source>

== See Also==

* [[Original_Bitcoin_client/API_Calls_list|API calls list]]
* [[Running Bitcoin]]
* [[Lazy API]]

[[Category:Articles using content from the old wiki]]
[[Category:Technical]]
[[Category:Developer]]
[[zh-cn:API_reference_(JSON-RPC)]]

Securing your wallet

2011-05-29T10:35:05Z

Simapple:

==Introduction==

Wallet security can be broken down into two independent goals:
# Protecting your wallet against loss.
# Protecting your wallet against theft.

In the case that your current wallet hasn't been protected adequately (e.g. put online with a weaker password):
# Making a new secure wallet, using appropriate long-term protection.

==Technical Background==

Bitcoin transactions send Bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received Bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.

The wallet contains a pool of queued keys. By default there are 100 keys in the [[key pool]]. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins.

Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.

The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends some number of Bitcoins back to yourself at a new key. When sending Bitcoins to anyone, you generate a new keypair for yourself and simultaneously send Bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature – it makes tracking Bitcoin transactions much more difficult.

So if you create a backup, do more than 100 things that cause a new key to be used, and then restore from the backup, some Bitcoins will be lost. Bitcoin has not deleted any keys (keys are never deleted) – it has created a new key that is not in your old backup and then sent Bitcoins to it.

== Making a new wallet ==

In the case that a wallet has been distributed, or stored, in a (real or potential) compromised state, it is wise to create a new wallet and transfer the full balance of Bitcoins to an address contained only in the newly created wallet.

For example, this will be necessary if one created a wallet with a password of 12 characters, as suggested. However a few years have passed and the wallet is now more easily compromised. Just re-encrypting isn't secure. One needs to make a new wallet and make the old wallet worthless (spending the funds to the new wallet).

==Making a secure workspace==

===Linux===

The first step is to make a [http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ new user,] so type:

sudo adduser new_user_name

when you get to the prompt 'Enter the new value, or press ENTER for the default', just keep hitting ENTER.

Then switch user to the new user. To get to the new user you can use the switch user icon for your system, which on Ubuntu is in the 'System/Quit' screen, or if there is no switch icon on your system you can log out and log back in as the new user. Then click on a folder in the new user to display the file browser, then keep going up folders until you see the new user home directory, then right click to bring up the Properties dialog, then click on the Permissions tab, then in the Others section, set the folder access to None.

For secure browsing, open Firefox, and then go into the Edit menu and click Preferences. Starting from the left, click on the General tab, and in the 'Startup/When Firefox starts' pop up menu, choose 'Show a Blank Page'. Then click on the Content tab, and deselect 'Load images automatically' and deselect 'Enable Javascript'. Then click on the Privacy tab, and in the 'History/Firefox will' pop up menu, choose 'Never remember history'. Then click on the Security tab, and in the Passwords section, deselect 'Remember passwords for sites' and deselect 'Use a master password'. Then click on the Advanced tab, then click on the Update tab, and then in the 'Automatically check for updates to' section, deselect 'Add-ons' and 'Search Engines'.

When javascript is disabled, the [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/bitcoin-0.3.19-linux.tar.gz/download linux download page] will not download automatically, so you'll have to click on the 'direct link' part of the "Problems with the download? Please use this 'direct link' or try another mirror." line.

After you've made your secure new user, to maintain security you should use it only for bitcoin.

===Mac===

You can keep your wallet file on an encrypted disk image. Open Disk Utility, click New Image, choose small size (eg. 100MB), 128-bit or 256-bit (faster or more secure) encryption and single partition. Save it somewhere you won't lose it (like your Dropbox, Strongspace or whatever), choose a safe password and there you have it. Move everything from ~/Library/Application Support/Bitcoin/ to the image and symlink it back so the app would be able to use it, eg.

ln -s /Volumes/Bitcoin ~/Library/Application Support/Bitcoin

Don't forget to mount your image before using Bitcoin and unmount after quitting it.

== Locating BitCoin's data directory ==

The [[data directory]] is the location where Bitcoin's data files are stored, including the wallet data file.

=== Windows ===

Go to Start -> Run (or press WinKey+R) and run this:

explorer %APPDATA%\BitCoin

BitCoin's data folder will open. For most users, this is the following locations:

C:\Documents and Settings\YourUserName\Application data\BitCoin (XP)

C:\Users\YourUserName\Appdata\Roaming\BitCoin (Vista and 7)

"AppData" and "Application data" are hidden by default.

=== Linux ===

By default BitCoin will put its data here:

~/.bitcoin/

You need to do a "ls -a" to see directories that start with a dot.

If that's not it, you can do a search like this:

find / -name wallet.dat -print 2>/dev/null

=== Mac ===

By default BitCoin will put its data here:

~/Library/Application Support/Bitcoin/

==Backup==

The only file you need to back up is "wallet.dat". Ensure that BitCoin is closed, copy this file somewhere else, encrypt it, and put it somewhere safe. Ideally, you would put this file in two places: one nearby, and one 100+ miles away.

You can use the [[api|backupwallet]] JSON-RPC command to back up without shutting down Bitcoin.

=== General Solutions ===

Your wallet.dat file is not encrypted by BitCoin. Anyone who can access it can easily steal all of your coins. Use one of these encryption programs if there is any chance someone might stumble upon your wallet.
* [http://www.7-zip.org/ 7-zip] - Supports strongly-encrypted archives.
* [http://www.axantum.com/axcrypt/ AxCrypt]
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly encryption (for advanced users)
* [http://www.rarlab.com/ WinRar] - Commonly used archive software that supports verification records and encryption.

There is also a list of [[OpenSourceEncryptionSoftware|open source encryption software.]]

==== Password Strength ====
Brute-force password cracking has come a long distance, a previously thought secure password of random [a-Z] [0-9] [!-~] of 8 characters long can be trivially solved now (using appropriate hardware)... The recommended length is '''at least''' 12 characters long.

If you use keyfiles in addition to a password, it is unlikely that your encrypted file can ever be cracked using brute force methods, even 10 years from now when even a 12 character password might be too short.

Assume that any encrypted files you store online (eg. gmail, Dropbox) will be stored somewhere forever and can never be erased.

==== Storage of Archive ====
One of the most simple methods for storing a appropriately '''encrypted''' archive of your wallet.dat file is to send the archive as an email attachment to your own e-mail address. Services like gmail.com use very comprehensive distributed networks that make the loss of data very unlikely. One can even obfuscate the name of the files within the archive, and name the archive something less inviting, such as: 'personal notes' or 'car insurance'.

Another solution is to use a file storage service like [http://www.wuala.com/bitcoin Wuala] ( encrypted, [http://www.bitcoin.org/smf/index.php?topic=5817.0 instructions]), [http://www.dropbox.com Dropbox] and [http://en.wikipedia.org/wiki/Comparison_of_online_backup_services others], including the more secure [http://www.spideroak.com SpiderOak].

=== Linux solution ===

Linux users can setup cron by running 'crontab -e' and adding this line:

01 */1 * * * /usr/local/bin/backupwallet.sh

This cron line runs backupwallet.sh at the 01 minute of every hour. Remember to add a newline after the last line of the crontab file, or else the last line won't run.

backupwallet.sh:

#!/bin/bash

TS=$(date "+%Y%m%d-%H-%M")
WALLET=/tmp/wallet${TS}
WALLET_E=/tmp/wallet${TS}.crypt

if
echo -n making backup...
bitcoind backupwallet $WALLET
<nowiki>[[ ! -s "$WALLET" ]]</nowiki>
then echo failed
elif
echo done
echo -n encrypting....
! gpg -r myusername --output $WALLET_E --encrypt $WALLET
then echo failed
elif
echo done
echo -n copying to distant server...
! scp $WALLET_E user@myserver.org:~/wallets/
then echo failed
else echo done
fi

rm -f $WALLET $WALLET_E

The shell script:

* Calls bitcoind backupwallet to create a time/date-stamped wallet.
* GPG encrypts the wallet with your public key.
* Copies the result to a backup location.

[[Category:Technical]]

==Restore==

Assuming your backup is recent enough that you haven't used up all of your key pool... restoring a wallet to a new (or old) location and rescanning the block chain should leave you with all your coins. Just follow these steps:
* Quit bitcoin(d).
* Copy your backed up wallet.dat into your bitcoin profile directory.
* If copying into existing profile, delete file ''blkindex.dat'', to make the client rescan the block chain.
And you'll be good as new.

==Erasing Plain Text Wallets==

A good practice is to keep at least two wallets, one as a "current account" for everyday transactions and one as a "savings account" where you store the majority of your Bitcoins.

The "savings account" wallet should be backed up in encrypted form only and all plaintext copies of this wallet should be erased. In case someone gains unauthorised access to your computer (either by physically stealing it or by exploiting a system vulnerability via the internet), they will only be able to spend the coins in your "current account" wallet.

In most operating systems, including Windows, Linux, and Mac OS X, simply deleting a wallet.dat file will ''not'' generally destroy it. It is likely that advanced tools can still be used to recover the wallet.dat file, even after it has been deleted.

The Linux '''shred''' command can be used to overwrite the wallet file with random data prior to deleting; this particular copy of the file will then be practically impossible to recover. Using shred (and similar tools on Windows) however does not guarantee that still other copies don't exist somewhere hidden on your HD. That will depend on your system configuration and what packages you have installed. Some system restore and backup tools, for instance, create periodic snapshots of your filesystem, duplicating your wallet.dat.

In Mac OS, clicking "Secure Empty Trash" in the Finder menu will shred the contents of the trash can. As with any OS this doesn't guarantee that there are not other copies elsewhere on your system.

For Windows, the built-in command ''cipher /W'' will shred all previously-deleted files. [http://www.cylog.org/utilities/cybershredder.jsp CyberShredder] can securely deleted individual files.

==eWallet==

Storing bitcoins with an [[eWallet]] provider incurs risks as well.

==See Also==

* [[Data directory]]

[[de:Sichere deine Geldbörse]]
[[zh-cn:保护你的钱包]]

Help:Installing Bitcoin Core

2011-05-29T10:33:42Z

Simapple:

An account can effortlessly be created using an [[eWallet]] service. eWallet services provide an online wallet to hold your bitcoins.

This guide covers installing Bitcoin without needing a third party wallet service.

== For Windows computers ==

=== Installation ===
[http://sourceforge.net/projects/bitcoin/ Download] and install Bitcoin.

[[File:Install fin.png|frame|none|Complete installation wizard]]

=== Initialization ===

The first time you run Bitcoin, it needs to download all the blocks to setup. You already have your bitcoin address at this point, but you won't see any transactions before the initialisation is complete (it can take from half to a few hours).

[[File:First time run fin.png|frame|none|Bitcoin is initialising by establishing a connection to other clients and downloading the blocks.]]

[[File:Bitcoin all blocks fin.png|frame|none|Completed download of block-chain.]]

Your address (you can have as many as you want) is at the top. Below is your balance which will be zero. The list below shows your transactions.

== For Mac computers ==

Download the [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/bitcoin-0.3.19-macosx.zip/download OS X version] of Bitcoin and expand the archive.

[[File:BcOSX.png|thumb|none|Contents of the Bitcoin archive after expansion]]

Drag the Bitcoin icon to the desired install location, and double-click or Cmd-O (⌘O) to run the application. The Bitcoin window will open and connections will start up in minutes. The blocks will begin downloading. Your address and balance are at the top of the window. Click "Copy to Clipboard" to copy your address. Transactions are displayed in the main window.

[[File:BcOSXrunning.png|thumb|none|Main window]]

As Bitcoin currently does not support hiding with Cmd-H (⌘H), it is recommended that users tick the "Minimize on close" option in the Preferences menu to prevent accidental program exits.

[[File:BcOSXPreferences.png|thumb|none|Preferences window on OS X]]

== Getting my first coins ==

The [[Bitcoin Faucet]] [https://freebitcoins.appspot.com/ website] currently hands out 0.02 BTC to new bitcoin users. Fill in the form with your bitcoin address. When you wish to add more, view [[Buying bitcoins]].

[[File:Get some btc.png|frame|none|Getting free coins from the Faucet]]

A new entry should appear in Bitcoin. The network hasn't yet confirmed it, but you know it's being processed. After about one hour it should get 6 confirmations. You are able to spend the coins when there is only one confirmation.

The confirmation counter (like the block counter) will increase by one roughly every 10 minutes. Six confirmations are considered as 100% sure a transfer has been processed.

[[File:First btc recv.png|frame|none]]

[[File:Six confirms bitcoin client.png|frame|none]]

* Play games and enter your first raffle at http://bitgames.jhfire.net!
* Create an account on witcoin and post something (cost 0.01 BTC): http://www.witcoin.com (click "get wit it" to create an account) If your post is any good, you can earn when it gets replies and votes.
* Give a tip to a deserving artist, writer, etc. on YouTipIt.org. For instance, this video creation is worth 0.05 BTC, no?: http://www.youtipit.org/t/2652
* Give lady luck a shot? Double Trouble (49% chance of doubling your money) http://doubletrouble.bitcoinbet.com
* Give to any of the charities on Bitcoin Trade page: http://en.bitcoin.it/wiki/Trade#Donation-accepting_organizations_and_projects

== Points to remember ==

* You don't need to be online to receive BTC.
* You can create as many new addresses as you like. Using a different address each time helps keep you [[Anonymity|anonymous]].
* You can be [[Anonymity|anonymous]] with adequate precautions.
* You cannot send BTC to an invalid address. Typos are not a worry as the payment will refuse to send.
* The 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 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]]

Proceed to the [[Introduction|introduction]]

== Technical ==
=== Block chain ===
The [[block chain]] is a neverending 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 a coin, you are actually sending a cryptographically signed message, associating your coin with the recipient's address. This effectively transfers ownership to to the recipient. Once they own the coin, 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; having more addresses makes you more anonymous, because then people cannot see how much BTC 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 the wallet then you no longer possess the money.

=== Generating ===
New coins are minted through generating hashes. These generators are rewarded with a small fee for the computationally intensive task of incorporating your transactions into the block-chain. This fee halves each time 210000 blocks are added to the block chain, or approximately every 4 years. The fee will keep halving until it effectively reaches zero, at which point 21 million coins will be in circulation.

[[Category:Introduction]]

[[de:Erste Schritte]]
[[zh-cn:入门]]

Secure Trading

2011-05-29T10:32:43Z

Simapple:

''Secure Trading Online''

This topic is a guide in how to set up your online identity and best practices for trading with others in the Bitcoin community.

==Introduction==
Within the Bitcoin community, many are very careful with their security and identity. This is because of two main reasons:
# There is no violent body to cover your back for you. Or more simply there is no courts to seek assistance from if your transaction sours.
# One’s reputation is the most important thing that any user has; traders will take very little risk with new users who have not proven themselves. (as they could just be last week’s scammer with a new identity)
The bitcoin community uses a few tools to help protect their privacy, and thus identity. The first and most important is a [[Securing Your Computer|Secure Computer]]. 

'''Before proceeding please make sure you have completed the [[Securing Your Computer]] guide, this guide assumes that your computer is secure both physically and in software.'''

==Creating a secure Identity==
The first step is to create a cryptographically secure public-private key-pair. This will be used as the basis of keeping both your wallet secure (see [[Securing your wallet]]), and your identity secure.

===Creating your first PGP key-pair===
A PGP key-pair does two very important functions.
# Sign information with an unforgeable signature
# Decrypt things that other people encrypt for you

This allows you to both conduct business privately (encryption), and give out promises that you cannot deny making (signature).

==== Microsoft Windows:====
* Install GPG4Win: http://www.gpg4win.org/ 

This contains all the key management and generation tools for Microsoft Windows.

====All:====
# Install Thunderbird: https://www.mozillamessaging.com/en-GB/
# Setup your email account with Thunderbird.
# Install the Enigmail plugin for Thunderbird: https://addons.mozilla.org/en-US/thunderbird/addon/enigmail/ 

Upon loading Enigmail, Thunderbird will ask you to make a new ‘identity,’ follow this wizard and you will have created your identity. 
You should backup your private key in a secure place. Secondary, you should create a revocation certificate and store that in a different secure place (maybe print it out and store it in your fire safe).

===Register with [#bitcoin-otc]===
Follow the guide here: http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc

===Register the same username at the popular places:===
* [[Bitcoin Forum]]
* [[Bitcoin.it_Wiki|Bitcoin Wiki]]
* [[Bitcoin:Community_portal#IRC_Chat|Freenode IRC]]
Use a strong and different password for each of these places, keeping your passwords in a secure place. This will allow other people in the community to track you across the different Bitcoin related sites. Also making identity theft online more challenging.

==Best Practices with trading==
===Use Bitcoin-OTC===
* Always require the user to become registered with #bitcoin-otc.
* Require a signed message from the fingerprint quoted at: http://bitcoin-otc.com/viewgpg.php
* Follow additional [http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc#Risk_of_fraud recommendations] for avoiding fraud.

===Make sure both parties agree to the terms of the trade with signed messages===
* Get a PGP signed quote, and check the signature.
* Send a PGP signed receipt.
This allows either party to go public if the trade has become sour and stops your trading partner from claiming the details of the agreement were somehow different. 

Search the Bitcoin Forum for the username of the person that you are trading with. Check if the user has provided constructive and useful advice to other parties. And, most importantly, check for any claims that the user has scammed.

===Use an escrow===
Trading might benefit from an escrow such that bitcoins are disbursed only after contract terms have been met. 

A popular online escrow is [[ClearCoin]].

Found in Bitcoin's community are trusted individuals willing to act as independent, third-party escrow brokers.

[[de:Sicheres_Handeln]]
[[zh-cn:交易安全]]

Protocol documentation

2011-05-29T10:20:00Z

Simapple:

Sources:
* [[Original Bitcoin client]] source
* [http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1 Draft spec on bitcoin wiki]

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

==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 SHA-256, and are built up as so:

sha256(a) sha256(b) sha256(c)
sha256(sha256(a)+sha256(b)) sha256(sha256(c)+sha256(c))
sha256(sha256(sha256(a)+sha256(b))+sha256(sha256(c)+sha256(c)))

They are paired up, with the last element being _duplicated_.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] (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 strings representing the coordinates of a point on the curve. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default).

=== Transaction Verification ===
{{See also|OP_CHECKSIG}}

The first transaction of a block is usually the generating transaction, which do not include any "in" transaction, and generate bitcoins (from fees for example) usually received by whoever solved the block containing this transaction.
Such transactions are called a "coinbase transaction" and are accepted by bitcoin clients without any need to execute scripts, provided there is only one per block.

If a transaction is not a coinbase, it references previous transaction hashes as input, and the index of the other transaction's output used as input for this transaction.
The script from the in part of this transaction is executed.
Then the script from the out part of the referenced transaction is executed.
It is considered valid if the top element of the stack is true.

=== 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)) (not included in version or verack)
|-
| ? || payload || uchar[] || The actual data
|}

The version and verack messages do not have a checksum, the payload starts 4 bytes earlier.

Known magic values:

{|class="wikitable"
! Network !! Magic value
|-
| main || F9BEB4D9
|-
| testnet || FABFB5DA
|}

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

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

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

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 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:10.0.0.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 (Limited to 2106!)
|-
| 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 || uint8_t || Number of transaction entries, this value is always 0
|}

== Message types ==

=== version ===

When a node receives an incoming connection, it will immediately advertise its version. No futher communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || uint64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_me || net_addr || The network address of the node emitting this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_you || net_addr || The network address seen by the node emitting this message (ie, the address of the receiving node)
|-
| 8 || nonce || uint64_t || Node random unique id. This id is used to detect connections to self
|-
| ? || sub_version_num || var_str || Secondary Version information (null terminated?)
|-
|colspan="4"| version >= 209
|-
| 4 || start_height || uint32_t || The last block received by the emitting node
|}

If the emitter of the packet has version >= 209, 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 (note the message header for this version message does not have a checksum):
<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 DA F6 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
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 DA F6 - Sender 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 - Recipient 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>

=== verack ===

The ''verack'' message is sent in reply to ''version'' for clients >= 209. 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 ....

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

=== addr ===

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

Payload (maximum payload length: 1000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || var_int || Number of address entries
|-
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one
|}

'''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 7F 85 39 C2 01 E2 15 10 4D 01 00 00 ......9.....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 .D(.. .

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
7F 85 39 C2 - 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: 50000 bytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || count || var_int || Number of inventory entries
|-
| 36x? || inventory || 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.

Payload (maximum payload length: 50000 bytes):

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

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting at hash_start, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with the last known hash.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (500)
|}

=== getheaders ===

Return a ''headers'' packet containing the headers for blocks starting at hash_start, up to hash_stop or 2000 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getheaders again with the last known hash. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours).

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || start count || var_int || number of hash_start entries
|-
| 32+ || hash_start || char[32] || hash of the last known block of the emitting node
|-
| 32 || hash_stop || char[32] || hash of the last desired block. Set to zero to get as many blocks as possible (2000)
|}

=== 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 || 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 || var_int || Number of Transaction outputs
|-
| 8+ || 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, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).
|}

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 || var_int || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || 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 for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || uint64_t || Transaction Value
|-
| 1+ || pk_script length || 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 timestamp recording when this block was created (Limited to 2106!)
|-
| 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
|-
| ? || txn_count || 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.

=== headers ===

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

Payload:

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

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message 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.

=== checkorder ===

This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.

It contains a CWalletTx object

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
|colspan="4"| Fields from CMerkleTx
|-
| ? || hashBlock
|-
| ? || vMerkleBranch
|-
| ? || nIndex
|-
|colspan="4"| Fields from CWalletTx
|-
| ? || vtxPrev
|-
| ? || mapValue
|-
| ? || vOrderForm
|-
| ? || fTimeReceivedIsTxTime
|-
| ? || nTimeReceived
|-
| ? || fFromMe
|-
| ? || fSpent
|}

=== submitorder ===

Confirms an order has been submitted.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || Hash of the transaction
|-
| ? || wallet_entry || CWalletTx || Same payload as checkorder
|}

=== reply ===

Generic reply for [[IP Transactions]]

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || reply || uint32_t || reply code
|}

Possible values:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')
|-
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed
|-
| 2 || DENIED || IP Transactions are not accepted by this node
|}

=== 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. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.

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

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || message || var_str || System message which is coded to convey some information to all nodes in the network
|-
| ? || signature || var_str || A signature which can be confirmed with a public key verifying that it is Satoshi (the originator of Bitcoins) who has "authorized" or created the message
|}

The signature is to be compared to this ECDSA public key:

04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

Source: [http://www.bitcoin.org/smf/index.php?topic=898.0]

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]