Bitcoin Wiki - User contributions [en]

OP CHECKSIG

2014-04-07T20:24:26Z

Philipkd: sp

OP_CHECKSIG is [[Script|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

For normal transaction inputs if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.

== Parameters ==

In addition to the script code itself and the stack parameters, to operate OP_CHECKSIG needs to know the current transaction and the index of current transaction input.

== How it works ==
Firstly always this (the default) procedure is applied:
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Signature verification process of the default procedure]]
# the public key and the signature are popped from the stack, in that order. If the hash-type value is 0, then it is replaced by the last_byte of the signature. Then the last byte of the signature is always deleted.
# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
# The sig is deleted from subScript.
# All OP_CODESEPARATORS are removed from subScript
# The hashtype is removed from the last byte of the sig and stored
# A copy is made of the current transaction (hereby referred to txCopy)
# The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00)
# The script for the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded!)

Now depending on the hashtype various things can happen to txCopy, these will be discussed individually.

'''Hashtype Values (from script.h):'''
{|class="wikitable"
! Name !! Value
|-
| SIGHASH_ALL || 0x00000001
|-
| SIGHASH_NONE || 0x00000002
|-
| SIGHASH_SINGLE || 0x00000003
|-
| SIGHASH_ANYONECANPAY || 0x00000080
|}

<ol>
<li> If (hashtype&31) = SIGHASH_NONE then apply the SIGHASH_NONE-procedure
<li> If (hashtype&31) = SIGHASH_SINGLE then apply the SIGHASH_SINGLE-procedure
<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure
</ol>
Hence, hashtype SIGHASH_ANYONECANPAY may be applied also after any other hashtype-procedure<ref>[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/bitcoin-0.7.1-linux.tar.gz file src/src/script.cpp in bitcoin-0.7.1]</ref>. Besides the four listed hashtypes only a hashtype of value 0 appears a few types in the (main) block chain (and is handled like SIGHASH_ALL).

=== Hashtype SIGHASH_ALL (default) ===

No special further handling occurs in the default case. Think of this as "sign '''all''' of the outputs." Which is already done by the default procedure.

=== Procedure for Hashtype SIGHASH_NONE ===

# The output of txCopy is set to a vector of zero size.
# All other inputs aside from the current input in txCopy have their nSequence index set to zero

Think of this as "sign '''none''' of the outputs-- I don't care where the bitcoins go."

=== Procedure for Hashtype SIGHASH_SINGLE ===

# The output of txCopy is resized to the size of the current input index+1.
# All other txCopy outputs aside from the output that is the same as the current input index are set to a blank script and a value of (long) -1.
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero.

