Bitcoin Wiki - User contributions [en]

User talk:MagicalTux

2013-01-31T20:47:37Z

Nubarius: BitcoinPayment issue

Hey MagicalTux, The WikiBot is not following the post-February 20th protocol change and the Fallback nodes page is not functioning. [[User:Atheros|Atheros]] 07:37, 20 February 2012 (GMT)

Wikibot currently malfunctioning, makring all the nodes as down when they arn't.
There is a steady trickle of spammers adding junk pages. How about granting delete and ban privileges to some established editors, it works for some other wiki's. [[User:Ziv|Ziv]] 14 April 2012

== BitcoinPayment ==
Hi MagicalTux. I have a problem with the new BitcoinPayment system. I've decided to contact you through your talk page because nobody seems to be available in the #bitcoin-wiki chatroom. Last week Nanotube read my questions and I think he asked you to have a look at this issue but I don't know if you got the chance to read that. Basically, the problem is that I made the payment to become a trusted member and now I find that the non-English wikis are off-limits to me. It seems as if not even trusted members can edit them. This is a bit frustrating since my activity was in the Spanish wiki, where I have translated some of the technical articles. I'd like to continue enlarging the Spanish wiki, but it seems to be impossible for anyone to edit the articles at the moment. Could you have a look at this? [[User:Nubarius|Nubarius]] ([[User talk:Nubarius|talk]]) 20:47, 31 January 2013 (GMT)

Category:BIP

2013-01-02T17:59:38Z

Nubarius: Interwiki link to Spanish category

Following [[BIP 0001]], BIP stands for "[[Bitcoin Improvement Proposal]]".

;A:Active
;C:Accepted
;D:Draft
;E:Deferred
;R:Rejected
;W:Withdrawn
;Z:Other

[[es:Categoría:BIP]]

Bitcoin Improvement Proposals

2013-01-02T17:56:21Z

Nubarius: Interwiki link to Spanish version

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

Those proposing changes should consider that ultimately consent may rest with the [[economic majority]].

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0018|18]]
| hashScriptCheck
| Luke Dashjr
| Draft
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Replaced
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0022|22]]
| getblocktemplate - Fundamentals
| Luke Dashjr
| Accepted
|-
| [[BIP 0023|23]]
| getblocktemplate - Pooled Mining
| Luke Dashjr
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| [[BIP 0032|32]]
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Draft
|-
| [[BIP 0033|33]]
| Stratized Nodes
| Amir Taaki
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0034|34]]
| Block v2, Height in coinbase
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0035|35]]
| mempool message
| Jeff Garzik
| Accepted
|-
| [[BIP 0036|36]]
| Custom Services
| Stefan Thomas
| Draft
|-
| [[BIP 0037|37]]
| Bloom filtering
| Mike Hearn and Matt Corallo
| Draft
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

[[es:Propuestas de mejora de Bitcoin]]

Category:Technical

2012-12-12T16:51:48Z

Nubarius: Added interwiki link to corresponding category in Spanish wiki

These pages outline the technology behind Bitcoin.

==See also==

* [[Research]]
* [[:Category:Developer|Developer]]

[[es:Categoría:Técnica]]

Key pool

2012-12-12T16:44:32Z

Nubarius: Added interwiki link to Spanish translation of the article

New public and private keys are pre-generated and stored in a queue before use.

