Bitcoin Wiki - User contributions [en]

Original Bitcoin client/API calls list

2014-04-02T21:32:49Z

Cdhowie:

Bitcoin API call list (as of version 0.8.0)

== Common operations ==

=== Listing my bitcoin addresses ===

Listing the bitcoin [[address|addresses]] in your wallet is easily done via ''listreceivedbyaddress''. It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true.

[[accounts explained|Accounts]] are used to organize addresses.

== Full list ==

Required arguments are denoted inside < and > Optional arguments are inside [ and ].

{|class="wikitable"
! Command !! Parameters !! Description !! Requires unlocked wallet? (v0.4.0+)
|-
| addmultisigaddress || <nrequired> <'["key","key"]'> [account] || Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. || N
|-
| addnode || <node> <add/remove/onetry> || '''version 0.8''' Attempts add or remove <node> from the addnode list or try a connection to <node> once. || N
|-
| backupwallet || <destination> || Safely copies wallet.dat to destination, which can be a directory or a path with filename. || N
|-
| createmultisig || <nrequired> <'["key,"key"]'> || Creates a multi-signature address and returns a json object ||
|-
| createrawtransaction || [{"txid":txid,"vout":n},...] {address:amount,...} || '''version 0.7''' Creates a [[Raw Transactions|raw transaction]] spending given inputs. || N
|-
| decoderawtransaction || <hex string> || '''version 0.7''' Produces a human-readable JSON object for a [[Raw Transactions|raw transaction]]. || N
|-
| dumpprivkey || <bitcoinaddress> || Reveals the private key corresponding to <bitcoinaddress> || Y
|-
| encryptwallet || <passphrase> || Encrypts the wallet with <passphrase>. || N
|-
| getaccount || <bitcoinaddress> || Returns the account associated with the given address. || N
|-
| getaccountaddress || <account> || Returns the current bitcoin address for receiving payments to this account. If <account> does not exist, it will be created along with an associated new address that will be returned. || N
|-
| getaddednodeinfo || <dns> [node] || '''version 0.8''' Returns information about the given added node, or all added nodes
(note that onetry addnodes are not listed here)
If dns is false, only a list of added nodes will be provided,
otherwise connected information will also be available.
|-
| getaddressesbyaccount || <account> || Returns the list of addresses for the given account. || N
|-
| getbalance || [account] [minconf=1] || If [account] is not specified, returns the server's total available balance.<br/>If [account] is specified, returns the balance in the account. || N
|-
| getbestblockhash || || '''recent git checkouts only''' Returns the hash of the best (tip) block in the longest block chain. || N
|-
| getblock || <hash> || Returns information about the block with the given hash. || N
|-
| getblockcount || || Returns the number of blocks in the longest block chain. || N
|-
| getblockhash || <index> || Returns hash of block in best-block-chain at <index>; index 0 is the [[genesis block]] || N
|-
| getblocknumber || || '''Deprecated'''. '''Removed in version 0.7'''. Use getblockcount. || N
|-
| getblocktemplate || [params] || Returns data needed to construct a block to work on. See [[ BIP_0022]] for more info on params.|| N
|-
| getconnectioncount || || Returns the number of connections to other nodes. || N
|-
| getdifficulty || || Returns the proof-of-work difficulty as a multiple of the minimum difficulty. || N
|-
| getgenerate || || Returns true or false whether bitcoind is currently generating hashes || N
|-
| gethashespersec || || Returns a recent hashes per second performance measurement while generating. || N
|-
| getinfo || || Returns an object containing various state info. || N
|-
| getmemorypool || [data] || '''Replaced in v0.7.0 with getblocktemplate, submitblock, getrawmempool''' || N
|-
| getmininginfo || || Returns an object containing mining-related information:
* blocks
* currentblocksize
* currentblocktx
* difficulty
* errors
* generate
* genproclimit
* hashespersec
* pooledtx
* testnet
|| N
|-
| getnewaddress || [account] || Returns a new bitcoin address for receiving payments. If [account] is specified payments received with the address will be credited to [account]. || N
|-
| getpeerinfo || || '''version 0.7''' Returns data about each connected node. || N
|-
| getrawchangeaddress || [account]|| '''recent git checkouts only''' Returns a new Bitcoin address, for receiving change. This is for use with raw transactions, NOT normal use. || Y
|-
| getrawmempool || || '''version 0.7''' Returns all transaction ids in memory pool || N
|-
| getrawtransaction || <txid> [verbose=0] || '''version 0.7''' Returns [[Raw Transactions|raw transaction]] representation for given transaction id. || N
|-
| getreceivedbyaccount || [account] [minconf=1] || Returns the total amount received by addresses with [account] in transactions with at least [minconf] confirmations. If [account] not provided return will include all transactions to all accounts. (version 0.3.24) || N
|-
| getreceivedbyaddress || <bitcoinaddress> [minconf=1] || Returns the amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations. It correctly handles the case where someone has sent to the address in multiple transactions. Keep in mind that addresses are only ever used for receiving transactions. Works only for addresses in the local wallet, external addresses will always show 0. || N
|-
| gettransaction || <txid> || Returns an object about the given transaction containing:
* "amount" : total amount of the transaction
* "confirmations" : number of confirmations of the transaction
* "txid" : the transaction ID
* "time" : time associated with the transaction<ref>From block timestamp, unless transaction was already in memory pool then the local time when the client added the transaction to its memory pool</ref>.
* "details" - An array of objects containing:
** "account"
** "address"
** "category"
** "amount"
** "fee"
|| N
|-
| gettxout || <txid> <n> [includemempool=true] || Returns details about an unspent transaction output (UTXO) || N
|-
| gettxoutsetinfo || || Returns statistics about the unspent transaction output (UTXO) set || N
|-
| [[getwork]] || [data] || If [data] is not specified, returns formatted hash data to work on:
* "midstate" : precomputed hash state after hashing the first half of the data
* "data" : block data
* "hash1" : formatted hash buffer for second hash
* "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
|| N
|-
| help || [command] || List commands, or get help for a command. || N
|-
| importprivkey || <bitcoinprivkey> [label] [rescan=true]|| Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a [[How_to_import_private_keys#Import_Private_key.28s.29|rescan]] is done, looking for existing transactions. '''Optional [rescan] parameter added in 0.8.0.''' Note: There's no need to import public key, as in [[Elliptic_Curve_Digital_Signature_Algorithm|ECDSA]] (unlike RSA) this can be computed from private key. || Y
|-
| keypoolrefill || || Fills the keypool, requires wallet passphrase to be set. || Y
|-
| listaccounts || [minconf=1] || Returns Object that has account names as keys, account balances as values. || N
|-
| listaddressgroupings || || '''version 0.7''' Returns all addresses in the wallet and info used for coincontrol. || N
|-
| listreceivedbyaccount || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "account" : the account of the receiving addresses
* "amount" : total amount received by addresses with this account
* "confirmations" : number of confirmations of the most recent transaction included
|| N
|-
| listreceivedbyaddress || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "address" : receiving address
* "account" : the account of the receiving address
* "amount" : total amount received by the address
* "confirmations" : number of confirmations of the most recent transaction included
To get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 true
|| N
|-
| listsinceblock|| [blockhash] [target-confirmations] || Get all transactions in blocks since block [blockhash], or all transactions if omitted. [target-confirmations] intentionally '''does not''' affect the list of returned transactions, but only affects the returned "lastblock" value.[https://github.com/bitcoin/bitcoin/pull/199#issuecomment-1514952] || N
|-
| listtransactions || [account] [count=10] [from=0] || Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided it'll return recent transactions from all accounts.
|| N
|-
| listunspent || [minconf=1] [maxconf=999999] || '''version 0.7''' Returns array of unspent transaction inputs in the wallet. || N
|-
| listlockunspent || || '''version 0.8''' Returns list of temporarily unspendable outputs
|-
| lockunspent || <unlock?> [array-of-objects] || '''version 0.8''' Updates list of temporarily unspendable outputs
|-
| move || <fromaccount> <toaccount> <amount> [minconf=1] [comment] || Move from one account in your wallet to another || N
|-
| sendfrom || <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object). || Y
|-
| sendmany || <fromaccount> {address:amount,...} [minconf=1] [comment] || amounts are double-precision floating point numbers || Y
|-
| sendrawtransaction || <hexstring> || '''version 0.7''' Submits [[Raw Transactions|raw transaction]] (serialized, hex-encoded) to local node and network. || N
|-
| sendtoaddress || <bitcoinaddress> <amount> [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. || Y
|-
| setaccount || <bitcoinaddress> <account> || Sets the account associated with the given address. Assigning address that is already assigned to the same account will create a new address associated with that account. || N
|-
| setgenerate || <generate> [genproclimit] || <generate> is true or false to turn generation on or off.<br/>Generation is limited to [genproclimit] processors, -1 is unlimited. || N
|-
| settxfee || <amount> || <amount> is a real and is rounded to the nearest 0.00000001 || N
|-
| signmessage || <bitcoinaddress> <message> || Sign a message with the private key of an address. || Y
|-
| signrawtransaction || <hexstring> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] || '''version 0.7''' Adds signatures to a [[Raw Transactions|raw transaction]] and returns the resulting raw transaction. || Y/N
|-
| stop || || Stop bitcoin server. || N
|-
| submitblock || <hex data> [optional-params-obj] || Attempts to submit new block to network. || N
|-
| validateaddress || <bitcoinaddress> || Return information about <bitcoinaddress>. || N
|-
| verifymessage || <bitcoinaddress> <signature> <message> || Verify a signed message. || N
|-
| walletlock || || Removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase again before being able to call any methods which require the wallet to be unlocked. || N
|-
| walletpassphrase || <passphrase> <timeout> || Stores the wallet decryption key in memory for <timeout> seconds. || N
|-
| walletpassphrasechange || <oldpassphrase> <newpassphrase> || Changes the wallet passphrase from <oldpassphrase> to <newpassphrase>. || N

|}

==Error Codes==

See [https://github.com/bitcoin/bitcoin/blob/master/src/rpcprotocol.h#L34 rpcprotocol.h] for the list of error codes and their meanings.

==See Also==

* [[Original Bitcoin client]]
* [[Protocol specification]]
* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Elis-API]] - A more detailed version of this page - for developers!
* [http://code.gogulski.com/bitcoin-php/class_bitcoin_client.html PHP BitcoinClient Class Reference]

==References==
<references />

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

User:Cdhowie

2014-03-27T17:32:13Z

Cdhowie: Blanked the page

BIP 0020

2011-12-19T19:19:48Z

Cdhowie: /* Use-cases */

This is about creating a URI scheme for bitcoin.
Previous discussion was in [http://www.bitcoin.org/smf/index.php?topic=55.0 this forum thread].
x-btc specification is at [[x-btc]].

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==Specification==

[] means optional, <> are placeholders

bitcoin:<address>[?][amount=<size>][&][label=<label>][&][message=<message>][&][send=<private key>]

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of base bitcoin units (cuBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC nor TonalBitCoins/TBC; see below)
*private key: used to send bitcoin, rather than to request them

==== Transfer amount/size ====

If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal.
The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
That is, "X8" multiplies your number by 100,000,000.
For decimal values, this means the standard BTC unit.
For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).
If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers.
I.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC.
When specifying bitcoin base units, "X0" SHOULD be used.

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3X8&label=Luke-Jr

Request 400 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x400X4

Request 4000 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x4X7

Request 5 uBTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=5X2

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50X8&label=Luke-Jr&message=Donation%20for%20project%20xyz

Send 1 BTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=1X8&send=S4b3N3oGqDqR5jNuxEvDwf

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | pkparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = digits [ "X" digits ]
amounthex = "x" hexdigits [ "X" hexdigits ]
labelparam = "label=" *uchar
messageparam = "label=" *uchar
sendparam = "send=" *uchar

=== Parsing amount ===
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1e8)
);
}