Think of this as "sign '''one''' of the outputs-- I don't care where the other outputs go".

Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs.
However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001 [https://bitcointalk.org/index.php?topic=260595.0]

=== Procedure for Hashtype SIGHASH_ANYONECANPAY ===

# The txCopy input vector is resized to a length of one.
# The subScript (lead in by its length as a var-integer encoded!) is set as the first and only member of this vector.

Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

== Code samples and raw dumps ==

Taking the first transaction in Bitcoin which is in block number 170, we would get after serialising the transaction but before we hash+sign (or verify) it:

* http://blockexplorer.com/block/00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee
* http://blockexplorer.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

See also [https://gitorious.org/libbitcoin/libbitcoin libbitcoin] for code samples.

<pre>
01 00 00 00 version
01 number of inputs (var_uint)

input 0:
c9 97 a5 e5 6e 10 41 02 input address hash
fa 20 9c 6a 85 2d d9 06
60 a2 0b 2d 9c 35 24 23
ed ce 25 85 7f cd 37 04
00 00 00 00 input index

48 size of script (var_uint)
47 push 71 bytes to stack
30 44 02 20 4e 45 e1 69
32 b8 af 51 49 61 a1 d3
a1 a2 5f df 3f 4f 77 32
e9 d6 24 c6 c6 15 48 ab
5f b8 cd 41 02 20 18 15
22 ec 8e ca 07 de 48 60
a4 ac dd 12 90 9d 83 1c
c5 6c bb ac 46 22 08 22
21 a8 76 8d 1d 09 01
ff ff ff ff sequence

02 number of outputs (var_uint)

output 0:
00 ca 9a 3b 00 00 00 00 amount = 10.00000000
43 size of script (var_uint)
script for output 0:
41 push 65 bytes to stack
04 ae 1a 62 fe 09 c5 f5
1b 13 90 5f 07 f0 6b 99
a2 f7 15 9b 22 25 f3 74
cd 37 8d 71 30 2f a2 84
14 e7 aa b3 73 97 f5 54
a7 df 5f 14 2c 21 c1 b7
30 3b 8a 06 26 f1 ba de
d5 c7 2a 70 4f 7e 6c d8
4c
ac OP_CHECKSIG

output 1:
00 28 6b ee 00 00 00 00 amount = 40.00000000
43 size of script (var_uint)
script for output 1:
41 push 65 bytes to stack
04 11 db 93 e1 dc db 8a
01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48
2e ca d7 b1 48 a6 90 9a
5c b2 e0 ea dd fb 84 cc
f9 74 44 64 f8 2e 16 0b
fa 9b 8b 64 f9 d4 c0 3f
99 9b 86 43 f6 56 b4 12
a3
ac OP_CHECKSIG

00 00 00 00 locktime
01 00 00 00 hash_code_type (added on)

result =
01 00 00 00 01 c9 97 a5 e5 6e 10 41 02 fa 20 9c 6a 85 2d d9 06 60 a2 0b 2d 9c 35
24 23 ed ce 25 85 7f cd 37 04 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49
84 0f 8c 53 bc 1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb
84 cc f9 74 44 64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3
ac ff ff ff ff 02 00 ca 9a 3b 00 00 00 00 43 41 04 ae 1a 62 fe 09 c5 f5 1b 13 90
5f 07 f0 6b 99 a2 f7 15 9b 22 25 f3 74 cd 37 8d 71 30 2f a2 84 14 e7 aa b3 73 97
f5 54 a7 df 5f 14 2c 21 c1 b7 30 3b 8a 06 26 f1 ba de d5 c7 2a 70 4f 7e 6c d8 4c
ac 00 28 6b ee 00 00 00 00 43 41 04 11 db 93 e1 dc db 8a 01 6b 49 84 0f 8c 53 bc
1e b6 8a 38 2e 97 b1 48 2e ca d7 b1 48 a6 90 9a 5c b2 e0 ea dd fb 84 cc f9 74 44
64 f8 2e 16 0b fa 9b 8b 64 f9 d4 c0 3f 99 9b 86 43 f6 56 b4 12 a3 ac 00 00 00 00
01 00 00 00
</pre>

To understand where that raw dump has come from, it may be useful to examine tests/ec-key.cpp in [https://gitorious.org/libbitcoin/libbitcoin libbitcoin],

[https://gitorious.org/libbitcoin/libbitcoin libbitcoin] has a unit test under tests/ec-key.cpp (make ec-key && ./bin/tests/ec-key). There is also a working OP_CHECKSIG implementation in src/script.cpp under script::op_checksig(). See also the unit test: tests/script-test.cpp

<source lang="cpp">
#include <iostream>
#include <iomanip>
#include <bitcoin/util/serializer.hpp>
#include <bitcoin/util/elliptic_curve_key.hpp>
#include <bitcoin/util/sha256.hpp>
#include <bitcoin/util/assert.hpp>
#include <bitcoin/util/logger.hpp>
#include <bitcoin/types.hpp>
#include <openssl/ecdsa.h>
#include <openssl/obj_mac.h>
using libbitcoin::elliptic_curve_key;
using libbitcoin::serializer;
using libbitcoin::hash_digest;
using libbitcoin::data_chunk;
using libbitcoin::log_info;
using libbitcoin::log_fatal;

int main()
{
serializer ss;
// blk number 170, tx 1, input 0
// version = 1
ss.write_4_bytes(1);
// 1 inputs
ss.write_var_uint(1);

// input 0
// prevout hash
ss.write_hash(hash_digest{0x04, 0x37, 0xcd, 0x7f, 0x85, 0x25, 0xce, 0xed, 0x23, 0x24, 0x35, 0x9c, 0x2d, 0x0b, 0xa2, 0x60, 0x06, 0xd9, 0x2d, 0x85, 0x6a, 0x9c, 0x20, 0xfa, 0x02, 0x41, 0x10, 0x6e, 0xe5, 0xa5, 0x97, 0xc9});
// prevout index
ss.write_4_bytes(0);

// input script after running OP_CHECKSIG for this tx is a single
// OP_CHECKSIG opcode
data_chunk raw_data;
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
data_chunk raw_script;
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
raw_script.push_back(172);
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);
// sequence
ss.write_4_bytes(0xffffffff);

// 2 outputs for this tx
ss.write_var_uint(2);

// output 0
ss.write_8_bytes(1000000000);
// script for output 0
raw_data = {0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c};
// when data < 75, we can just write it's length as a single byte ('special'
// opcodes)
raw_script = data_chunk();
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// output 1
ss.write_8_bytes(4000000000);
// script for output 0
raw_data = {0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// when data < 75, we can just write it's length as a single byte ('special'
raw_script.push_back(raw_data.size());
libbitcoin::extend_data(raw_script, raw_data);
// OP_CHECKSIG
raw_script.push_back(172);
// now actually write the script
ss.write_var_uint(raw_script.size());
ss.write_data(raw_script);

// End of 2 outputs

// locktime
ss.write_4_bytes(0);

// write hash_type_code
ss.write_4_bytes(1);

// Dump hex to screen
log_info() << "hashing:";
{
auto log_obj = log_info();
log_obj << std::hex;
for (int val: ss.get_data())
log_obj << std::setfill('0') << std::setw(2) << val << ' ';
}
log_info();

data_chunk raw_tx = {0x01, 0x00, 0x00, 0x00, 0x01, 0xc9, 0x97, 0xa5, 0xe5, 0x6e, 0x10, 0x41, 0x02, 0xfa, 0x20, 0x9c, 0x6a, 0x85, 0x2d, 0xd9, 0x06, 0x60, 0xa2, 0x0b, 0x2d, 0x9c, 0x35, 0x24, 0x23, 0xed, 0xce, 0x25, 0x85, 0x7f, 0xcd, 0x37, 0x04, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0xff, 0xff, 0xff, 0xff, 0x02, 0x00, 0xca, 0x9a, 0x3b, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0xae, 0x1a, 0x62, 0xfe, 0x09, 0xc5, 0xf5, 0x1b, 0x13, 0x90, 0x5f, 0x07, 0xf0, 0x6b, 0x99, 0xa2, 0xf7, 0x15, 0x9b, 0x22, 0x25, 0xf3, 0x74, 0xcd, 0x37, 0x8d, 0x71, 0x30, 0x2f, 0xa2, 0x84, 0x14, 0xe7, 0xaa, 0xb3, 0x73, 0x97, 0xf5, 0x54, 0xa7, 0xdf, 0x5f, 0x14, 0x2c, 0x21, 0xc1, 0xb7, 0x30, 0x3b, 0x8a, 0x06, 0x26, 0xf1, 0xba, 0xde, 0xd5, 0xc7, 0x2a, 0x70, 0x4f, 0x7e, 0x6c, 0xd8, 0x4c, 0xac, 0x00, 0x28, 0x6b, 0xee, 0x00, 0x00, 0x00, 0x00, 0x43, 0x41, 0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3, 0xac, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00};
BITCOIN_ASSERT(raw_tx == ss.get_data());

hash_digest tx_hash = libbitcoin::generate_sha256_hash(ss.get_data());

data_chunk pubkey{0x04, 0x11, 0xdb, 0x93, 0xe1, 0xdc, 0xdb, 0x8a, 0x01, 0x6b, 0x49, 0x84, 0x0f, 0x8c, 0x53, 0xbc, 0x1e, 0xb6, 0x8a, 0x38, 0x2e, 0x97, 0xb1, 0x48, 0x2e, 0xca, 0xd7, 0xb1, 0x48, 0xa6, 0x90, 0x9a, 0x5c, 0xb2, 0xe0, 0xea, 0xdd, 0xfb, 0x84, 0xcc, 0xf9, 0x74, 0x44, 0x64, 0xf8, 0x2e, 0x16, 0x0b, 0xfa, 0x9b, 0x8b, 0x64, 0xf9, 0xd4, 0xc0, 0x3f, 0x99, 0x9b, 0x86, 0x43, 0xf6, 0x56, 0xb4, 0x12, 0xa3};
// Leave out last byte since that's the hash_type_code (SIGHASH_ALL in this
// case)
data_chunk signature{0x30, 0x44, 0x02, 0x20, 0x4e, 0x45, 0xe1, 0x69, 0x32, 0xb8, 0xaf, 0x51, 0x49, 0x61, 0xa1, 0xd3, 0xa1, 0xa2, 0x5f, 0xdf, 0x3f, 0x4f, 0x77, 0x32, 0xe9, 0xd6, 0x24, 0xc6, 0xc6, 0x15, 0x48, 0xab, 0x5f, 0xb8, 0xcd, 0x41, 0x02, 0x20, 0x18, 0x15, 0x22, 0xec, 0x8e, 0xca, 0x07, 0xde, 0x48, 0x60, 0xa4, 0xac, 0xdd, 0x12, 0x90, 0x9d, 0x83, 0x1c, 0xc5, 0x6c, 0xbb, 0xac, 0x46, 0x22, 0x08, 0x22, 0x21, 0xa8, 0x76, 0x8d, 0x1d, 0x09};
BITCOIN_ASSERT(signature.size() == 70);

elliptic_curve_key key;
if (!key.set_public_key(pubkey))
{
log_fatal() << "unable to set EC public key";
return -1;
}

log_info() << "checksig returns: " << (key.verify(tx_hash, signature) ? "true" : "false");
return 0;
}

</source>

==References==
<references/>

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

Original Bitcoin client

2014-04-04T17:08:19Z

Philipkd: made linguistically smoother

The '''Satoshi client''' or the '''Satoshi code''' refers to [[bitcoind]], bitcoin-client, and bitcoin-qt. This is in honor of [[Satoshi Nakamoto]] for creating [[Bitcoin]].
<dl>
<dt>In the most widest sense:
<dd>All releases of bitcoin-x.y.z (starting 2009) and future official releases of the [http://bitcoin.org bitcoin-developer community].<br> (Last/newest when writing this remark is of release 0.7.2 in December 2012).
<dt>In the narrow sense:
<dd>Only the bitcoin releases up to version 0.3.19 which Satoshi Nakamoto himself was chief and main developer. He retired afterwards (end of 2010) completely from this project. With the next release also [[Testnet]] was reseted with a new Genesis block.
<dt>Original Satoshi clients:
<dd>Only the bitcoin releases 0.1.0 up to 0.1.5 which supported only Windows 2000 / Windows NT and Windows XP (perhaps Windows Vista). The next bitcoin release 0.2.0 from Dec 2009, nearly a year later, starts to support Linux and the [https://bitcointalk.org/index.php?topic=5.0 community] got more and more actively involved in the development.
</dl>
For history, one of the earliest available proof of a running bitcoin-0.1.0 with a [http://sourceforge.net/mailarchive/attachment.php?list_name=bitcoin-list&message_id=da7b3ce30901101113v2ec6bf61xf018265479eb7faf%40mail.gmail.com&counter=1 human readable debug log].
There might have been also (private) earlier client code before 0.1.0 available only to Satoshi Nakamoto.
==See also==
[[Bitcoind#History of official bitcoind (and predecessor) releases|History of Bitcoind]]

Regression test mode

2014-03-26T16:02:14Z

Philipkd: not sure if that's the right port.

You can run bitcoin in '''regression test mode''' with the '''-regtest''' command-line argument. This runs a local-only server and lets you generate blocks instantly. Use regtest for app development and testing purposes.

Regression test mode

2014-03-26T15:50:31Z

Philipkd: better wikiformatting.

You can run bitcoin in '''regression test mode''' with the '''-regtest''' command-line argument. This runs a local-only server on port 18444 and lets you generate blocks instantly. Use regtest for app development and testing purposes.

Regression test mode

2014-03-26T15:48:22Z

Philipkd: Basic description of regtest

You can run Bitcoin in **regression test mode** with the **-regtest** command-line argument. This runs a local-only server on port 18444 and lets you generate blocks instantly.

Running Bitcoin

2014-03-26T15:41:07Z

Philipkd: updated for 0.9 command line options

There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin”), and a 'headless' version (called [[bitcoind]]). They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files. You can run one copy of either Bitcoin or bitcoind on your system at a time (if you accidently try to launch another, the copy will let you know that Bitcoin or bitcoind is already running and will exit).

__TOC__

==Linux Quickstart==

The simplest way to start from scratch with the command line client, automatically syncing blockchain and creating a wallet, is to just run this command (without arguments) from the directory containing your bitcoind binary:

./bitcoind

To run with the standard GUI interface:

./bitcoin-qt

==Command-line arguments==

Give Bitcoin (or bitcoind) the -? or –-help argument and it will print out a list of the most commonly used command-line arguments and then exit:

Usage:
bitcoin-qt [command-line options]

Options:
-? This help message
-conf=<file> Specify configuration file (default: bitcoin.conf)
-datadir=<dir> Specify data directory
-testnet Use the test network
-pid=<file> Specify pid file (default: bitcoind.pid)
-gen Generate coins (default: 0)
-dbcache=<n> Set database cache size in megabytes (4 to 4096, default: 100)
-timeout=<n> Specify connection timeout in milliseconds (default: 5000)
-proxy=<ip:port> Connect through SOCKS proxy
-socks=<n> Select SOCKS version for -proxy (4 or 5, default: 5)
-onion=<ip:port> Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)
-dns Allow DNS lookups for -addnode, -seednode and -connect
-port=<port> Listen for connections on <port> (default: 8333 or testnet: 18333)
-maxconnections=<n> Maintain at most <n> connections to peers (default: 125)
-addnode=<ip> Add a node to connect to and attempt to keep the connection open
-connect=<ip> Connect only to the specified node(s)
-seednode=<ip> Connect to a node to retrieve peer addresses, and disconnect
-externalip=<ip> Specify your own public address
-onlynet=<net> Only connect to nodes in network <net> (IPv4, IPv6 or Tor)
-discover Discover own IP address (default: 1 when listening and no -externalip)
-checkpoints Only accept block chain matching built-in checkpoints (default: 1)
-listen Accept connections from outside (default: 1 if no -proxy or -connect)
-bind=<addr> Bind to given address and always listen on it. Use [host]:port notation for IPv6
-dnsseed Find peers using DNS lookup (default: 1 unless -connect)
-banscore=<n> Threshold for disconnecting misbehaving peers (default: 100)
-bantime=<n> Number of seconds to keep misbehaving peers from reconnecting (default: 86400)
-maxreceivebuffer=<n> Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
-maxsendbuffer=<n> Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
-upnp Use UPnP to map the listening port (default: 1 when listening)
-debug=<category> Output debugging information (default: 0, supplying <category> is optional)
If <category> is not supplied, output all debugging information.
<category> can be: addrman, alert, coindb, db, lock, rand, rpc, selectcoins, mempool, net, qt.
-logtimestamps Prepend debug output with timestamp (default: 1)
-shrinkdebugfile Shrink debug.log file on client startup (default: 1 when no -debug)
-printtoconsole Send trace/debug info to console instead of debug.log file
-regtest Enter regression test mode, which uses a special chain in which blocks can be solved instantly.
This is intended for regression testing tools and app development.
-server Accept command line and JSON-RPC commands
-rpcuser=<user> Username for JSON-RPC connections
-rpcpassword=<pw> Password for JSON-RPC connections
-rpcport=<port> Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
-rpcallowip=<ip> Allow JSON-RPC connections from specified IP address
-rpcthreads=<n> Set the number of threads to service RPC calls (default: 4)
-blocknotify=<cmd> Execute command when the best block changes (%s in cmd is replaced by block hash)
-alertnotify=<cmd> Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message)
-keypool=<n> Set key pool size to <n> (default: 100)
-checkblocks=<n> How many blocks to check at startup (default: 288, 0 = all)
-checklevel=<n> How thorough the block verification is (0-4, default: 3)
-txindex Maintain a full transaction index (default: 0)
-loadblock=<file> Imports blocks from external blk000??.dat file
-reindex Rebuild block chain index from current blk000??.dat files
-par=<n> Set the number of script verification threads (up to 16, 0 = auto, <0 = leave that many cores free, default: 0)

Wallet options:
-disablewallet Do not load the wallet and disable wallet RPC calls
-paytxfee=<amt> Fee per kB to add to transactions you send
-rescan Rescan the block chain for missing wallet transactions
-zapwallettxes Clear list of wallet transactions (diagnostic tool; implies -rescan)
-salvagewallet Attempt to recover private keys from a corrupt wallet.dat
-upgradewallet Upgrade wallet to latest format
-wallet=<file> Specify wallet file (within data directory)
-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
-spendzeroconfchange Spend unconfirmed change when sending transactions (default: 1)

Block creation options:
-blockminsize=<n> Set minimum block size in bytes (default: 0)
-blockmaxsize=<n> Set maximum block size in bytes (default: 750000)
-blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 50000)

SSL options: (see the Bitcoin Wiki for SSL setup instructions)
-rpcssl Use OpenSSL (https) for JSON-RPC connections
-rpcsslcertificatechainfile=<file.cert> Server certificate file (default: server.cert)
-rpcsslprivatekeyfile=<file.pem> Server private key (default: server.pem)
-rpcsslciphers=<ciphers> Acceptable ciphers (default: TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH)

UI options:
-lang=<lang> Set language, for example "de_DE" (default: system locale)
-min Start minimized
-splash Show splash screen on startup (default: 1)
-choosedatadir Choose data directory on startup (default: 0)

Many of the boolean options can also be set to off by specifying them with a "no" prefix: e.g. -nodnseed.

==Bitcoin.conf Configuration File==
All command-line options (except for -datadir and -conf) may be specified in a configuration file, and all configuration file options may also be specified on the command line. Command-line options override values set in the configuration file.

The configuration file is a list of setting=value pairs, one per line, with optional comments starting with the '#' character.

The configuration file is not automatically created; you can create it using your favorite plain-text editor. By default, Bitcoin (or bitcoind) will look for a file named 'bitcoin.conf' in the bitcoin [[data directory]], but both the data directory and the configuration file path may be changed using the -datadir and -conf command-line arguments.
{|
! Operating System
! Default bitcoin datadir
! Typical path to configuration file
|-
| Windows
| %APPDATA%\Bitcoin\
| (XP) C:\Documents and Settings\username\Application Data\Bitcoin\bitcoin.conf
(Vista, 7) C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf
|-
| Linux
| $HOME/.bitcoin/
| /home/username/.bitcoin/bitcoin.conf
|-
| Mac OSX
| $HOME/Library/Application Support/Bitcoin/
| /Users/username/Library/Application Support/Bitcoin/bitcoin.conf
|}

Note: if running Bitcoin in testnet mode, the sub-folder "testnet" will be appended to the data directory automatically.

==Sample Bitcoin.conf==
Here is a sample bitcoin.conf file.

# bitcoin.conf configuration file. Lines beginning with # are comments.

# Network-related settings:

# Run on the test network instead of the real bitcoin network.
#testnet=0

# Connect via a socks4 proxy
#proxy=127.0.0.1:9050

##############################################################
## Quick Primer on addnode vs connect ##
## Let's say for instance you use addnode=4.2.2.4 ##
## addnode will connect you to and tell you about the ##
## nodes connected to 4.2.2.4. In addition it will tell ##
## the other nodes connected to it that you exist so ##
## they can connect to you. ##
## connect will not do the above when you 'connect' to it. ##
## It will *only* connect you to 4.2.2.4 and no one else.##
## ##
## So if you're behind a firewall, or have other problems ##
## finding nodes, add some using 'addnode'. ##
## ##
## If you want to stay private, use 'connect' to only ##
## connect to "trusted" nodes. ##
## ##
## If you run multiple nodes on a LAN, there's no need for ##
## all of them to open lots of connections. Instead ##
## 'connect' them all to one node that is port forwarded ##
## and has lots of connections. ##
## Thanks goes to [Noodle] on Freenode. ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# ... or use as many connect= settings as you like to connect ONLY
# to specific peers:
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Maximum number of inbound+outbound connections.
#maxconnections=

# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)

# server=1 tells Bitcoin-QT to accept JSON-RPC commands.
#server=0

# You must set rpcuser and rpcpassword to secure the JSON-RPC api
#rpcuser=Ulysseys
#rpcpassword=YourSuperGreatPasswordNumber_DO_NOT_USE_THIS_OR_YOU_WILL_GET_ROBBED_385593

# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established.
#rpctimeout=30

# By default, only RPC connections from localhost are allowed. Specify
# as many rpcallowip= settings as you like to allow connections from
# other hosts (and you may use * as a wildcard character).
# NOTE: opening up the RPC port to hosts outside your local
# trusted network is NOT RECOMMENDED, because the rpcpassword
# is transmitted over the network unencrypted.
#rpcallowip=10.1.1.34
#rpcallowip=192.168.1.*

# Listen for RPC connections on this TCP port:
#rpcport=8332

# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:
#rpcconnect=127.0.0.1

# Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate
# with Bitcoin -server or bitcoind
#rpcssl=1

# OpenSSL settings used when rpcssl=1
#rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
#rpcsslcertificatechainfile=server.cert
#rpcsslprivatekeyfile=server.pem

# Miscellaneous options

# Set gen=1 to attempt to generate bitcoins
#gen=0

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100

# Pay an optional transaction fee every time you send bitcoins. Transactions with fees
# are more likely than free transactions to be included in generated blocks, so may
# be validated sooner.
#paytxfee=0.00

# Allow direct connections for the 'pay via IP address' feature.
#allowreceivebyip=1

# User interface options

# Start Bitcoin minimized
#min=1

# Minimize to the system tray
#minimizetotray=1

==Platforms==
===Windows===

====Start automatically====
To configure the Bitcoin client to start automatically:

You might use the configuration-file, or the GUI-Settings:

Settings -> Options

then mark the checkbox titled:
[X] Start Bitcoin on system startup

[[{{ns:file}}:Client_Settings_Options_windows.png]]

====Batch automation====
To work with batch, you have to start the daemon (bitcoind.exe). The bitcoin.exe run with option "-server" will respond with GUI-messages you are not able to process its answers.

===Mac===
[[{{ns:file}}:MacBitcoinStartOnLogin.png]]

===Linux===
[[{{ns:file}}:Client_Settings_Options.png]]

==See Also==

* [[Data directory]]

[[es:Ejecución de Bitcoin]]

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