This pooling feature was added so backups of the [[wallet]] would have a certain number of keys that would be used in the future. By default, the number of entries in the queue is 100<ref>[http://www.bitcointalk.org/index.php?topic=1414.0 Key pool feature for safer wallet backup]</ref>.

A command line option allows a greater or lesser number of keys to be maintained in the keypool<ref>[https://en.bitcoin.it/wiki/Running_Bitcoin Running Bitcoin]</ref>.

==See Also==

* [[Securing your wallet]]

==References==
<references />

[[Category:Technical]]

[[es:Reserva de claves]]

Exit Address

2012-12-12T16:26:03Z

Nubarius: Added interwiki link to Spanish translation of the article

Exit addresses (first described [http://www.reddit.com/r/Bitcoin/comments/ohfxw/update_mt_gox_steals_from_tor_users_now_i_can_not/c3ha5li here]) are defined as follows: "When you create an account with a site, you should be able to enter an address that, should anything go wrong, your coins will be sent too. Deepbit, for example has an option that will let you 'lock your payments address forever' meaning, even if someone hijacks your account, they won't be able to withdraw money anywhere."

Many members of the bitcoin community have advocated that any service accepting bitcoin deposits (as opposed to payments -- i.e. exchanges, etc) ought to include an exit address facility, and allow enactment of exit address policy at any time. This would avoid the conflict of interest inherent in "anti-money-laundering" account freezures, whereby the exchange ''actually books a profit under accepted accounting practices'' as a result of balances inheriting from accounts abandoned in response to account freezure (once the statue of limitations on embezzlement expires).

[[Category:Vocabulary]]

[[es:Dirección de escape]]

List of address prefixes

2012-12-12T16:08:08Z

Nubarius: Added interwiki link to Spanish translation of the article

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

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Bitcoin Private key (for uncompressed public key)
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Bitcoin Private key (for compressed public key)
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

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

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

[[es:Lista de prefijos de direcciones]]

Base58Check encoding

2012-12-12T15:55:28Z

Nubarius: Added interwiki link to Spanish translation of the article

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

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

The original Bitcoin client source code discusses the reasoning behind base58 encoding:

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

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

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

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

A Bitcoin address is the Base58Check encoding of the hash of the associated [[script]]. Specifically, it is Base58Check(5,[[RIPEMD160]]([[SHA256]]([[script]]))), with the following constraints:
* [[RIPEMD160]] and [[SHA256]] in this case are always exactly 20 and 32 unsigned bytes respectively. These are big-endian (most significant byte first). (Beware of [[bignumber]] implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign - your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from - which would lead to the permanent loss of coins.)
* 0 refers to the version/application byte.

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

==Encoding a private key==
Base58Check encoding is also used for encoding [[private key]]s in the [[Wallet Import Format]]. This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer). Such encodings will always yield a 51-character string that starts with '5', or more specifically, either '5H', '5J', or '5K'.

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

The algorithm for encoding address_byte_string (consisting of 0x01 + hash + 4-byte_check_code) is

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

output_string = ""

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

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

output_string.reverse();

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

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

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

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

[[Category:Technical]]

[[es:Codificación Base58Check]]

Category:Vocabulary

2012-12-12T08:55:16Z

Nubarius: Added interwiki link to the category in the Spanish-language wiki

Confused by the lingo? These pages might help.

The list below includes words that have an article of their own. Other vocabulary can be found in the [[vocabulary|vocabulary list]].

==See Also==

* [[Vocabulary]]

[[es:Categoría:Vocabulario]]

Invoice address

2012-12-12T08:51:16Z

Nubarius: Added interwiki link to Spanish translation of the article

A '''Bitcoin address''', or simply '''address''', is an identifier of 27-34 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

An example of a Bitcoin address is ''31uEbMgunupShBVTewXjtqbBv5MndwfXhb''.


==A Bitcoin address is like an e-mail address==
Like e-mail, you can send bitcoins to a person by sending bitcoins to one of their addresses. A person can have many different Bitcoin addresses and, for increased privacy and as the only way to know what the bitcoins are received for/from, it is recommended that you use a unique address for each transaction. Most Bitcoin software and websites will help with this by generating a brand new address each time you perform a transaction. Some services provide a facility to request a new Bitcoin address for use with their service when desired.

When using a web site that accepts bitcoins or holds Bitcoin balances on your behalf, that website will assign a Bitcoin address to your account, so you can transfer funds into your account at the site. Very much unlike e-mail, this address may change every time funds come in so care should be taken when sending additional funds to a previously-used address. When you send Bitcoins to your account at a web site, they will usually be credited to your account at that web site after the transaction is [[confirmation|confirmed]].

==Addresses can be created offline==
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. The network starts tracking an address when it is first seen in a valid payment transaction.

It is possible to create large batches of addresses offline using freely available software tools. Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.

An average desktop computer can generate thousands of new Bitcoin addresses a minute. Addresses are created simply by generating random numbers and then performing mathematical operations to derive matching pairs of "public" and "private" keys. Because addresses can be created easily and at minimal cost, it is not uncommon to create temporary addresses that can be discarded if unused.

==Addresses are case sensitive and exact==
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.

The probability that a mistyped address is accepted as being valid is 1 in 232, that is, approximately 1 in 4.29 billion.

==Address validation==
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3.

==Addresses have a "private key"==
For most properly-generated Bitcoin addresses, there is at least one secret number known as a [[private key]] which is required for access to the funds assigned to that address.

When using a Bitcoin client, private keys are typically stored in the [[Wallet|wallet file]]. The private key has a special purpose - it is mathematically needed to create valid transactions that spend the funds originally sent to the address. If the private key to an address is lost (for example, in a hard drive crash, fire or other natural disaster), any associated Bitcoins are effectively lost forever.

==Multi-signature addresses==
Addresses can be created that require a combination of multiple private keys.
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.

The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.

==What's in an address==
Most Bitcoin addresses are 34 characters.
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.

Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid.
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.
Every Bitcoin address stands for a number - somewhat like an account number. These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.

==See Also==
* [[Technical background of Bitcoin addresses]]
* [[List of address prefixes]]
* [[Exit Address]]

[[Category:Vocabulary]]

[[es:Dirección]]

Transaction

2012-12-11T21:54:43Z

Nubarius: Added interwiki link to Spanish translation of the article

[[File:TxBinaryMap.png|thumb|right|Byte-map of Transaction with each type of TxIn and TxOut]]
A transaction is a signed section of data that is broadcast to the [[network]] and collected into [[block|blocks]]. It references a previous transaction and dedicates a certain number of bitcoins from it to a new public key (Bitcoin address). It is not encrypted (nothing in Bitcoin is encrypted).

A [[block chain browser]] is a site where every transaction included within the block chain can be viewed. This is useful for seeing the technical details of transaction in action, and for payment verification purposes.

=== Example Bitcoin Transaction ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

===== Input =====

An '''input''' is a reference to an output in a different transaction. Multiple inputs are often listed in a transaction. The values of the referenced outputs are added up, and the total is usable in the outputs of this transaction. '''Previous tx''' is a [[hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[script]] (discussed in more detail later).

The script contains two components, a signature and a public key. The public key belongs to the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value. The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

===== Output =====

An '''output''' contains instructions for sending bitcoins. '''Value''' is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. '''ScriptPubKey''' is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because an output can only ever be referenced by a single input, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction fee]]; whoever generates the block will get it.
[[File:transaction.png|thumb|A sends 100 BTC to C and C generates 50 BTC. C sends 101 BTC to D, and he needs to send himself some change. D sends the 101 BTC to someone else, but they haven't redeemed it yet. Only D's output and C's change are capable of being spent in the current state.]]

===== Verification =====

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like [[script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

=== Types of Transaction ===
Bitcoin currently only creates three different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as [[Contracts]].

==== Transfer to IP address ====

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>
The sender gets the public key when talking to the recipient over IP. When redeeming coins that have been sent to an IP address, the recipient provides only a signature. The signature is checked against the public key in scriptPubKey.

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

==== Transfer to Bitcoin address ====

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

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

==== Generation ====

Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.

==See Also==

* [[Script]]
* [[BTC Sender]] Transmit raw, hand-crafted transactions

[[Category:Technical]]
[[Category:Vocabulary]]
[[de:Transaktion]]
[[es:Transacción]]
[[pl:Transakcje]]

BitAddress

2012-12-11T12:32:02Z

Nubarius: Added interwiki link to Spanish translation of the article

A tool used to securely generate one or more Bitcoin addresses for offline use or for secure offline storage.

The address and private key pair generated allow bitcoins to be received and then spent without running any software or using any external [[eWallet]] service.

The all-in-one web page can be used offline (i.e., without being connected to the Internet).

==External Links==

* [https://www.bitaddress.org BitAddress] web site
* [http://bitcointalk.org/index.php?topic=43496.0 Forum discussion]

[[Category:Tools]]

[[es:BitAddress]]

Secp256k1

2012-12-10T18:22:17Z

Nubarius: Added interwiki link to new Spanish article

'''secp256k1''' refers to the parameters of the [[ECDSA]] curve used in Bitcoin, and is defined in ''Standards for Efficient Cryptography (SEC)'' (Certicom Research, http://www.secg.org/collateral/sec2_final.pdf).

As excerpted from ''Standards'':

The elliptic curve domain parameters over F''p'' associated with a Koblitz curve secp256k1 are specified
by the sextuple T = (''p,a,b,G,n,h'') where the finite field F''p'' is defined by:
* ''p'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F
* = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1

The curve ''E'': ''y2 = x3+ax+b'' over F''p'' is defined by:
* ''a'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
* ''b'' = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007

The base point G in compressed form is:
* ''G'' = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
and in uncompressed form is:
* ''G'' = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
Finally the order ''n'' of ''G'' and the cofactor are:
* ''n'' = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
* ''h'' = 01

[[es:Secp256k1]]

Pywallet

2012-12-10T18:14:50Z

Nubarius: Added interwiki link to new Spanish article

Pywallet is a python utility that dumps addresses and private keys from a Bitcoin-QT or bitcoind wallet.dat file. The script also imports private keys into the wallet.dat file.

Included since version 0.6.0 of Bitcoin-QT and bitcoind, the importprivkey command makes pywallet's import feature unnecessary. It is advised to shut down any program that is accessing the wallet.dat file and make a backup before running pywallet to avoid any potential for corruption.

[[es:Pywallet]]

Private key

2012-12-10T18:11:39Z

Nubarius: Added interwiki link to new Spanish article

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

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

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

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

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

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

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

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

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

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

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

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

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

SzavMBLoXU6kDrqtUVmffv

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

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

==See Also==

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

[[es:Clave privada]]

Paper wallet

2012-12-10T17:19:46Z

Nubarius: Added interwiki link to Spanish translation of the article

A '''paper wallet''' is a way to store Bitcoins that involves printing the Bitcoin addresses and private keys directly on a piece of paper. When done properly, paper wallets are one of the safest ways possible to store Bitcoins.

__TOC__

A Bitcoin [[private key]] can be represented in several formats, but is typically a string of numbers and letters no more than about 51 characters in length. This is easy to print on paper, and if kept secret, can securely hold an unlimited quantity of Bitcoins.

==Producing safe paper wallets==
Several tools exist for producing paper wallets, including [[pywallet]], [[vanitygen]], [http://bitaddress.org/ Bitaddress.org], [[LinuxCoin]], and [[Bitcoin Address Utility]]. Paper wallets must be produced securely in order to be safe, because any leak of the private key constitutes the ability for an attacker to steal any present and future balance of the address. Consider the following:
* Paper wallets should be produced on a computer not connected to the Internet.
* Be aware that malware often allows a remote third party to view your screen and see your keystrokes, and these can compromise the integrity of your paper wallet. Also consider that antivirus software cannot completely rule out the possibility of malware. However, using bootable CD's prevents the vast majority of malware from being able to run. If you can generate a paper wallet with a bootable CD such as [[LinuxCoin]], the likelihood of malware being able to compromise your keys is very low.
* The private keys of paper wallets should never be saved to a computer hard drive. You should also never scan your paper wallet into your computer or type the private keys or save them in e-mail, except at the moment you are redeeming the balance.
* A web-based paper wallet generator should be written so that all of the generation happens on your computer, not the web server. After you load the paper wallet generating website in your web browser, you should disconnect from the internet, and observe that the paper wallet generator continues to function. Afterward, you should close your browser before reconnecting to the internet.
* A paper wallet generator should use an appropriate source of random numbers (entropy). This means that the generated addresses aren't predictable. If the addresses come from a predictable or partially-predictable pattern, someone else who can predict the pattern addresses can steal the balance. A safe way to generate addresses is from a passphrase, where you provide a very long unguessable passphrase (at least thirty characters - even if it is just mashing random characters on the keyboard). This way, you as the user are in control of the randomness and potential predictability of the addresses.

===Printer Security===

Some printers will store the output using storage in which the data can be recovered from the printer's memory or from a hard drive (if the printer has one) and stores its print jobs there. Most larger commercial printers have hard drives but whether or not documents are stored on them will vary based on manufacturer and model.

==Redeeming Keys==

There are various methods for copying the private key data from a paper wallet to other wallets. [[BlockChain.info]] and [[Armory]] can import them directly into wallets. [[MtGox|Mt. Gox]] provides the ability to Add Funds using a private key. The exchange will then create a "sweep" transaction that spends any amount for that paper wallet address so that the amount is added to your account with them. They will also sweep to your account any bitcoins received to that address in the future as well.

Those running the Bitcoin.org ("Satoshi") client can import paper wallet addresses using the [[Pywallet]] utility. Other [[:Category:Clients|clients]] may allow this as well, including the Javascript-based wallet called My Wallet from [[BlockChain.info]] which can import Bitcoin private keys as well.

Since 0.6.0, key import/export are available in the client itself, you can use is via RPC. The commands are ''dumpprivkey'' and ''importprivkey''. For encrypted wallet, you need to use ''walletpassphrase'' to decrypt temporarily in memory before importing or exporting. Note that bitcoind will rescan the block data when importing each key now, this process takes about one minute or two, depending on your CPU performance. See [[How to import private keys]] for more info.

==See Also==

* [[Private key]]

* [[Securing_your_wallet#Paper_Wallets]]

* [[How to import private keys]]

[[Category:Security]]

[[es:Monedero de papel]]

Category:Instructional

2012-12-05T21:44:06Z

Nubarius: Added interwiki link to corresponding category in Spanish wiki

Instructions and how-to articles.

==See Also==

* [[:Category:Introduction]]

[[es:Categoría:Instrucciones]]

Wallet Security Dos and Don'ts (Windows)

2012-12-05T21:40:02Z

Nubarius: Added interwiki link to Spanish translation of this article.

[Note - There are varying levels of security appropriate for the level of risk. The following might be general recommendations for consumer-level risks. Service providers and large investors requiring enterprise level security might have a very specific list of Dos and Dont's that varies from this list.]

*'''Don't''' keep all your bitcoins in one wallet.

*'''Don't''' send bitcoins to a wallet that hasn't been backed up ''beforehand''.

*'''Don't''' send [[Securing_your_wallet#General_Solutions|unencrypted]] copies of your wallets over the Internet.

*'''Don't''' store unencrypted copies of your wallets on online backup/storage services.

*'''Don't''' run or install programs from questionable sources on the system where you are running bitcoin.

*'''Don't''' click on questionable links in your browser.

*'''Don't''' run bitcoin on an untrusted or badly maintained machine.

*'''Don't''' run software that has been copied illegally (eg, "warez")

*'''Don't''' install unnecessary browser plugins.

*'''Don't''' use a password for wallet encryption that you use elsewhere on the web.

*'''Don't''' use weak passwords. If a password is easy to remember without rehearsal, it is probably weak.

*'''Don't''' forget your passwords. If you write them down on a piece of paper, keep that piece of paper in a safety deposit box.

*'''Don't''' store unencrypted copies of your wallets on a device that you insert into machines of friends, at work, or while traveling.

*'''Don't''' insert any devices of doubtful origin.

*'''Don't''' develop a carefree attitude towards wallet security. Handle bitcoins with the same amount of diligence as you handle physical cash.

*'''Do''' keep at least one [[How to set up a secure offline savings wallet|offline savings wallet]].

*'''Do''' backup your spending wallet regularly.

*'''Do''' keep dated versions of each backed up wallet.

*'''Do''' [[Securing_your_wallet#General_Solutions|encrypt]] all wallets as soon as they leave your system.

*'''Do''' keep encrypted backups of all your wallets in at least 3 physically separate locations.

*'''Do''' use strong, unique passwords to encrypt your wallets.

*'''Do''' use [http://www.truecrypt.org/docs/?s=keyfiles keyfiles] to encrypt your wallets, and keep backups of your keyfiles in at least 3 physically separate locations.

*'''Do''' use a good antivirus and firewall, and keep them up to date (but understand their limitations).

*'''Do''' update all your installed programs to the latest version.

*'''Do''' update your operating system with the latest security patches.

*'''Do''' uninstall all programs that you don't use regularly.

*'''Do''' uninstall all browser plugins/ add-ons that you don't use regularly.

*'''Do''' always browse in private mode.

*'''Do''' use the [http://noscript.net/ NoScript] plugin (or similar) in your browser and whitelist only the sites you trust.

*'''Do''' run programs from questionable sources inside a virtual machine, such as [http://www.virtualbox.org/ VirtualBox].

*'''Do''' browse questionable websites from inside a virtual machine.

*'''Do''' connect the bitcoin client and IRC via [[Tor]].

*If you own a large number of bitcoins, '''do''' invest time and money in order to secure them, just like you would with other valuables. If you lack the technical expertise, ask or pay somebody else to do it for you.

*If you believe your computer has been compromised, '''do''' wipe your HD and perform a clean OS install.

[[Category:Instructional]]
[[Category:Security]]

[[es:Qué se debe y qué no se debe hacer respecto a la seguridad del monedero (Windows)]]

Category:Security

2012-12-04T21:02:40Z

Nubarius: Added interwiki link to the category in the Spanish-language wiki

This category is for articles related to securing a wallet or online service, or other security and Infosec topics.

[[es:Categoría:Seguridad]]

Data directory

2012-11-16T21:27:18Z

Nubarius: Added interwiki link to new Spanish article

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

==Default Location==
=== 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/

==Directory Contents==

===Subdirectories===
* database
**Contains journaling files for the block database
* testnet
**Contains testnet versions of these files (if running with -testnet)

===Files===
* .lock
**BDB lock file
* bitcoin.conf [optional]
**Contains [[Running_Bitcoin#Bitcoin.conf_Configuration_File|configuration options]].
* blk''xxxx''.dat
**Contains concatenated raw blocks
* blkindex.dat
**Indexing information used with blk''xxxx''.dat
* __db.''xxx''
**Used by BDB
* db.log
* debug.log
**Bitcoin's verbose log file. Automatically trimmed from time to time.
* wallet.dat
**Storage for keys, transactions, metadata, and options. Please be sure to make backups of this file. It contains the keys necessary for spending your bitcoins.
* addr.dat [Versions prior to v0.7.0]
** Storage for ip addresses to make a reconnect easier
* peers.dat [Versions v0.7.0 and later]
** Storage for peer information to make a reconnect easier. This file uses a bitcoin-specific file format, unrelated to any database system<ref>[http://bitcointalk.org/index.php?topic=119525.msg1287284#msg1287284 Ultraprune merged in mainline]</ref>.
The data, index and log files are used by Oracle [http://en.wikipedia.org/wiki/Berkeley_DB Berkeley DB], the embedded key/value data store that Bitcoin uses.

==See Also==

* [[Securing your wallet]]

==References==
<references />

[[Category:Technical]]

[[es:Directorio de datos]]

Securing your wallet

2012-09-19T10:05:34Z

Nubarius: Added interwiki link to new Spanish article

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

''For a brief overview see also: [[Wallet Security Dos and Don'ts (Windows)|Wallet Security Dos and Don'ts]]''

==Paper Wallets==
[[Paper wallet]]s are a fairly simple way to store your bitcoins independent of a computer. When generated securely and stored on paper, or other offline storage media, a paper wallet decreases the chances of your bitcoins being stolen by hackers, or computer viruses.

With each entry on a paper wallet, you are securing a sequence of secret numbers that is used to prove your right to spend the bitcoins assigned to one of your addresses. This secret number, called a [[private key]], is most commonly written as a sequence of fifty-one alphanumeric characters, beginning with a '5'.

One way you can create a paper wallet is by going to the website [[BitAddress|bitaddress.org]]. This website features a free client-side paper wallet generator written in JavaScript. The webpage can be saved as a file and used on an offline computer. Using it online is relatively safe, for storing smaller amounts, but not airtight unless you take extra precautions to ensure your keys are not stolen by spyware. Alternatively Blockchain.info offers a [https://blockchain.info/wallet/paper-tutorial tutorial on how to generate a paper wallet] with an online component so you can still check your balance easily.

To generate a safer paper wallet, it is best to "clean-boot" your computer with a bootable CD (such as a Linux Live CD), with your computer not connected to the Internet, to ensure that you do not have any active spyware that might steal any private keys you generate. Disconnecting from the Internet allows you to confirm that the paper wallet generator is truly self-contained and isn't depending on communication with a remote server. Run the saved paper wallet generator in a web browser, then print your paper wallets or store them on external media (do not save them on the computer), and then shut down the computer. You may need to load an appropriate printer driver in order to print while booted from the live CD.

A paper wallet lists multiple Bitcoin addresses and their corresponding private keys. You can send Bitcoins to any address on the page and they will be inaccessible until the private key is imported into a wallet. Since version 0.6.0, the bitcoin software has a command called "importprivkey" that can load private keys, but you can also use the "Add Funds" - "Private key" screen at [[MtGox]] or Blockchain.info's "My Wallet" service to recover bitcoins from a private key. In the case of MtGox, bitcoins are deposited in your account, and can be sent out of MtGox after the standard number of deposit confirmations.

Remember, spyware and viruses often attempt to monitor your computer activities so that their authors can steal from you. They are interested in passwords to online accounts, and anything of value. Bitcoin wallets and private keys are something of value that have already been targeted by malware. Paper wallets isolate you from much of this risk.

If your computer is infected with spyware or viruses - even if there are no symptoms, or your antivirus isn't reporting anything - then anything you type, view, or save on your computer, could potentially be stolen by someone remotely controlling your computer. Your private key can then be intercepted while you enter it, so only enter a Bitcoin private key into your computer when your intent is to redeem its value ''immediately''.

==Importance of security updates==

No software is perfect, and from time to time there may be security vulnerabilities found in your Bitcoin client as well.
Be sure you keep your client updated with the latest bug fixes, especially when a new vulnerability is discovered.
We maintain a [[CVEs|list a known vulnerabilities]] on this wiki - you can watch that page to get updates.
Note that you ''don't'' need to be running the latest major client version: some clients, including the popular Bitcoin-Qt, have older versions available with bugfix-only updates.

==Securing the Bitcoin-QT or bitcoind wallet==

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 (the account is the 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 ==

If a wallet or an encrypted wallet's password has been compromised, it is wise to create a new wallet and transfer the full balance of bitcoins to addresses contained only in the newly created wallet. Examples of ways a wallet may be compromised are through password re-use, minimal strength passwords, computer hack or virus attack.

There are a number of ways to create a new wallet with Bitcoin-QT or bitcoind but this is a process that has been tested with bitcoind 0.6.3. We use the copy command to minimize the chance of any data loss but you are warned to make backups of any wallet.dat that holds a balance for you.

:1. Shut down the Bitcoin program.
:2. Find and make a backup of the "compromised" wallet.dat file and rename it, perhaps adding a short description:
:::wallet.dat -> wallet-compromised.dat
:Depending on your OS, the wallet file will be located at:
:::Windows: %APPDATA%\Bitcoin\
:::Linux: ~/.bitcoin/
:::Mac: ~/Library/Application Support/Bitcoin/
:3. Start the Bitcoin program and it will create a new wallet.dat. You may then encrypt the wallet as desired and make a new backup.
:4. Once you've made a new wallet, you can obtain one or more addresses and copy them into a text editor. After obtaining the new address(es), shut down the Bitcoin program, make a backup of the new wallet.dat file and copy it to a new file named wallet-new.dat.
:5. Copy the wallet-compromised.dat file back to wallet.dat, start the Bitcoin program and transfer your balance to the new address(es) you put in your text editor. Once the balance is back to 0 for your compromised wallet, you may want to wait a couple minutes or for a confirmation or check block explorer to be sure the transactions have been broadcasted. Then you may shut down the Bitcoin program.
:6. Rename wallet.dat to wallet-compromised.dat.
:7. Rename wallet-new.dat to wallet.dat.

You should now have a new wallet with all the bitcoins from the old wallet.

==Making a secure workspace==

If you are using your computer to handle bitcoins, a wallet, Bitcoin-related passwords, or Bitcoin private keys, you must take care that the system is free of malware, viruses, keyloggers, remote access tools, and other tools that may be used to make remote copies of any of the above. In the case that your computer is compromised, the precautions taken below may provide additional protection.

===Linux===

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

<code>adduser new_user_name</code>

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.23/bitcoin-0.3.23-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 only use it for Bitcoin.

It's also a good idea to encrypt the Home directory of whatever user you run Bitcoin under using ecryptfs-utils. To do this:
# If the Home directory is not empty you should back it up first, by just copying the data to an external drive or something.
# install ecryptfs-utils (on Ubuntu: sudo apt-get install ecryptfs-utils)
# log out of X (graphical system) and press Ctrl+Alt+F1 to login to the command shell (you must be logged out or some files will be open and the tool won't be able to encrypt your data)
# change directory to something that's not in your home folder (ex: cd / )
# run the migration tool (on Ubuntu: sudo ecryptfs-migrate-home -u username)
# if it's successful, you can now press ALT+F8 to go back to the GUI and login
# run 'ecryptfs-unwrap-passphrase' and '''WRITE DOWN OR SAVE THE CODE IT RETURNS''' because you will need it if you ever have to pull your data off while the OS is not working. (You can run it again later if you need to, but run it now so that you can get your data if your Linux install gets botched.)
# run 'ecryptfs-setup-swap' to encrypt your swap partition (the encrypted folder data is not encrypted while it's in memory, and so if it's ever sent to the swap partition it can be stolen from there unless that too is encrypted - be aware that this will mean you cannot use Hibernate anymore, as the bootloader won't be able to restore the hibernation data)
(instructions from [http://bodhizazen.net/Tutorials/Ecryptfs/#Migrate])

===Mac===
This solution '''does not scale'''; the amount of needed space can grow beyond the image size.

=====Backup all data=====
Follow these instructions to backup all the bitcoin data (wallet and block chains) to an encrypted disk image.
# Open Disk Utility
# Click New Image and choose a big enough size, 128-bit or 256-bit (faster or more secure) encryption and single partition.
# Save it somewhere you won't lose it (like your Wuala, Dropbox, Strongspace or whatever)
# Choose a safe and strong password
# Move everything from ~/Library/Application Support/Bitcoin/ to the image
# Symlink it back so the app would be able to use it
:::ln -s /Volumes/Bitcoin ~/Library/Application Support/Bitcoin

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

=====Backup just wallet.dat=====
Follow these instructions to backup just the wallet.dat file. This results in a smaller disk image, but it's more complicated to do.
# Open Disk Utility
# Click New Image and choose a big enough size, 128-bit or 256-bit (faster or more secure) encryption and single partition.
# Save it somewhere you won't lose it (like your Wuala, Dropbox, Strongspace or whatever)
# Choose a safe and strong password
# Move your wallet.dat file to the image
# Symlink it back so the app would be able to use it
:::ln -s /Volumes/Bitcoin/wallet.dat ~/Library/Application Support/Bitcoin/wallet.dat

[[File:MountWalletAndLauchnBitcoin_OSX_Automator.png|thumbnail|150px|Mount Wallet and launch Bitcoin]]
Don't forget to mount your image before using Bitcoin and unmount after quitting it.

'''Note''': If you start the Bitcoin application without having the image mounted, the application will overwrite your symlink with a new wallet. If that happens, don't panic. Just delete the new wallet.dat, mount the image, and recreate the symlink like above.

'''Automation''': You can create a small application using [http://en.wikipedia.org/wiki/Automator_%28software%29 Automator] (included in OS X) to automatically mount the wallet and then launch Bitcoin App. See the Screenshot on how to do this.

If one ''doesn't'' want to use encrypted Disk images, then a '''small shell script''' can be used instead that takes care of decrypting the wallet, launching bitcoin client, and encrypting it after the client exits. This script works on both OSX and Linux: [http://lorelei.kaverit.org/bitcoin.sh bitcoin-launch-script]

===Windows===

Due to the frequency with which Windows computers are compromised, it is advised to encrypt your wallet or to keep your wallet on an encrypted disk image created by third-party software, such as [http://www.truecrypt.org/ TrueCrypt] (open source) or [http://www.jetico.com/encryption-bestcrypt/ Jetico BestCrypt] (commercial). This also applies to the storage of passwords, private keys and other data that can be used to access any of your Bitcoin balances.

Assuming that you have installed the Windows Bitcoin client and run it at least once, the process is described below.

To mount the Bitcoin data directory on an encrypted drive
<ol start=1 type=1>
<li>Use the third-party disk image encryption program of your choice to create and mount an encrypted disk image of at least 5GB in size. This procedure stores the entire block chain database with the wallet.dat file so the required size of the encrypted disk image required may grow in the future.</li>
<li>Locate the Bitcoin data directory, and copy the directory with all contents to the encrypted drive.
For help finding this directory, see [[Securing_your_wallet#Locating_Bitcoin_s_data_directory|Locating Bitcoin's Data Directory]].</li>
<li>Create a Windows shortcut that starts Bitcoin with the <code>-datadir</code> parameter and specifies the encrypted drive and directory.
For example, if you installed Bitcoin in the default directory, mounted your Bitcoin encrypted drive as <code>E:\</code>, and stored your Bitcoin data directory on it as <code>Bitcoin</code>, you would type the following command as the shortcut Target:
<blockquote><code>C:\Program Files\Bitcoin\bitcoin.exe -datadir=E:\Bitcoin</code></blockquote></li>
<li>Open Bitcoin's settings and configure it NOT to start automatically when you start Windows.
This is to allow you to mount the Bitcoin encrypted disk image before starting Bitcoin.</li>
<li>Shut down Bitcoin, and then restart it from the new shortcut.</li>
</ol>

After doing this, any time you want to use Bitcoin, you must first mount the Bitcoin encrypted disk image using the same drive designation, and then run Bitcoin from the shortcut that you created, so that it can find its data and your wallet.

== 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 one of the following locations:

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

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

If you have trouble browsing to these folders, note that "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

To change the directory Bitcoin stores its data in:
Run in terminal or script: ./bitcoin(-qt) -datadir=./[Directory_Name]

=== Mac ===

By default Bitcoin will put its data here:

~/Library/Application Support/Bitcoin/

==Backup==

'''Note''': Using Dropbox to back up your Bitcoin data is not recommended as doing so introduces the following [https://en.wikipedia.org/wiki/Dropbox_(service)#Reception security concerns]:
# Dropbox stores your encryption key (meaning that a disgruntled Dropbox employee or an attacker who gained access to the system could decrypt your Dropbox data and steal your bitcoins)
# the Dropbox client only needs a password for the first login. After it authenticates once, the server assigns it a token which it uses to show that, at one time, its user knew the password rather than sending the actual password (meaning that if you ever use the Dropbox client on another PC, that PC's users can access your Dropbox - even if you change your password - and can steal your bitcoins or get a virus that will steal your bitcoins).

For these reasons, an alternative that always uses password authentication such as [http://www.wuala.com/en/bitcoin Wuala] should be used. Wuala's servers do not store your encryption key and the program authenticates with the password each time it is started.

Whether you use Dropbox as your backup or not, it is advised to use what Steve Gibson calls "pre-Internet encryption" which means to use some form of encryption on your files before you back them up, in case an attacker gains access to that backup. Make sure to pick a password that is memorable but secure.

The only file you need to back up is "wallet.dat" which can be done one of two ways. To make a copy of the wallet.dat file, ensure that Bitcoin is closed and copy this file somewhere else. The other way is to use the [[api|backupwallet]] JSON-RPC command to back up without shutting down Bitcoin.

Once a copy has been made, encrypt it, and put it in two or more safe locations. Consider the risk due to theft, fire, or natural disaster in proportion to the value of bitcoins stored in the wallet.

=== General Solutions ===

Your wallet.dat file is not encrypted by the Bitcoin program by default but the most current release of the Bitcoin client provides a method to encrypt with a passphrase the private keys stored in the wallet. Anyone who can access an unencrypted wallet can easily steal all of your coins. Use one of these encryption programs if there is any chance someone might gain access to your wallet.
* [http://www.7-zip.org/ 7-zip] - Supports strongly-encrypted archives.
* [http://www.axantum.com/axcrypt/ AxCrypt by Axantum]
* [http://lrzip.kolivas.org lrzip] - Compression software for Linux and OSX that supports very high grade password protected encryption
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly encryption (for advanced users)

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

Decrypting and encrypting the wallet.dat every time you start or quit the Bitcoin client can be ''tedious'' (and outright error-prone). If you want to keep your wallet encrypted (except while you're actually running the Bitcoin client), it's better to relegate the automation to a [http://lorelei.kaverit.org/bitcoin.sh small shell script] that handles the en/decryption and starting up Bitcoin client for you (Linux and OSX).

There is also a method to print out and encrypt your wallet.dat as a special, scannable code. See details here: [[WalletPaperbackup]]

==== Password Strength ====
Brute-force password cracking has come a long way. A password including capitals, numbers, and special characters with a length of 8 characters can be trivially solved now (using appropriate hardware). The recommended length is '''at least''' 12 characters long. You can also use a multi-word password and there are techniques to increase the strength of your passwords without sacrificing usability. [http://www.baekdal.com/tips/password-security-usability The Usability of Passwords]

However, simply using dictionary words is also insecure as it opens you up to a dictionary attack. If you use dictionary words, be sure to include random symbols and numbers in the mix as well.

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

===== Choosing A Strong Password =====
Make sure you pick at least one character in each group: 

Lowercase: abcdefghijklmnopqrstuvwxyz
Uppercase: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Number: 1234567890
Symbol: `~!@#$%^&*()-_=+\|[{]};:'",<.>/? (space)

<9 char = unsuitable for use
09 char = insecure
10 char = low security
11 char = medium security
12 char = good security (good enough for your wallet)
13 char = very good, enough for anything.

==== Email-based Archival and Remote Backup ====
One of the simplest methods for storing an 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 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] (after encrypting the wallet first) and [http://en.wikipedia.org/wiki/Comparison_of_online_backup_services others], including the more secure [http://www.spideroak.com SpiderOak].

=== Autmated Backups using Cron, Bash and GNU/Linux ===

Linux users can setup backups using cron by telling it to run a backup script at set intervals of time. Run 'crontab -e' and add this line near the bottom:

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

This cron line will run the /usr/local/bin/backupwallet.sh script 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. You may also wish to ignore the script's output by appending " > /dev/null 2>&1" to the line (this will also prevent emails from being sent).

Create /usr/local/bin/backupwallet.sh:

#!/bin/bash
# /usr/local/bin/backupwallet.sh
#
# Performs backup of bitcoin wallet.
#
# Written by: https://en.bitcoin.it/wiki/Securing_your_wallet

#
# Standard Options
#
TS=$(date "+%Y%m%d-%H%M")
WALLET=/tmp/wallet-${TS}
WALLET_E=/tmp/wallet-${TS}.crypt
BITCOIN=bitcoind # /path/to/bitcoind
GPG=gpg # /path/to/gpg
GPG_USER=username # Username of gpg recipient. User should have gpg setup.
RM=rm
RM_OPTS='--force'
USE_SHRED=0 # Flip to 1 to use `shred` instead of `rm`.
SHRED=shred
SHRED_OPTS='--force --iterations=9 --zero --remove'

#
# Storage Options
# Only 1 set of options should be un-commented (the last one will be used).
# Update CP_DEST paths as neccessary.
#
# CP - Storage on a local machine. Could be Dropbox/Wuala folder.
#CP=cp
#CP_DEST='/var/data/backups/' # '~/Dropbox/', etc.
#
# SSH - Storage on a remote machine.
CP=scp
CP_DEST='remoteuser@example.com:~/wallets/'
#
# S3 - Storage on Amazon's S3. Be sure s3cmd is installed and properly setup.
# You may need "s3cmd put --force" if you use a sub-directory in CP_DEST.
#CP=s3cmd put
#CP_DEST='s3://bucket'

do_clean() {
# Remove temporary wallets.
if [ 1 -eq $USE_SHRED ]; then
$SHRED $SHRED_OPTS $WALLET $WALLET_E
else
$RM $RM_OPTS $WALLET $WALLET_E
fi
}

do_fail() {
do_clean
echo failed!
exit 1
}

# Perform the backup.
echo -n Making backup...
$BITCOIN backupwallet $WALLET
[ ! -s "$WALLET" ] && do_fail # If the backup does not exist or is empty, fail.
echo done.
echo -n Encrypting backup...
$GPG -r $GPG_USER --output $WALLET_E --encrypt $WALLET
[ 0 -ne $? ] && do_fail # If gpg returns a non-zero result, fail.
echo done.
echo -n Copying to backup location...
$CP $WALLET_E "$CP_DEST"
[ 0 -ne $? ] && do_fail # If the $CP command returns a non-zero result, fail.
echo done.
do_clean

exit 0

The shell script:

* Calls bitcoind backupwallet to create a time/date-stamped wallet.
* GPG encrypts the wallet with your public key.
* Copies the result using one of several storage options (cp, scp, and s3cmd).
* Uses the rm or shred command to remove the temporary wallet files.

Be sure to modify the script options to fit your setup. After you save, make sure the file can be executed properly by the cron user. Common permissions for files in /usr/local/bin/ can be applied using (verify with your distribution!):

cd /usr/local/bin/ && chown root:root backupwallet.sh && chmod 755 backupwallet.sh

[[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:
* Shut down the Bitcoin program.
* Copy your backed-up wallet.dat into your bitcoin data directory.
* If copying into existing profile, delete files ''blk*.dat'' to make the client re-download the block chain.

==Erasing Plain-text Wallets==

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, the equivalent of '''shred''' is '''srm''' (introduced in Leopard). Using the Finder to remove files, 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.

==Online and Mobile Wallets==

Thus far, this article has been discussing the security of a wallet file for Bitcoin-QT or bitcoind that is under your sole control. Additional wallets applications and services have become available that offer other features and more convenience but not without introducing additional risk. When storing bitcoins with an [[eWallet]] such as Instawallet or Easywallet, you are essentially storing your private keys or wallet with that provider.

Online wallets have a number of pros and cons to consider. For example, you can access your wallet on any computer in the world, but depending on the service, your bitcoins may be lost if the service is compromised.

Mobile wallet applications are available for Android devices that allow you to send bitcoins by QR code or NFC, but this opens up the possibility of loss if mobile device is compromised. It may be possible to encrypt and backup the wallet or private keys on a mobile device but it is not advisable to store a large amount of bitcoins there without doing your own research and testing.

==See Also==

* [[Data directory]]
* [[How to import private keys]]
* [http://startbitcoin.com/how-to-create-a-secure-bitcoin-wallet/ Secure Bitcoin Wallet Tutorial]
* [[How to set up a secure offline savings wallet]]
* [http://arimaa.com/bitcoin/ Bitcoin Gateway - A Peer-to-peer Bitcoin Vault and Payment Network]
* [http://blog.cyplo.net/2012/04/01/bitcoin-wallet-recovery-photorec/ Find lost wallet eg. after disk format, using Photorec]

[[de:Sichere deine Geldbörse]]
[[es:Cómo asegurar su monedero]]
[[zh-cn:保护你的钱包]]

PHP developer intro

2012-09-10T21:27:10Z

Nubarius: Interwiki link to new Spanish article

'''L'''inux '''A'''pache '''M'''ySQL '''P'''HP + Bitcoin tutorial.

For this introduction we assume that you have GNU/Linux server with Apache and PHP and that you wish to interact with the Bitcoin network from a web application. We assume some knowledge of Bitcoin and experience in PHP.

While this is written for PHP, the same principles apply for other languages. See the associated [[API reference (JSON-RPC)|API reference]] pages for info on other languages.

The easiest way to get started is to run Bitcoin in daemon mode with which PHP communicates via local HTTP requests. A library called [http://jsonrpcphp.org/ JSON-RPC] is used to call the various functions of bitcoind, which will respond back with a [http://en.wikipedia.org/wiki/Json JSON object].

== Setting up Bitcoin ==

You can download the Bitcoin daemon from the [[Main_Page|homepage]] and run one of the included binaries or compile your own from the included source code. See [[Running Bitcoin]] for details on configuring bitcoind.

Before running bitcoind you will need to create a configuration file in the Bitcoin data directory (~/.bitcoin/bitcoin.conf on Linux):
<source lang="bash">
rpcuser=user
rpcpassword={you MUST pick a unique password to be secure}
</source>
If you miss this step, bitcoind will remind you.

Now run bitcoind:
<source lang="bash">
$ ./bitcoind
# wait a few seconds for it to start up
$ ./bitcoind getinfo
# various information will be shown. If you get an error, try again until you see some useful output.
$ ./bitcoind help
# get help on commands, note no dash before help
</source>

Bitcoin will begin synchronizing with the network and downloading a complete copy of the block chain. As of August 2012, more than 2gb of data must be downloaded and verified during this process. It may take two or more hours to complete. You will know when it's done when the block count reaches the [http://blockexplorer.com/q/getblockcount current count].

== Getinfo (Bitcoind's version of Hello World) ==

Assuming Bitcoin has finished the initialisation process; download the file jsonRPCClient.php from [http://jsonrpcphp.org/ JSON-RPC PHP] and place it in a web-accessible location.

Second, create a PHP file with the following and visit it with your browser to test.

<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 "</pre>";
</source>

== Precision ==

Bitcoin amounts can range from 1 (0.00000001 BTC) to nearly 2,100,000,000,000,000 (21,000,000 BTC). To avoid rounding errors, you must make sure your PHP implementation supports the full range of Bitcoin values without losing precision. Most PHP implementations use IEEE 64-bit double-precision floating point numbers with 53 bits of precision, which is enough to correctly represent the full range of bitcoin values.

See [[Proper Money Handling (JSON-RPC)]] for more information.

If your PHP implementation does not support 64-bit numbers (again, this is very rare), you must use a version of bitcoind that sends values as strings (genjix maintains a fork at http://github.com/genjix/bitcoin) and use the [http://php.net/manual/en/ref.gmp.php GMP] and [http://php.net/manual/en/ref.bc.php BC Math] libraries for all calculations involving bitcoin amounts.

== Accounts ==

In Bitcoin, money is sent to addresses and many addresses can be held by one wallet. The balance shown by default in bitcoind is the sum of the bitcoins in all the addresses in the wallet.

Bitcoin goes another step. You can have [[Accounts explained|accounts]]. Each account holds multiple addresses and acts like a mini-bitcoind.

<source lang="bash">
$ ./bitcoind listaccounts
# show list of accounts and various info for each one
$ ./bitcoind getaccountaddress user889
# get an address to receive money to that is unique for the account user889
$ ./bitcoind getbalance user889
# get the sum of all the money in the addresses owned by the account user889
</source>

In your application, each user should have a unique username. You may then query bitcoind for a unique address using $bitcoin->getaccountaddress("user889"); [gets the first address for user889] or $bitcoin->getnewaddress("user889"); [creates a new address for user889].

The customer then deposits to this address.

You can check the funds for that customer by doing $bitcoin->getbalance("user889", 4);. The 4 indicates the minimum number of confirmations we will accept before assuming this payment is valid.

If you will be using accounts for multiple deposits and withdrawals long-term, you may want to consider tracking user balances in your own database. This simplifies transfers between your application's accounts and decouples your accounts from the Bitcoin wallet.

=== getnewaddress vs getaccountaddress ===

Using getnewaddress helps increase maintain anonymity of your users by making it hard for a malicious agent to track payments flowing through your application. Running getnewaddress too often, however, will cause your wallet to become filled with many empty addresses.

It is therefore recommended to in some way limit the number of unfunded addresses each user can request. Here is an example using sessions:
<source lang="php">
<?php
require_once('jsonRPCClient.php');
$bitcoin = new jsonRPCClient('http://root:root@127.0.0.1:8332/');
# now check for appropriate funds in user account
try {
$username = ...
if(isset($_SESSION['sendaddress']))
$sendaddress = $_SESSION['sendaddress'];
else {
$sendaddress = $bitcoin->getnewaddress($username);
$_SESSION['sendaddress'] = $sendaddress;
}
$balance = $bitcoin->getbalance($username);
}
catch (Exception $e) {
die("Server error! Please contact the admin.");
}
?>
</source>

This creates a new address at the beginning of every new session, and stores it in the session variable.

==See Also==

* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Merchant Howto]]

[[es:Introducción para desarrolladores de PHP]]

[[Category:Developer]]

Release process

2012-09-09T22:20:30Z

Nubarius: Interwiki link to new Spanish article

== Bitcoin Open Source Release Process ==

Releases to the [[Original_Bitcoin_client|Bitcoin.org client]] project are built and released using this process:

* Labeled in github
* Binaries are created for the platforms affected (usually all, Windows, Mac and Linux).
* Binary file checksum(s) is(are) calculated and a message with those are signed by a core developer.
** sha256 checksum
* Files used to build are checksummed and submitted to the Gitian.sigs project on github.
* Uploaded to sourceforge
* Blog post on Bitcoin.org
* Forum post on BitcoinTalk.org

==Verifying The Download==

To verify the checksum for a binary download, first ensure the checksum file is secure by decrypting the SHA256SUMS.asc file:
$ gpg --decrypt SHA256SUMS.asc

Then verify the file checksum:
$ openssl dgst -sha256 [binary release archive]

Verify that the checksum matches the one in SHA256SUMS.asc

==External Links==

* [https://github.com/bitcoin/bitcoin Bitcoin.org client source] project on Github
* [https://github.com/bitcoin/gitian.sigs Gitain.sigs] Trusted build process signatures on Github
* [http://bitcoin.org Bitcoin.org] website with releases

==See Also==

* [[Development process]]
* [[Original Bitcoin client]]
* [[:Category:Open_Source|Open source]]

[[es:Proceso de publicación de versiones]]

[[Category:Developer]]

Development process

2012-09-09T22:11:03Z

Nubarius: Interwiki link to new Spanish article

== Bitcoin Open Source Development Process ==

The [[Original_Bitcoin_client|Bitcoin client]] project has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development. The Linux Kernel development process is being used as the model for how changes flow into the original Bitcoin application:
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [http://www.bitcoin.org/smf/index.php?board=6.0 Development and Technical Forum].
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a "release candidate" and then the official, stable, released bitcoin.
# After being accepted into the mainline master branch, bugfixes are merged or backported into the current stable branch, which periodically releases stable older versions.

Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/master/doc/coding.txt coding.txt] for a description of the bitcoin coding style.

==See Also==

* [[Release process]]
* [[Original Bitcoin client]]
* [[:Category:Open_Source|Open source]]

[[es:Proceso de desarrollo]]

[[Category:Developer]]

Running Bitcoin

2012-09-09T20:42:34Z

Nubarius: Interwiki link to new Spanish article

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__
==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:
bitcoind [options]
bitcoind [options] <command> [params] Send command to -server or bitcoind
bitcoind [options] help List commands
bitcoind [options] help <command> Get help for a command
Options:
-conf=<file> Specify configuration file (default: bitcoin.conf)
-pid=<file> Specify pid file (default: bitcoind.pid)
-gen Generate coins
-gen=0 Don't generate coins
-min Start minimized
-datadir=<dir> Specify data directory
-timeout=<n> Specify connection timeout (in milliseconds)
-proxy=<ip:port> Connect through socks4 proxy
-dns Allow DNS lookups for addnode 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
-connect=<ip> Connect only to the specified node
-nolisten Don't accept connections from outside
-nodnsseed Don't bootstrap list of peers using DNS
-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: 10000)
-maxsendbuffer=<n> Maximum per-connection send buffer, <n>*1000 bytes (default: 10000)
-noupnp Don't attempt to use UPnP to map the listening port
-paytxfee=<amt> Fee per KB to add to transactions you send
-daemon Run in the background as a daemon and accept commands
-testnet Use the test network
-debug Output extra debugging information
-logtimestamps Prepend debug output with timestamp
-printtoconsole Send trace/debug info to console instead of debug.log file
-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)
-rpcallowip=<ip> Allow JSON-RPC connections from specified IP address
-rpcconnect=<ip> Send commands to node running on <ip> (default: 127.0.0.1)
-keypool=<n> Set key pool size to <n> (default: 100)
-rescan Rescan the block chain for missing wallet transactions

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+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH)

Additional (Supported but not listed in -? help):
-checkblocks Rescan the whole blockchain (can take very much time)

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

# Do not use Internet Relay Chat (irc.lfnet.org #bitcoin channel) to
# find other peers.
#noirc=0

# 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):
#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

# Use SSE instructions to try to generate bitcoins faster.
#4way=1

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

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

[[es:Ejecución de Bitcoin]]

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

Bitcoin Core

2012-09-09T19:51:10Z

Nubarius: Added interwiki link to new Spanish article

'''Bitcoin-Qt''' is an MIT-licenced Qt4 Bitcoin client written and maintained by Wladimir J. van der Laan, and has been distributed together with [[bitcoind]] since version 0.5.

==Features==
* Compatibility with Linux (both GNOME and KDE), Mac OS X and Windows
* All functionality of the original wxWidgets client
* User friendly, tabbed interface
* Asks for confirmation before sending coins
* CSV export of transactions
* Clearer transaction list with status icons and real-time filtering
* Progress bar on initial block download
* Languages: Dutch, English, German, many more
* Sendmany support in UI (send to multiple recipients in one transaction)
* Multiple [[Units|unit]] support, can show subdivided bitcoins (mBTC, µBTC) for users that like large numbers (only decimal units)
* Splash screen that details progress

==Current version==
Source code (and build instructions for supported platforms) can be found at the [https://github.com/bitcoin/bitcoin Bitcoin GitHub page].

==External Links==

* [https://forum.bitcoin.org/index.php?topic=15276.0 Forum thread] (includes screenshots)
* [https://github.com/bitcoin/bitcoin Current GitHub repository shared with bitcoind]

==See also==

* [[QBitcoin]]
* [[bitcoind]]

[[es:Bitcoin-Qt]]

[[Category:User Interfaces]]
[[Category:Frontends]]
[[Category:Free Software]]
[[Category:Open Source]]

Bitcoind

2012-09-09T19:36:01Z

Nubarius: Added link to new Spanish article (plus two minor corrections in the English text)

Bitcoind is a program that implements the Bitcoin protocol for command line and remote procedure call (RPC) use. It is also the first Bitcoin client in the network's history. It is available under the [http://www.opensource.org/licenses/mit-license.php MIT license] in 32-bit and 64-bit versions for Windows, GNU/Linux-based OSes, and Mac OS X.

Prior to version 0.5, this service-provider client used a wxWidgets GUI as its default GUI. It is now instead bundled with [[Bitcoin-Qt]].

=== Running ===

See [[Running_bitcoind|running bitcoind]] for more detail and an example of the configuration file.

Bitcoind is a headless daemon, and also bundles a testing tool for the same daemon. It provides a JSON-RPC interface, allowing it to be controlled locally or remotely which makes it useful for integration with other software or in larger payment systems. [[Original Bitcoin client/API Calls list|Various commands]] are made available by the API.

To use locally, first start the program in daemon mode:
:bitcoind -daemon

Then you can use the same program to execute [[Original Bitcoin client/API Calls list|API commands]], e.g.:
:bitcoind getinfo
:bitcoind listtransactions

To stop the bitcoin daemon, execute:
:bitcoind stop

==History==
* Version 0.4.0 was released for all supported platforms on September 23th, 2011 <ref>[https://bitcointalk.org/index.php?topic=45410.0 Bitcoin version 0.4.0 released]</ref>.
* Version 0.3.24 was released for all supported platforms on July 8th, 2011 <ref>[http://forum.bitcoin.org/index.php?topic=27187.0 Bitcoin version 0.3.24 released]</ref>.
* Version 0.3.23 was released for all supported platforms on June 13th, 2011 <ref>[http://forum.bitcoin.org/index.php?topic=16553.0 Bitcoin version 0.3.23 released]</ref>.
* Version 0.3.22 was released for all supported platforms on May 19th, 2011 <ref>[http://forum.bitcoin.org/index.php?topic=8894.0 Version 0.3.22]</ref>.
* Version 0.3.20 was released for all supported platforms on February 21st, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=3704.0 Version 0.3.20]</ref>.

==Theory of Operation==

bitcoind is a multithreaded C++ program. It is designed to be portable across Windows, Mac, and Linux systems. The multithreaded aspect leads to some complexity and the use of certain code patterns to deal with concurrency that may be unfamiliar to many programmers. Also, the code is aggressive in the use of C++ constructs, so it will help to be fluent with map, multimap, set, string, vector, iostream, and templates. As is typical of a C++ program, a lot of code tends to end up in the header files so be sure to search both the .cpp and .h files when looking for a function.

The client is oriented around several major operations, which are described in separate detailed articles and summarized in the following sections.

===[[Satoshi Client Initialization and Startup|Initialization and Startup]]===
Upon startup, the client performs various initialization routines including starting multiple threads to handle concurrent operations.

===[[Satoshi Client Node Discovery|Node Discovery]]===
The client uses various techniques to find out about other Bitcoin nodes that are currently connected to the network.

===[[Satoshi Client Node Connectivity|Node Connectivity]]===
The client initiates and maintains connections to other nodes.

===[[Satoshi Client Sockets and Messages|Sockets and Messages]]===
The client processes messages from other nodes and sends messages to other nodes using socket connections.

===[[Satoshi Client Block Exchange|Block Exchange]]===
Nodes advertise their inventory of blocks to each other and exchange blocks to build block chains.

===[[Satoshi Client Transaction Exchange|Transaction Exchange]]===
Nodes exchange and relay transactions with each other. The client associates transactions with bitcoin addresses in the local wallet.

===Wallet Services===
The client can create transactions using the local wallet. The client associates transactions with bitcoin addresses in the local wallet. The client provides a service for managing the local wallet.

===RPC Interface===
The client offers an JSON-RPC interface over HTTP over sockets to perform various operational functions and to manage the local wallet.

===User Interface===
Bitcoind's current user interface is the command line while it used to be based on [http://www.wxwidgets.org wxWidgets]. A graphical user interface is now provided by [[Bitcoin-qt]] in version 0.5+ for the reference client.

==Troubleshooting==

===I get "Error loading blkindex.bat" when I try to run the client===

blkindex.dat is part of the database that stores the local copy of the blockchain which may have become corrupted. Open the Bitcoin data dir:

Windows: %APPDATA%\Bitcoin
Linux: ~/.bitcoin
Mac: ~/Library/Application Support/Bitcoin/

Make a backup of that entire folder, then delete everything EXCEPT wallet.dat. Start bitcoind again and it will download a fresh copy of the blockchain.

==See Also==

* [[Original Bitcoin client/API calls list]]
* [[Protocol specification|Bitcoin network protocol]]
* [[Development process]]
* [[Release process]]
* [[Changelog]]

==External Links==
* [https://github.com/bitcoin/bitcoin/ Bitcoin Client project on Github]

==References==
<references />
`
[[es:Bitcoind]]

[[Category:Nodes]]
[[Category:Wallets]]
[[Category:User Interfaces]]
[[Category:Clients]]
[[Category:Developer]]
[[Category:Technical]]
[[Category:Free Software]]
[[Category:License/MIT-X11]]
[[Category:Open Source]]

Satoshi Nakamoto

2012-09-09T15:08:36Z

Nubarius: Interwiki link to Spanish article

[[File:Satoshi-nakamoto.gif|thumb|200px|right|Picture of Satoshi Nakamoto.]]

'''Satoshi Nakamoto''' is the founder of [[Bitcoin]] and initial creator of the [[Original Bitcoin client]]. He has said in a P2P foundation profile<ref name="p2p_f_profile">[http://p2pfoundation.ning.com/profile/SatoshiNakamoto Satoshi Nakamoto profile on P2P Foundation]</ref> that he is from Japan. Beyond that, not much else is known about him and his identity. He has been working on the Bitcoin project since 2007.<ref>[http://www.bitcoin.org/smf/index.php?topic=13.msg46#msg46 Re: Questions about Bitcoin]</ref>

His involvement in the Bitcoin project had tapered and by late 2010 it has ended. The most recent messages reportedly indicate that Satoshi is "gone for good"<ref>[http://bitcoinstats.com/irc/logs/2011/04/26/5#l445170 Transcript of #bitcoin-dev for 2011/04/26]</ref>.

==Possible Motives==

He left some clues about why he is doing this project with the inclusion of the following text in the [[Genesis block]], "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".

Some interesting quotes:
<blockquote>Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of
freedom for several years.

Governments are good at cutting off the heads of a centrally controlled
networks like Napster, but pure P2P networks like Gnutella and Tor seem to be
holding their own.<ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg09971.html Re: Bitcoin P2P e-cash paper Fri, 07 Nov 2008 09:30:36 -0800]</ref></blockquote>

<blockquote>It's very attractive to the libertarian viewpoint if we can explain it
properly. I'm better with code than with words though. <ref>[http://www.mail-archive.com/cryptography@metzdowd.com/msg10001.html Re: Bitcoin P2P e-cash paper Fri, 14 Nov 2008 14:29:22]</ref></blockquote>

==Possible identity==

His identity and nationality are unknown. The few bits of information available<ref name="p2p_f_profile"/> about him point to Japan, he never wrote a single line of Japanese, the Bitcoin client has no Japanese version and there is no Japanese page on [http://bitcoin.org bitcoin.org].

He is entirely unknown outside of Bitcoin as far as anyone can tell, and his PGP key was created just months prior to the date of the genesis block. He seems to be very familiar with the cryptography mailing list, but there are no non-Bitcoin posts from him on it. He has used an email address from an anonymous mail hosting service (vistomail) as well as one from a free webmail account (gmx.com) and sends mail when connected via Tor. Some have speculated that his entire identity was created in advance in order to protect himself or the network. Perhaps he chose the name Satoshi because it can mean "wisdom" or "reason".

==External links==
* [http://forum.bitcoin.org/Satoshi_Nakamoto.asc Satoshi's PGP public key]
* [http://www.bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System] Paper
* [http://sourceforge.net/users/s_nakamoto SourceForge page]

==References==
<references/>

[[de:Satoshi Nakamoto]]
[[es:Satoshi Nakamoto]]

[[Category:Individuals]]