==== Python ====
m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
if m.group(5):
amount = float(int(m.group(5), 16))
if m.group(7):
amount += float(int(m.group(7), 16)) * pow(16, -(len(m.group(7))))
if m.group(9):
amount *= pow(16, int(m.group(9), 16))
else:
amount *= 0x10000
else:
amount = Decimal(m.group(2))
if m.group(4):
amount *= 10 ** int(m.group(4))
else:
amount *= 100000000

==== C# ====
Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
Match match = amountExpression.Match(value);
if (match.Success)
{
if (match.Groups[5].Success)
{
long hexDecimal = 0;
if (match.Groups[7].Success)
hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);

long hexExponent = 0x10000;
if (match.Groups[9].Success)
hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));

Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
}
else
{
long decimalExponent = 100000000;
if (match.Groups[4].Success)
decimalExponent = (long)Math.Pow(10, int.Parse(match.Groups[4].Value));
Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
}
}

==Requirements==

===Payment identifiers, not person identifiers===
In my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. So the URIs should represent first and foremost payments. If it represents something else, this needs to be specified. Thus
<code>
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L
</code>
represents a '''request for payment''' to me using my bitcoin address, not my bitcoin address itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the address filled in. You then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the address". But the point I am trying to make is that the default use of the URI should be for payment, nor for exchanging addresses.

===Sending money===
To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:

<code>
<pubkey> OP_CHECKSIG
</code>

Construct an address from the public key. Encode the URI as below:

<code>
bitcoin:<address>?send=<base 58 encoded private key>
</code>

You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:

<code>
<sig>
</code>

This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.

===Accessibility===
'''Imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx and very much approve of its accessibility. Should someone from the outside happen to see such a URI, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic; the chance that someone googles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

For the same reason I am for using '&' as a delimiter for key-value pairs. People know it from URLs. Make it easy for people to understand what is going on.

===Keep it simple===
Don't explicitly write down information that can be inferred. Don't mark the address as an address. If there is no address, this does lose much of its utility. We could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50X8
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===Use-cases===
Before the URI scheme is finalised one should think long and hard about use cases. in what circumstances will which people use this, and for what?
* an online shop has a 'buy this' link, which uses the URI scheme.
**PROBLEM: click on the link opens the application; how does the merchant notice this?
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via HTTP request.
**PROBLEM: the time problem (~10 minutes) is very apparent here; nobody wants to wait 10 minutes for the transaction to be confirmed.
***For micropayment-style digital content (songs, for example) it's probably not necessary to wait for any confirmation at all, since there is low risk of a double-spend attack for payments of a small amount.
***For physical goods, the merchant can tell the client that their transaction is pending when it first notices the transaction, and that payment is complete when the number of confirmations is large enough. The buyer isn't going to sit there and wait anyway; nobody sits at their computer until their credit card gets charged when buying physical goods.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI so that the online client gets a notice?
***POSSIBLE SOLUTION: Small application and/or browser plugins to redirect the handler call to the designated online wallet.

===Backwards compatibility===
We want URIs generated in 2011 to still work in 2036. Think about extensibility. Of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. This should be the best we can do, but it should not be seen as set in stone. Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "I just upgraded to this shiny new version. What? It doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

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

BIP 0020

2011-12-19T19:18:46Z

Cdhowie:

This is about creating a URI scheme for bitcoin.
Previous discussion was in [http://www.bitcoin.org/smf/index.php?topic=55.0 this forum thread].
x-btc specification is at [[x-btc]].

==RFC 3986==
'''the following is taken from wikipedia'''

Internet standard [http://rfc.net/std0066.html STD 66] (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:

<code><nowiki><scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]</nowiki></code>

The '''scheme name''' consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").

The '''hierarchical part''' of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an ''authority'' part and an optional ''path''.

* The '''authority''' part holds an optional user information part terminated with "@" (e.g. <code><nowiki>username:password@</nowiki></code>), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".

* The '''path''' part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.

The '''query''' is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <code><nowiki><key>=<value></nowiki></code> pairs separated by a semicolon<ref>
RFC 1866 section 8.2.1 : by Tim Berners-Lee in 1995 encourages CGI authors to support ';' in addition to '&'.
</ref><ref>
[http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.2.2 HTML 4.01 Specification: Implementation, and Design Notes]: "CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
</ref><ref>
[http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT26 Hypertext Markup Language - 2.0]
"CGI implementors are encouraged to support the use of ';' in place of '&' "
</ref> or separated by an ampersand, for example:
Semicolon: <code><nowiki>key1=value1;key2=value2;key3=value3</nowiki></code>
Ampersand: <code><nowiki>key1=value1&key2=value2&key3=value3</nowiki></code>

The '''fragment''' is an optional part separated from the front parts by a hash ("#"). It holds additional identifying information that provides direction to a secondary resource, e.g. a section heading in an article identified by the remainder of the URI. When the primary resource is an HTML document, the '''fragment''' is often an <code>id</code> attribute of a specific element and web browsers will make sure this element is visible.

==Specification==

[] means optional, <> are placeholders

bitcoin:<address>[?][amount=<size>][&][label=<label>][&][message=<message>][&][send=<private key>]

=== Query Keys ===

*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: optional message that is shown to the user after scanning the QR code
*size: amount of base bitcoin units (cuBTCents/TBCᵇ-- NOT full DecimalBitCoins/BTC nor TonalBitCoins/TBC; see below)
*private key: used to send bitcoin, rather than to request them

==== Transfer amount/size ====

If an amount is provided, it may be specified either in decimal or, when prefixed with a single "x" character, hexadecimal.
The number SHOULD be followed by "X" <digits> to signify an exponent to the base multiplier.
That is, "X8" multiplies your number by 100,000,000.
For decimal values, this means the standard BTC unit.
For hexadecimal values, this means ᵇTBC units (which are equivalent to 42.94967296 BTC).
If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, and X4 for hexadecimal numbers.
I.e. amount=50.00 is treated as 50 BTC, and amount=x40 is treated as 40 TBC.
When specifying bitcoin base units, "X0" SHOULD be used.

=== Examples ===

Just the address:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L

Address with name:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?label=Luke-Jr

Request 20.30 BTC to "Luke-Jr":
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=20.3X8&label=Luke-Jr

Request 400 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x400X4

Request 4000 TBC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=x4X7

Request 5 uBTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=5X2

Request 50 BTC with message:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=50X8&label=Luke-Jr&message=Donation%20for%20project%20xyz

Send 1 BTC:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=1X8&send=S4b3N3oGqDqR5jNuxEvDwf

Characters must be URI encoded properly.

=== BNF syntax ===

bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ]
bitcoinaddress = FIXME :)
bitcoinversion = "1.0"
bitcoinparams = *bitcoinparam
bitcoinparam = amountparam | labelparam | messageparam | pkparam
amountparam = "amount=" amount
amount = amountdecimal | amounthex
amountdecimal = digits [ "X" digits ]
amounthex = "x" hexdigits [ "X" hexdigits ]
labelparam = "label=" *uchar
messageparam = "label=" *uchar
sendparam = "send=" *uchar

=== Parsing amount ===
==== ECMAScript ====
reAmount = /^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$/i;
function parseAmount(txt) {
var m = txt.match(reAmount);
return m[5] ? (
(
parseInt(m[5], 16) +
(m[7] ? (parseInt(m[7], 16) * Math.pow(16, -(m[7].length))) : 0)
) * (
m[9] ? Math.pow(16, parseInt(m[9], 16)) : 0x10000
)
) : (
m[2]
*
(m[4] ? Math.pow(10, m[4]) : 1e8)
);
}

==== Python ====
m = re.match(r'^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$', amount, re.IGNORECASE)
if m.group(5):
amount = float(int(m.group(5), 16))
if m.group(7):
amount += float(int(m.group(7), 16)) * pow(16, -(len(m.group(7))))
if m.group(9):
amount *= pow(16, int(m.group(9), 16))
else:
amount *= 0x10000
else:
amount = Decimal(m.group(2))
if m.group(4):
amount *= 10 ** int(m.group(4))
else:
amount *= 100000000

==== C# ====
Regex amountExpression = new Regex(@"^(([\d.]+)(X(\d+))?|x([\da-f]*)(\.([\da-f]*))?(X([\da-f]+))?)$", RegexOptions.IgnoreCase);
Match match = amountExpression.Match(value);
if (match.Success)
{
if (match.Groups[5].Success)
{
long hexDecimal = 0;
if (match.Groups[7].Success)
hexDecimal = Convert.ToInt64(match.Groups[7].Value, 16) * (long)Math.Pow(16, -match.Groups[7].Length);

long hexExponent = 0x10000;
if (match.Groups[9].Success)
hexExponent = (long)Math.Pow(16, Convert.ToInt32(match.Groups[9].Value, 16));

Amount = (Convert.ToInt64(match.Groups[5].Value, 16) + hexDecimal) * hexExponent;
}
else
{
long decimalExponent = 100000000;
if (match.Groups[4].Success)
decimalExponent = (long)Math.Pow(10, int.Parse(match.Groups[4].Value));
Amount = (long)(decimal.Parse(match.Groups[2].Value) * decimalExponent);
}
}

==Requirements==

===Payment identifiers, not person identifiers===
In my opinion, the most basic idea of the URI scheme (as this is a currency) is to facilitate payment. So the URIs should represent first and foremost payments. If it represents something else, this needs to be specified. Thus
<code>
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L
</code>
represents a '''request for payment''' to me using my bitcoin address, not my bitcoin address itself. So after parsing the URI (via link/qr/whatever) the application should open a transaction window with the address filled in. You then need to add an amount and confirm the payment.
If your application is smart, it will also have a button "just store the address". But the point I am trying to make is that the default use of the URI should be for payment, nor for exchanging addresses.

===Sending money===
To send a payment to someone else first construct a new keypair. You may want to use a [[mini private key format]], or you may also use a full private key for more security depending on the amount being sent and how long you expect to pass before a claim. Now create and publish a transaction with an output of the amount you wish to send. Use this script in that output:

<code>
<pubkey> OP_CHECKSIG
</code>

Construct an address from the public key. Encode the URI as below:

<code>
bitcoin:<address>?send=<base 58 encoded private key>
</code>

You may optionally include amount or message fields as well. In a wallet to claim money sent this way search for an incoming transaction with the output script form above, where <address> matches the public key in the script. When you find the transaction create a claim transaction with an input script of this form:

<code>
<sig>
</code>

This claims the money you were sent. Until your claim transaction has confirmed the sender may take their money back.

===Accessibility===
'''Imported from the forum:''' I like the simplicity of bitcoin:xxxxxxxxxxxxx and very much approve of its accessibility. Should someone from the outside happen to see such a URI, the protocol name already gives a description. A quick google search should then do the rest. x-btc sounds much more cryptic; the chance that someone googles that out of curiosity are much slimmer. Also, very likely, what s/he will find are mostly technical specifications. Not a good introduction to bitcoin.

For the same reason I am for using '&' as a delimiter for key-value pairs. People know it from URLs. Make it easy for people to understand what is going on.

===Keep it simple===
Don't explicitly write down information that can be inferred. Don't mark the address as an address. If there is no address, this does lose much of its utility. We could, however, specify 'address' as a reserved word, so that <code>
bitcoin:address?amount=50X8
</code>
would initiate a transaction with the amount filled in, but with a blank address. I am not convinced that there is a use case, though.

===Use-cases===
Before the URI scheme is finalised one should think long and hard about use cases. in what circumstances will which people use this, and for what?
* an online shop has a 'buy this' link, which uses the URI scheme.
**PROBLEM: click on the link opens the application; how does the merchant notice this?
***POSSIBLE SOLUTION: javascript can detect the click.
***POSSIBLE SOLUTION: the checkout site checks its bitcoin account for payment via HTTP request.
**PROBLEM: the time problem (~10 minutes) is very apparent here; nobody wants to wait 10 minutes for the transaction to be confirmed.
***For micropayment-style digital content (songs, for example) it's probably not necessary to wait for any confirmation at all, since there is low risk of a double-spend attack for payments of a small amount.
***For physical goods, the merchant can tell the client that their transaction is pending when it first notices the transaction, and that payment is complete when the number of confirmations is large enough.
* a person only has an online client, no actual application
**PROBLEM: how to redirect the URI so that the online client gets a notice?
***POSSIBLE SOLUTION: Small application and/or browser plugins to redirect the handler call to the designated online wallet.

===Backwards compatibility===
We want URIs generated in 2011 to still work in 2036. Think about extensibility. Of course we can make only educated guesses (and nothing more!) about the future, but don't act as if there is none. This should be the best we can do, but it should not be seen as set in stone. Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now. Version incompatibility is the easiest thing to drive users crazy: "I just upgraded to this shiny new version. What? It doesn't support the old format? AAAAAAARRRGH!"

==References==
<references/>

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

Fallback Nodes

2011-08-25T20:46:48Z

Cdhowie: /* IPv4 Nodes */ meh, connections keep filling up

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-08-25 20:01:25 || ?
|-
| 50.23.217.19 || Senseless || 50.23.217.19 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:03 || No
|-
| 66.158.72.2 || imsaguy || 66.158.72.2 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:03 || No
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:03 || Yes
|-
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:04 || ?
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:04 || ?
|-
| bitcoin.es || neutrino || 188.165.138.165 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:04 || ?
|-
| 216.135.68.67 || NothinG || 216.135.68.67 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 20:00:31 || ?
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-08-25 20:00:31 || ?

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|-
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No
|-
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Fallback Nodes

2011-08-25T18:05:09Z

Cdhowie: /* IPv4 Nodes */

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 50.23.217.19 || Senseless || 50.23.217.19 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:03 || No
|-
| 66.158.72.2 || imsaguy || 66.158.72.2 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:03 || No
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:03 || Yes
|-
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:04 || ?
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:04 || ?
|-
| bitcoin.es || neutrino || 188.165.138.165 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:04 || ?
|-
| 216.135.68.67 || NothinG || 216.135.68.67 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:04 || ?
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-08-25 18:01:04 || ?
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2011-08-25 17:00:52 || ?
|-
| zack.home.chrishowie.com || cdhowie || 98.222.154.109 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-25 18:01:04 || No

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|-
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No
|-
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Fallback Nodes

2011-08-24T20:25:26Z

Cdhowie: /* IPv4 Nodes */

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:
bitcoind -dns -addnode=bitcoin.es

Versions prior to 0.3.22 do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(dig +short bitcoin.es)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 50.23.217.19 || Senseless || 50.23.217.19 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:03 || No
|-
| 66.158.72.2 || imsaguy || 66.158.72.2 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:04 || No
|-
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:04 || Yes
|-
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:04 || ?
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:06 || ?
|-
| bitcoin.es || neutrino || 188.165.138.165 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:06 || ?
|-
| 216.135.68.67 || NothinG || 216.135.68.67 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:06 || ?
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-08-24 20:00:06 || ?
|-
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2011-08-24 17:01:32 || ?
|-
| zack.home.chrishowie.com || cdhowie || 98.222.154.109 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.24}} || 2011-08-24 20:00:06 || No

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|-
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No
|-
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Main Page

2011-05-26T14:55:12Z

Cdhowie: replace channel link with link to IRC channels

{| id="mp-topbanner" style="width:100%; background:#f6f6f6; margin-top:1.2em; border:1px solid #ddd;"
| style="width:61%; color:#000;" |

{| style="width:100%; border:none; background:none;"
| style="text-align:center; white-space:nowrap; color:#000;" |
<div style="font-size:162%; border:none; margin:0; padding:.1em; color:#000;">Welcome to [[Bitcoin]] wiki,</div>
<div style="top:+0.2em; font-size:95%;">All your bitcoin information needs.</div>
<div id="articlecount" style="width:100%; text-align:center; font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles.</div>
'''Improve [[:Category:Stubs|this wiki]] and [[Bitcoin:Contributors Award|earn bitcoins]].'''
|}

| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[http://bitcoin.org Frontpage]</span>
| style="width:13%; font-size:120%;" |
* <span class="plainlinks">[http://bitcoin.org/smf Forum]</span>
| style="width:13%; font-size:120%; padding-right: 40px;" |
* <span class="plainlinks">[[IRC channels|Chatrooms]]</span>
|}


{| id="mp-upper" style="width: 100%; margin:6px 0 0 0; background:none; border-spacing: 0px;"
| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f6e5f1; vertical-align:top; color:#000;" |
{| id="mp-left" style="vertical-align:top; background:#f6e5f1;"
! style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Bitcoin</h2>
|-
| style="color:#000;" | <div id="mp-tfa" style="padding:2px 5px">{{MainPage_Intro}}</div>
|-
! style="padding:2px" | <h2 id="mp-dyk-h2" style="margin:3px; background:#e9caef; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Why</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-dyk">{{MainPage_Reasons}}</div>
|}
| style="border:1px solid transparent;" |

| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f6e5f1; vertical-align:top;"|
{| id="mp-right" style="width:100%; vertical-align:top; background:#f6e5f1;"
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Topic central</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_Topics}}</div>
|-
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#efc1e2; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">FAQ</h2>
|-
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd">{{MainPage_FAQ}}</div>
|}
|}

== Other pages ==

* '''[http://www.mediawiki.org/wiki/Help:Formatting Help]''' - Documentation on wiki editing.
* '''[[Bitcoin.it Wiki|About]]''' - Information on this site.

[[fr:Accueil]]
[[zh-cn:首页]]
[[es:Página Principal]]
[[it:Pagina principale]]
[[ru:Заглавная страница]]
[[de:Hauptseite]]

__NOTOC____NOEDITSECTION__

Template:Freenode IRC

2011-05-26T14:05:04Z

Cdhowie:

<small>[irc://irc.freenode.net/{{{1}}} IRC] [http://webchat.freenode.net/?channels={{{1}}}&uio=d4 Web]</small> {{#if: {{{text|}}} | {{{text}}} | <nowiki>#</nowiki>{{{1}}}}}

IRC channels

2011-05-26T14:04:35Z

Cdhowie: Created page with "The following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]: {| class="wikitable" ! Channel !! Description |- | {{Freenode IRC|bitcoin}} || Ge..."

The following Bitcoin-related IRC channels are available on [http://www.freenode.net Freenode]:

{| class="wikitable"
! Channel !! Description
|-
| {{Freenode IRC|bitcoin}} || General Bitcoin-related discussion.
|-
| {{Freenode IRC|bitcoin-otc|text=[[bitcoin-otc|#bitcoin-otc]]}} || Over-the-counter marketplace. (Chat tends to get off-topic frequently.)
|-
| {{Freenode IRC|bitcoin-pit}} || Marketplace with low tolerance for off-topic chat.
|-
| {{Freenode IRC|bitcoin-market}} || Streaming market data, no chat.
|-
| {{Freenode IRC|bitcoin-watch}} || Another streaming market data channel.
|-
| {{Freenode IRC|bitcoin-dev}} || Bitcoin software development.
|-
| {{Freenode IRC|bitcoin-mining}} || Discussion and support related to mining.
|-
| {{Freenode IRC|bitcoin-politics}} || Discuss politics with other Bitcoin users.
|}

Template:Freenode IRC

2011-05-26T14:02:28Z

Cdhowie:

{{#if: {{{text|}}} | {{{text}}} | <nowiki>#</nowiki>{{{1}}}}} <small>[irc://irc.freenode.net/{{{1}}} IRC] [http://webchat.freenode.net/?channels={{{1}}}&uio=d4 Web]</small>

Template:Freenode IRC

2011-05-26T13:59:40Z

Cdhowie: Created page with "{{{text|{{{1}}}}}} <small>[irc://irc.freenode.net/{{{1}}} IRC] [http://webchat.freenode.net/?channels={{{1}}}&uio=d4 Web]</small>"

{{{text|{{{1}}}}}} <small>[irc://irc.freenode.net/{{{1}}} IRC] [http://webchat.freenode.net/?channels={{{1}}}&uio=d4 Web]</small>

Fallback Nodes

2011-05-10T19:09:17Z

Cdhowie: /* IPv4 Nodes */ remove one of my nodes due to RAM constraints; update the version number of another

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:08 || No
|-
| bitcoin.csy.ca || Martok || 128.189.187.27 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:09 || ?
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.74.69 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:10 || ?
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:10 || No
|-
| bluematt.me || BlueMatt || 62.155.236.249 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-05-03 12:29:00 || No
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || Yes
|-
| BiddingPond.com || BiddingPond || 184.106.111.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-17 12:00:10 || ?
|-
| zack.home.chrishowie.com || cdhowie || 98.222.140.181 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-17 12:00:11 || No
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-04-17 12:00:11 || ?
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-04-17 12:00:12 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:12 || No
|-
| bitlex.org || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-17 12:00:13 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-04-17 12:00:13 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-04-17 12:00:13 || ?
|-
| 67.176.86.181 || BobSGI || 67.176.86.181 ||
|-
| BTCSportsBet.com || Cusipzzz || 109.75.176.39 || {{Table Value Yes}}

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Bitcoin-mining-proxy

2011-05-06T01:05:17Z

Cdhowie: +license

A multi-pool, multi-worker proxy for Bitcoin miners, supporting long polling and pool failover.

This software allows multiple miners to be run against multiple pools with fail-over to other pools if something happens to a miner's preferred pool. It requires a web server supporting PHP, and a MySQL database.

The software is open source (AGPLv3) and was released on May 4, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=5506.msg106640#msg106640 Flexible mining proxy]</ref>.

==See Also==

* [[:Category:Miners|Miners]]
* [[:Category:Pool Operators|Pool Operators]]

==External Links==

* [http://github.com/cdhowie/Bitcoin-mining-proxy Bitcoin-mining-proxy] project on GitHub

==References==

<references />

[[Category:Mining]]

Bitcoin-mining-proxy

2011-05-06T01:02:52Z

Cdhowie: add requirements

A multi-pool, multi-worker proxy for Bitcoin miners, supporting long polling and pool failover.

This software allows multiple miners to be run against multiple pools with fail-over to other pools if something happens to a miner's preferred pool. It requires a web server supporting PHP, and a MySQL database.

The software is open source and was released on May 4, 2011<ref>[http://www.bitcoin.org/smf/index.php?topic=5506.msg106640#msg106640 Flexible mining proxy]</ref>.

==See Also==

* [[:Category:Miners|Miners]]
* [[:Category:Pool Operators|Pool Operators]]

==External Links==

* [http://github.com/cdhowie/Bitcoin-mining-proxy Bitcoin-mining-proxy] project on GitHub

==References==

<references />

[[Category:Mining]]

Fallback Nodes

2011-04-03T19:04:57Z

Cdhowie: i borked my DNS :(

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-03 19:00:04 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-03 19:00:04 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-03 19:00:04 || No
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.73.218 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-04-03 19:00:04 || ?
|-
| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:00:05 || ?
|-
| bitcoin.chrishowie.com || cdhowie || 68.169.45.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:00:13 || No
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:00:14 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:00:14 || Yes
|-
| 217.157.1.202 || kseistrup || 217.157.1.202 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:00:14 || ?
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-04-03 19:00:14 || ?
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-04-03 19:00:15 || No
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-04-03 19:00:15 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-03 19:00:15 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-03 19:00:15 || No
|-
| 173.224.125.222 || MagicalTux [US] || 173.224.125.222 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-03 19:00:15 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-03 19:00:16 || No
|-
| bitlex.co.cc || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-04-03 19:00:16 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-04-03 19:00:16 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-04-03 19:00:16 || ?
|-
| 84.114.155.197 || sniffy || 84.114.155.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2011-04-03 02:00:05 || Yes
|-
| zack.home.chrishowie.com || cdhowie || 98.222.140.181 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-04-03 19:03:00 || No

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Network

2011-03-21T18:17:49Z

Cdhowie: /* IRC */ moved linux alternate port info to the FAQ

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333, but there is currently no option to change this. IPv6 is currently not supported.

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is only sent in response to a ''getdata'' request.
* ''block'' - Send a block. This is only sent in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. Normally ''addr'' messages only contain one address, but in this initial exchange it contains many recent peers.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers only ask for or relay transactions if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by Satoshi), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are only needed by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has two methods of finding peers.

=== IRC ===

Bitcoin joins the #bitcoin channel on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

For hosts that cannot make outbound connections on port 6667, the lfnet servers are also [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|listening on port 7777]].

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with an address database already populated by a few addresses. If you are unable to connect to IRC and you've never connected to the network before, you will get an updated address database by connecting to one of these "seednodes".

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]

[[Category:Technical]]

Help:FAQ

2011-03-21T18:16:49Z

Cdhowie: /* Do I need to configure my firewall to run bitcoin? */ +alternate port

Here you will find answers to the most commonly asked questions.

== General ==
=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”)
A Bitcoin isn't actually a 'thing' you can point at. It is just a number associated with a [[Address|Bitcoin Address]]. See also an [[Introduction|easy intro]] to bitcoin.

=== How are new Bitcoins created? ===

[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[controlled inflation|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of coins will approach 21,000,000 BTC over time.

In addition, built into the network is a system that attempts to allocate new coins in blocks about every 10 minutes, on average, somewhere on the network. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody "discovering" one of these blocks is based on the computer they are using compared to all of the computers also generating blocks on the network.

=== What's the current total amount of Bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are Bitcoins? ===

Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises. For convenience, the program currently accepts only 2 decimal places as quantities smaller than 0.01 BTC are considered of trivial value and are usually used only to attack the network.

=== How does the halving work when the number gets really small? ===

The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created.

The calculation is done as a right bitwise shift of a 64-bit signed integer. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.

Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.

=== How long will it take to generate all the coins? ===
Z
The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999, assuming that people are still using Bitcoins at that time.

==Networking==
=== Do I need to configure my firewall to run bitcoin? ===

Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. Bitcoin will also try to connect to IRC (tcp port 6667) to meet other nodes to connect to.

If you want to restrict your firewall rules to a few ips and/or don't want to allow IRC connection, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]]. If your provider blocks the common IRC ports, note that lfnet also listens on port 7777. Connecting to this alternate port currently requires either recompiling Bitcoin, or changing routing rules. For example, on Linux you can evade a port 6667 block by doing something like this:

echo 173.246.103.92 irc.lfnet.org >> /etc/hosts
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works

==See Also==

* [[Man page]]

[[zh-cn:FAQ]]
[[fr:FAQ]]
{{fromold|bitcoins}}

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

Network

2011-03-21T18:13:11Z

Cdhowie: /* IRC */ add linux recipe for using alternate port

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333, but there is currently no option to change this. IPv6 is currently not supported.

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is only sent in response to a ''getdata'' request.
* ''block'' - Send a block. This is only sent in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. Normally ''addr'' messages only contain one address, but in this initial exchange it contains many recent peers.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers only ask for or relay transactions if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by Satoshi), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are only needed by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has two methods of finding peers.

=== IRC ===

Bitcoin joins the #bitcoin channel on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

For hosts that cannot make outbound connections on port 6667, the lfnet servers are also listening on port 7777. A recipe for making bitcoind on Linux use this port without recompiling would be something like this:

echo 173.246.103.92 irc.lfnet.org >> /etc/hosts
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with an address database already populated by a few addresses. If you are unable to connect to IRC and you've never connected to the network before, you will get an updated address database by connecting to one of these "seednodes".

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]

[[Category:Technical]]

Network

2011-03-21T18:10:31Z

Cdhowie: /* IRC */ add alternate port

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333, but there is currently no option to change this. IPv6 is currently not supported.

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is only sent in response to a ''getdata'' request.
* ''block'' - Send a block. This is only sent in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. Normally ''addr'' messages only contain one address, but in this initial exchange it contains many recent peers.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers only ask for or relay transactions if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by Satoshi), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are only needed by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has two methods of finding peers.

=== IRC ===

Bitcoin joins the #bitcoin channel on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

(For hosts that cannot make outbound connections on port 6667, the lfnet servers are also listening on port 7777.)

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with an address database already populated by a few addresses. If you are unable to connect to IRC and you've never connected to the network before, you will get an updated address database by connecting to one of these "seednodes".

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]

[[Category:Technical]]

Fallback Nodes

2011-03-21T02:55:34Z

Cdhowie: /* IPv4 Nodes */ add one more of my permanent nodes

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-21 02:00:06 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-21 02:00:07 || ?
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.73.218 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-21 02:00:10 || ?
|-
| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:10 || ?
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:10 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:11 || Yes
|-
| 217.157.1.202 || kseistrup || 217.157.1.202 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:11 || ?
|-
| lfmcal.dontexist.org || lfm || 75.158.131.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:11 || Yes
|-
| bitcoin.samara-lab.ru || m0Ray || 95.128.160.162 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:12 || ?
|-
| bitcoin-otc.com || nanotube || 69.163.132.101 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:12 || No
|-
| bitcoin.chrishowie.com || cdhowie || 68.169.45.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:55:00 || No
|-
| zack.home.chrishowie.com || cdhowie || 98.222.140.181 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-21 02:00:12 || No
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-03-21 02:00:20 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20}} || 2011-03-21 02:00:12 || No
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-21 02:00:12 || No
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-21 02:00:12 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-21 02:00:13 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-21 02:00:13 || No
|-
| 174.120.185.74 || MagicalTux [US] || 174.120.185.74 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-21 02:00:13 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-21 02:00:13 || No
|-
| bitlex.co.cc || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-21 02:00:14 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-03-21 02:00:15 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-03-21 02:00:15 || ?
|-
| 84.114.155.197 || sniffy || 84.114.155.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || 2011-03-20 23:00:08 || Yes

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

Fallback Nodes

2011-03-21T00:49:08Z

Cdhowie: hmm, i broke the bot? let's try this...

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:06 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:06 || ?
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.73.218 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:07 || ?
|-
| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || ?
|-
| 84.114.155.197 || sniffy || 84.114.155.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| 217.157.1.202 || kseistrup || 217.157.1.202 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || ?
|-
| lfmcal.dontexist.org || lfm || 75.158.131.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || Yes
|-
| bitcoin.samara-lab.ru || m0Ray || 95.128.160.162 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || ?
|-
| bitcoin-otc.com || nanotube || 69.163.132.101 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || No
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-03-20 23:00:10 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20}} || 2011-03-20 23:00:10 || No
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-20 23:00:10 || No
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-20 23:00:10 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 174.120.185.74 || MagicalTux [US] || 174.120.185.74 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| bitlex.co.cc || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:12 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-03-20 23:00:12 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-03-20 23:00:12 || ?
|-
| zack.home.chrishowie.com || cdhowie || 98.222.140.181 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[0.2]}} || 2011-03-21 00:49:00 || No

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.

User:Cdhowie

2011-03-21T00:05:20Z

Cdhowie: Created page with "Hello, I am [http://www.chrishowie.com/ Chris Howie]. I'm a relatively new Bitcoin user, but am already running a GPU miner and am working on a CPU miner library in C#. My expe..."

Hello, I am [http://www.chrishowie.com/ Chris Howie]. I'm a relatively new Bitcoin user, but am already running a GPU miner and am working on a CPU miner library in C#.

My experience on other wikis includes being [http://en.wikipedia.org/wiki/User:Crazycomputers a sysop on Wikipedia] and I hope I can be a useful contributor here as well.

It's probably a bit early for me to be asking for tips ;) but if -- once I make larger contributions to the wiki -- you want to send a few cents my way, you can tip at 1AhyvR5NANQD9wWSBZTQcUG5iY2G5ZD2iR.

Fallback Nodes

2011-03-20T23:26:54Z

Cdhowie: /* IPv4 Nodes */ add my permanent node

This is a list of nodes which are considered reliable. Nodes from this list which are down for more than 24 hours will be automatically removed and status of each node is displayed and updated every hour by [[User:WikiBot|WikiBot]].

== How to use this list ==

=== Connect to nodes ===

You can connect to these nodes with the ''-addnode=ip'' switch instead of the usual node harvesting process (through IRC or via the embedded nodelist). You can connect to more than one node by using ''-addnode=ip'' more than once. It is usually a good idea to connect to more than one of these nodes.

==== Nodes without a fixed ip ====

If the node IP is not fixed (see "Fixed" column), you will have to resolve the node's name (first column) each time the IP changes. Some nodes may have their ip change once a day, some others once a month, and some others may stay on the same IP for years. Still, as long as the IP is not fixed, there is no guarantee it will stay the same.

The [[Original Bitcoin client]] do not support hostnames to the ''-addnode'' parameter, so you must do the resolving part for it. For example on linux:
bitcoind -addnode=$(host theymos.ath.cx |sed s/"^.*has address "//)

=== IP Transactions ===

You can also send [[IP Transactions]] to these nodes. If you include your bitcoin address in the "message" field, you may have your coins back.

=== Tor network ===

To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:

mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Once you have configured and restarted tor, 192.0.2.2 will connect to ijzt2eeizty3p5xe.onion when accessed through the Tor proxy (and likewise for the other IPs/onions). You can then run Bitcoin with -addnode=192.0.2.2, or even send bitcoins to that IP address. You can use any arbitrary IP addresses with MapAddress, though some of the common non-routable ranges (10.*, 192.168.*) will not work due to a Bitcoin bug. 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.

== Nodes list ==

=== IPv4 Nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-

| 69.164.218.197 || Gavin Andresen || 69.164.218.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:06 || ?
|-
| jun.dashjr.org || Lightfoot Hosting || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:06 || ?
|-
| nat.router.dashjr.org || Luke-Jr || 71.1.73.218 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.21}} || 2011-03-20 23:00:07 || ?
|-
| ndrix.com || mndrix || 64.22.103.150 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || ?
|-
| 84.114.155.197 || sniffy || 84.114.155.197 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| btc1.justmoon.net || justmoon || 109.75.176.226 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| bitcoins.ca || humble || 142.58.248.28 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:08 || Yes
|-
| 217.157.1.202 || kseistrup || 217.157.1.202 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || ?
|-
| lfmcal.dontexist.org || lfm || 75.158.131.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || Yes
|-
| bitcoin.samara-lab.ru || m0Ray || 95.128.160.162 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || ?
|-
| bitcoin-otc.com || nanotube || 69.163.132.101 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.20[.2]}} || 2011-03-20 23:00:09 || No
|-
| 178.63.15.200 || hendi || 178.63.15.200 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20[.1]}} || 2011-03-20 23:00:10 || ?
|-
| mining.bitcoin.cz || slush || 178.79.147.99 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.20}} || 2011-03-20 23:00:10 || No
|-
| bitcoin.sipa.be || sipa || 178.18.90.41 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-20 23:00:10 || No
|-
| theymos.ath.cx || theymos || 99.27.237.13 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.3.19[.2]}} || 2011-03-20 23:00:10 || Yes
|-
| fallback1.bitcoin.me.uk || Vladimir || 91.85.220.84 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 109.75.176.193 || MagicalTux [DE] || 109.75.176.193 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 174.120.185.74 || MagicalTux [US] || 174.120.185.74 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| 178.63.62.15 || MagicalTux [DE] || 178.63.62.15 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:11 || No
|-
| bitlex.co.cc || BitLex || 78.34.69.123 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.3.19}} || 2011-03-20 23:00:12 || Yes
|-
| 74.82.216.10 || thufir || 74.82.216.10 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.10}} || 2011-03-20 23:00:12 || Yes
|-
| 74.57.236.239 || ? || 74.57.236.239 || {{Table Value Yes}} || {{Fallback Nodes/Node Old|version=0.3.0}} || 2011-03-20 23:00:12 || ?
|-
| zack.home.chrishowie.com || cdhowie

|}

=== Tor nodes ===

{|class="wikitable sortable"
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions
|-
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes
|-
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes
|-
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes
|-
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes
|-
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes
|-
| rnam4cxam62nkcyf.onion || BitLex || ? || 2011-02-11 || Yes
|-
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?
|-
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?
|-
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?
|-
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?
|-
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?
|-
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No
|}

== Adding a node ==

Before adding yourself as a fallback node, you should be sure your node will stay online for a long time. If a node is offline for more than 24 hours it will be removed from the list. To accept IP transactions you will have to add the ''-allowreceivebyip'' flag to your command line parameters.

To add a node in this list, you just need the ip/hostname and your name, the other fields will be filled automatically. Insert the following lines before the <tt>END NODELIST</tt> line:

<nowiki>|-
| ip || your name</nowiki>

Please note that a bot will connect to your node every hour to check its status and version.