https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Redemerald&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T13:08:27ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=34894Fallback Nodes2013-01-11T06:35:21Z<p>Redemerald: /* Tor network */</p>
<hr />
<div>This is a list of nodes which are considered reliable. <del>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]] </del>.<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
Starting with Bitcoin 0.7, there are useful [https://raw.github.com/bitcoin/bitcoin/master/doc/Tor.txt docs] for running clients and hidden services within Tor.<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), with versions of Bitcoin <0.7 you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion<br />
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."<br />
<br />
== Nodes list ==<br />
<br />
=== IPv6 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== IPv4 Nodes ===<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || <br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} <br />
|-<br />
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} <br />
|-<br />
| coin.soul-dev.com || Soul-Dev<br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No<br />
|-<br />
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No<br />
|-<br />
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| yyl3ipdmyjkfypmx.onion || redemerald || up || 2013-01-04 || Yes<br />
|-<br />
| x3danbeag2kyx644.onion || redemerald || up || 2013-01-04 || Yes<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No<br />
|-<br />
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?<br />
|-<br />
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?<br />
|-<br />
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]<br />
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=34612Fallback Nodes2013-01-05T07:37:08Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>This is a list of nodes which are considered reliable. <del>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]] </del>.<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion<br />
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."<br />
<br />
Additional suggested settings for hidden node operators:<br />
<br />
noirc=1<br />
upnp=0<br />
listen=1<br />
<br />
== Nodes list ==<br />
<br />
=== IPv6 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== IPv4 Nodes ===<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || <br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} <br />
|-<br />
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} <br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No<br />
|-<br />
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No<br />
|-<br />
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| yyl3ipdmyjkfypmx.onion || redemerald || up || 2013-01-04 || Yes<br />
|-<br />
| x3danbeag2kyx644.onion || redemerald || up || 2013-01-04 || Yes<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No<br />
|-<br />
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?<br />
|-<br />
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?<br />
|-<br />
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]<br />
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=34611Fallback Nodes2013-01-05T07:31:45Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>This is a list of nodes which are considered reliable. <del>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]] </del>.<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion<br />
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."<br />
<br />
Additional suggested settings for hidden node operators:<br />
<br />
noirc=1<br />
upnp=0<br />
listen=1<br />
<br />
== Nodes list ==<br />
<br />
=== IPv6 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== IPv4 Nodes ===<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || <br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} <br />
|-<br />
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} <br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No<br />
|-<br />
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No<br />
|-<br />
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| yyl3ipdmyjkfypmx.onion || redemerald || up || 2013-01-04 || Yes<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No<br />
|-<br />
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?<br />
|-<br />
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?<br />
|-<br />
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]<br />
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=34610Fallback Nodes2013-01-05T07:31:16Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>This is a list of nodes which are considered reliable. <del>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]] </del>.<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion<br />
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."<br />
<br />
Additional suggested settings for hidden node operators:<br />
<br />
noirc=1<br />
upnp=0<br />
listen=1<br />
<br />
== Nodes list ==<br />
<br />
=== IPv6 Nodes ===<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 2001:470:8:2e1::40 || ? || 2001:470:8:2e1::40 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== IPv4 Nodes ===<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| archivum.info || Ferraro Ltd.|| 88.198.58.172 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| 62.75.216.13 || exMULTI, Inc. || 62.75.216.13 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 69.64.34.118 || exMULTI, Inc. || 69.64.34.118 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btc.turboadmin.com || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| fallback.bitcoin.zhoutong.com || Zhou Tong || 117.121.241.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || No<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| jun.dashjr.org || Luke-Jr || 173.242.112.53 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || <br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| porgressbar.sk || progressbar hackerspace || 91.210.181.21 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| faucet.bitcoin.st || bitcoin street || 64.27.57.225 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| bitcoin.securepayment.cc || SecurePayment CC || 63.247.147.163 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| x.jine.se || jine || 213.112.48.166 || {{Table Value Yes}} || {{Fallback Nodes/Node Up}} || || Yes<br />
|-<br />
| www.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.181 || {{Table Value Yes}} <br />
|-<br />
| ns2.dcscdn.com || [[User:Danw12|Danw12]] || 199.115.228.182 || {{Table Value Yes}} <br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| 6hgmaxwellgpv2oe.onion|| Gmaxwell || up || 2012-07-01 || No<br />
|-<br />
| pqosrh6wfaucet32.onion|| bitcoin street || up || 2012-08-29 || No<br />
|-<br />
| btc4ulpftizx5b72.onion || TorNode || up || 2012-06-22 || Yes<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-06-23 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-06-23 || No<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-09-16 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| yyl3ipdmyjkfypmx.onion || redemerald || up || 2013-01-04 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-06-23 || No<br />
|-<br />
| mutqcuh7hwxmhx3k.onion || Xirafe || up || 2012-06-23 || ?<br />
|-<br />
| r4de4zf4lyniu4mx.onion:8444 || ? || up || 2012-06-26 || ?<br />
|-<br />
| bitcoinprwwpuinm.onion:8333 || ? || up || 2012-06-26 || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]<br />
* [http://nodes.bitcoin.st Fallback Nodes] List of longest running Bitcoin Nodes listed by Country.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Help:FAQ&diff=33351Help:FAQ2012-12-06T02:58:56Z<p>Redemerald: /* How can I get bitcoins? */</p>
<hr />
<div>Here you will find answers to the most commonly asked questions.<br />
<br />
== General ==<br />
=== What are bitcoins? ===<br />
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”).<br />
There are such things as [[physical bitcoins]], but ultimately, a bitcoin is just a number associated with a [[Address|Bitcoin Address]]. A physical bitcoin is simply an object, such as a coin, with the number carefully embedded inside. See also an [[Introduction|easy intro]] to bitcoin.<br />
<br />
=== How can I get bitcoins? ===<br />
<br />
There are a variety of ways to acquire bitcoins:<br />
<br />
* Accept bitcoins as payment for goods or services.<br />
* There are several services where you can [[buying bitcoins|trade them]] for traditional currency.<br />
* Find someone to trade cash for bitcoins in-person through a [https://en.bitcoin.it/wiki/Category:Directories local directory].<br />
* Participate in a [[Pooled mining|mining pool]].<br />
* If you have a lot of mining hardware, you can solo mine and attempt to create a new [[block]] (currently yields 25 bitcoins plus transaction fees).<br />
<br />
===Does Bitcoin guarantee an influx of free money?===<br />
<br />
Since Bitcoin is a new technology, what it is and how it works may be initially unclear. Bitcoin is sometimes presented as being one of three things:<br />
<ol style="list-style-type: upper-alpha;"><br />
<li>Some sort of online 'get-rich-quick' scam.</li><br />
<li>A loophole in the market economy, the installation of which guarantees a steady influx of cash.</li><br />
<li>A sure investment that will almost certainly yield a profit.</li><br />
</ol><br />
In fact, none of the above are true. Let's look at them independently.<br />
<br />
;Is Bitcoin a 'get-rich-quick' scheme?<br />
:If you've spent much time on the Internet, you've probably seen ads for many 'get-rich-quick' schemes. These ads usually promise huge profits for a small amounts of easy work. Such schemes are usually pyramid/matrix-style schemes that make money from their own employees and offer nothing of any real value. Most convince one to buy packages that will make them earn hundreds a day, which in fact have the buyer distribute more such ads, and make minute profits.<br />
<br />
:Bitcoin is in no way similar to these schemes. Bitcoin doesn't promise windfall profits. There is no way for the developers to make money from your involvement or to take money from you. That bitcoins are nearly impossible to acquire without the owner's consent represents one of its greatest strengths. Bitcoin is an experimental, virtual currency that may succeed or may fail. None of its developers expect to get rich off of it. <br />
<br />
:A more detailed answer to this question can be found [http://bitcointalk.org/?topic=7815.0 here].<br />
<br />
;Will I make money by installing the client?<br />
:Most people who use Bitcoin don't earn anything by doing so, and the default client has no built-in way to earn Bitcoins. A small minority of people with dedicated, high-performance hardware do earn some Bitcoins by "''mining''" (generating new bitcoins, see [[#What is mining?|What is mining?]]) with special software, but joining Bitcoin shouldn't be construed as being the road to riches. Most Bitcoin users get involved because they find the project conceptually interesting and don't earn anything by doing so. This is also why you won't find much speculation about the political or economic repercussions of Bitcoin anywhere on this site: Bitcoin developers owe their dedication to the project's intellectual yieldings more than to those of a monetary nature. Bitcoin is still taking its first baby steps; it may go on to do great things but right now it only has something to offer those chasing conceptually interesting projects or bleeding edge technology.<br />
<br />
;As an investment, is Bitcoin a sure thing?<br />
:Bitcoin is a new and interesting electronic currency, the value of which is not backed by any single government or organization. Like other currencies, it is worth something partly because people are willing to trade it for goods and services. Its exchange rate fluctuates continuously, and sometimes wildly. It lacks wide acceptance and is vulnerable to manipulation by parties with modest funding. Security incidents such as website and account compromise may trigger major sell-offs. Other fluctuations can build into positive feedback loops cause much larger exchange rate fluctuations. Anyone who puts money into Bitcoin should take measures to reduce their risk and consider it as a high-risk currency. Later, as Bitcoin becomes better known and more widely accepted, it should stabilize, but for the time being it is unpredictable. Any investment in Bitcoin should be done carefully and with a clear plan to manage risk.<br />
<br />
=== Can I buy bitcoins with Paypal? ===<br />
<br />
It is possible to buy [[physical bitcoins]] with PayPal but it is otherwise difficult and/or expensive to do so, because of significant risk to the seller. <br />
<br />
While it is possible to find an individual who wishes to sell Bitcoin to you via Paypal, (perhaps via [http://www.bitcoin-otc.com/ #bitcoin-otc] ) most exchanges do not allow funding through PayPal. This is due to repeated cases where someone pays for bitcoins with Paypal receives their bitcoins, and then fraudulently complains to Paypal that they never received their purchase. PayPal often sides with the fraudulent buyer in this case which means any seller would need to cover that risk with higher fees or refuse to accept PayPal altogether.<br />
<br />
Buying Bitcoins from individuals with this method is still possible, but requires the seller to have some trust that the buyer will not file a claim with PayPal to reverse the payment.<br />
<br />
=== Where can I find a forum to discuss Bitcoin? ===<br />
<br />
Please visit the [[Bitcoin:Community_portal#Bitcoin_Community_Forums_on_various_platforms|Community Portal]] for links to Bitcoin-related forums.<br />
<br />
=== How are new bitcoins created? ===<br />
<br />
[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]<br />
New bitcoins are generated by the network through the process of "[[#What is mining?|''mining'']]". In a process that is similar to a continuous lottery, mining nodes on the network are awarded bitcoins each time they find the solution to a certain mathematical problem (and thereby create a new [[block]]). Creating a block is a [[proof of work]] with a difficulty that varies with the overall strength of the network. The reward for solving a block is [[Controlled Currency Supply|automatically adjusted]] so that in roughly the first four years of operation of the Bitcoin network, {{formatnum:10500000}} BTC will be created. This amount is halved each four years, so it will be {{formatnum:5250000}} over years 4-8, {{formatnum:2625000}} over years 8-12, and so on. Thus the total number of bitcoins in existence will not exceed {{formatnum:21000000}}. See [[Controlled Currency Supply]].<br />
<br />
Blocks are [[Mining|mined]] every 10 minutes, on average and for the first four years ({{formatnum:210000}} blocks) each block includes 50 new bitcoins. As the amount of processing power directed at mining changes, the difficulty of creating new bitcoins changes. This difficulty factor is calculated every 2016 blocks and is based upon the time taken to generate the previous 2016 blocks. See [[Mining]].<br />
<br />
=== What's the current total number of bitcoins in existence? ===<br />
<br />
[http://blockexplorer.com/q/totalbc Current count]. Also see [https://blockchain.info/charts/total-bitcoins Total bitcoins in circulation chart]<br />
<br />
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 {{formatnum:210000}} blocks, 25 BTC for the next {{formatnum:210000}} blocks, then 12.5 BTC, 6.25 BTC and so on.<br />
<br />
=== How divisible are bitcoins? ===<br />
<br />
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction. If necessary, the protocol and related software can be modified to handle even smaller amounts.<br />
<br />
=== What do I call the various denominations of bitcoins? ===<br />
<br />
There is a lot of discussion about the naming of these fractions of bitcoins. The leading candidates are:<br />
<br />
* 1 BTC = 1 bitcoin<br />
* 0.01 BTC = 1 cBTC = 1 centibitcoin (also referred to as bitcent)<br />
* 0.001 BTC = 1 mBTC = 1 millibitcoin (also referred to as mbit (pronounced em-bit) or millibit or even bitmill)<br />
* 0.000 001 BTC = 1 μBTC = 1 microbitcoin (also referred to as ubit (pronounced yu-bit) or microbit)<br />
<br />
The above follows the accepted international SI prefixes for hundredths, thousandths, and millionths. There are many arguments against the special case of 0.01 BTC since it is unlikely to represent anything meaningful as the Bitcoin economy grows (it certainly won't be the equivalent of 0.01 USD, GBP or EUR). Equally, the inclusion of existing national currency denominations such as "cent", "nickel", "dime", "pence", "pound", "kopek" and so on are to be discouraged; this is a worldwide currency.<br />
<br />
One exception is the "satoshi" which is smallest denomination currently possible <br />
<br />
* 0.000 000 01 BTC = 1 satoshi (pronounced sa-toh-shee)<br />
which is so named in honour of Satoshi Nakamoto, the pseudonym of the inventor of Bitcoin.<br />
<br />
For an overview of all defined units of Bitcoin (including less common and niche units), see [[Units]].<br />
<br />
Further discussion on this topic can be found on the forums here:<br />
<br />
* [http://forum.bitcoin.org/index.php?topic=14438.msg195287#msg195287 We need names]<br />
* [http://forum.bitcoin.org/index.php?topic=8282.0 What to call 0.001 BTC]<br />
<br />
=== How does the halving work when the number gets really small? ===<br />
<br />
Eventually the reward will go from 0.00000001 BTC to zero and no more bitcoins will be created. <br />
<br />
The block reward calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by two and rounded down. The integer is equal to the value in BTC * 100,000,000 since internally in the reference client software, all Bitcoin balances and values are stored as unsigned integers.<br />
<br />
With an initial block reward of 50 BTC, it will take many 4-year periods for the block reward to reach zero.<br />
<br />
=== How long will it take to generate all the coins? ===<br />
<br />
The last block that will generate coins will be block #6,929,999 which should be generated at or near the year 2140. The total number of coins in circulation will then remain static at 20,999,999.9769 BTC.<br />
<br />
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 20,999,999.999999999496 BTC.<br />
<br />
=== If no more coins are going to be generated, will more blocks be created? ===<br />
<br />
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, these fees will sustain the ability to use bitcoins and the Bitcoin network. There is no practical limit on the number of blocks that will be mined in the future.<br />
<br />
=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===<br />
<br />
Because of the law of supply and demand, when fewer bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So, as Bitcoins are lost, the remaining bitcoins will eventually increase in value to compensate. As the value of a bitcoin increases, the number of bitcoins required to purchase an item '''de'''creases. This is a [[Deflationary spiral|deflationary economic model]]. As the average transaction size reduces, transactions will probably be denominated in sub-units of a bitcoin such as millibitcoins ("Millies") or microbitcoins ("Mikes").<br />
<br />
The Bitcoin protocol uses a base unit of one hundred-millionth of a Bitcoin ("a Satoshi"), but unused bits are available in the protocol fields that could be used to denote even smaller subdivisions.<br />
<br />
=== If every transaction is broadcast via the network, does Bitcoin scale? ===<br />
The Bitcoin protocol allows lightweight clients that can use Bitcoin without downloading the entire transaction history. As traffic grows and this becomes more critical, implementations of the concept will be developed. Full network nodes will at some point become a more specialized service.<br />
<br />
With some modifications to the software, full Bitcoin nodes could easily keep up with both VISA and MasterCard combined, using only fairly modest hardware (a single high end server by todays standards). It is worth noting that the MasterCard network is structured somewhat like Bitcoin itself - as a peer to peer broadcast network.<br />
<br />
Learn more about [[Scalability]].<br />
<br />
==Economy==<br />
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===<br />
Bitcoins have value because they are useful and because they are [[Controlled Currency Supply|scarce]]. As they are accepted by more merchants, their value will [http://en.wikipedia.org/wiki/Sticky_%28economics%29 stabilize]. See the [[Trade|list of Bitcoin-accepting sites]].<br />
<br />
When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. Bitcoins, like dollars and euros, are not backed up by anything except the variety of merchants that accept them.<br />
<br />
It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.<br />
<br />
Alternatively it needs to be added that while the law of supply and demand applies it does not guarantee value of Bitcoins in the future. If confidence in Bitcoins is lost then it will not matter that the supply can no longer be increased, the demand will fall off with all holders trying to get rid of their coins. An example of this can be seen in cases of state currencies, in cases when the state in question dissolves and so no new supply of the currency is available (the central authority managing the supply is gone), however the demand for the currency falls sharply because confidence in its purchasing power disappears. Of-course Bitcoins do not have such central authority managing the supply of the coins, but it does not prevent confidence from eroding due to other situations that are not necessarily predictable.<br />
<br />
=== Is Bitcoin a bubble? ===<br />
Yes, in the same way as the euro and dollar are. They only have value in exchange and have no inherent value. If everyone suddenly stopped accepting your dollars, euros or bitcoins, the "bubble" would burst and their value would drop to zero. But that is unlikely to happen: even in Somalia, where the government collapsed 20 years ago, [http://en.wikipedia.org/wiki/Somali_shilling Somali shillings] are still accepted as payment.<br />
<br />
=== Is Bitcoin a Ponzi scheme? ===<br />
In a Ponzi Scheme, the founders persuade investors that they’ll profit. Bitcoin does not make such a guarantee. There is no central entity, just individuals building an economy.<br />
<br />
A ponzi scheme is a zero sum game. Early adopters can only profit at the expense of late adopters. Bitcoin has possible win-win outcomes. Early adopters profit from the rise in value. Late adopters, and indeed, society as a whole, benefit from the usefulness of a stable, fast, inexpensive, and widely accepted p2p currency.<br />
<br />
The fact that early adopters benefit more doesn't alone make anything a Ponzi scheme. All good investments in successful companies have this quality.<br />
<br />
=== Doesn't Bitcoin unfairly benefit early adopters? ===<br />
Early adopters have a large number of bitcoins now because they took a risk and invested resources in an unproven technology. By so doing, they have helped Bitcoin become what it is now and what it will be in the future (hopefully, a ubiquitous decentralized digital currency). It is only fair they will reap the benefits of their successful investment.<br />
<br />
In any case, any bitcoin generated will probably change hands dozens of time as a medium of exchange, so the profit made from the initial distribution will be insignificant compared to the total commerce enabled by Bitcoin.<br />
<br />
Since the pricing of Bitcoins has fallen greatly from its June 2011 peak, prices today are much more similar to those enjoyed by many early adopters. Those who are buying Bitcoins today likely believe that Bitcoin will grow significantly in the future. Setting aside the brief opportunity to have sold Bitcoins at the June 2011 peak enjoyed by few, the early-adopter window is arguably still open.<br />
<br />
===Won't loss of wallets and the finite amount of Bitcoins create excessive deflation, destroying Bitcoin? ===<br />
Worries about Bitcoin being destroyed by deflation are not entirely unfounded. Unlike most currencies, which experience inflation as their founding institutions create more and more units, Bitcoin will likely experience gradual deflation with the passage of time. Bitcoin is unique in that only a small amount of units will ever be produced (twenty-one million to be exact), this number has been known since the project's inception, and the units are created at a predicable rate.<br />
<br />
Also, Bitcoin users are faced with a danger that doesn't threaten users of any other currency: if a Bitcoin user loses his wallet, his money is gone forever, unless he finds it again. And not just to him; it's gone completely out of circulation, rendered utterly inaccessible to anyone. As people will lose their wallets, the total number of Bitcoins will slowly decrease.<br />
<br />
Therefore, Bitcoin seems to be faced with a unique problem. Whereas most currencies inflate over time, Bitcoin will mostly likely do the just the opposite. Time will see the irretrievable loss of an ever-increasing number of Bitcoins. An already small number will be permanently whittled down further and further. And as there become fewer and fewer Bitcoins, the laws of supply and demand suggest that their value will probably continually rise.<br />
<br />
Thus Bitcoin is bound to once again stray into mysterious territory, because no one exactly knows what happens to a currency that grows continually more valuable. Economists generally agree that a low level of inflation is a good thing for a currency, but nobody is quite sure about what might happens to one that continually deflates. Although deflation could hardly be called a rare phenomenon, steady, constant deflation is unheard of. There may be a lot of speculation, no one has any hard data to back up their claims.<br />
<br />
That being said, there is a mechanism in place to combat the obvious consequences. Extreme deflation would render most currencies highly impractical: if a single Canadian dollar could suddenly buy the holder a car, how would one go about buying bread or candy? Even pennies would fetch more than a person could carry. Bitcoin, however, offers a simple and stylish solution: infinite divisibility. Bitcoins can be divided up and trade into as small of pieces as one wants, so no matter how valuable Bitcoins become, one can trade them in practical quantities. <br />
<br />
In fact, infinite divisibility should allow Bitcoins to function in cases of extreme wallet loss. Even if, in the far future, so many people have lost their wallets that only a single Bitcoin, or a fraction of one, remains, Bitcoin should continue to function just fine. No one can claim to be sure what is going to happen, but deflation may prove to present a smaller threat than many expect.<br />
<br />
For more information, see the [[Deflationary spiral]] page.<br />
<br />
=== What if someone bought up all the existing Bitcoins? ===<br />
Bitcoin markets are competitive -- meaning the price of a bitcoin will rise or fall depending on supply and demand at certain price levels. Only a fraction of bitcoins issued to date are found on the exchange markets for sale. So even though technically a buyer with lots of money could buy all the bitcoins offered for sale, unless those holding the rest of the bitcoins offer them for sale as well, even the wealthiest, most determined buyer can't get at them.<br />
<br />
Additionally, new currency continues to be issued daily and will continue to do so for decades though over time the rate at which they are issued declines to insignificant levels. Those who are mining aren't obligated to sell their bitcoins so not all bitcoins will make it to the markets even.<br />
<br />
This situation doesn't suggest, however, that the markets aren't vulnerable to price manipulation. It doesn't take significant amounts of money to move the market price up or down and thus Bitcoin remains a volatile asset.<br />
<br />
===What if someone creates a new block chain, or a new digital currency that renders Bitcoin obsolete?===<br />
<br />
That the block chain cannot be easily forked represents one of the central security mechanisms of Bitcoin. Given the choice between two block chains, a Bitcoin miner always chooses the longer one - that is to say, the one with the more complex hash. Thusly, it ensures that each user can only spend their bitcoins once, and that no user gets ripped off.<br />
<br />
As a consequence of the block chain structure, there may at any time be many different sub-branches, and the possibility always exists of a transaction being over-written by the longest branch, if it has been recorded in a shorter one. The older a transaction is though, the lower its chances of being over-written, and the higher of becoming permanent. Although the block chain prevents one from spending more Bitcoins than one has, it means that transactions can be accidentally nullified. <br />
<br />
A new block chain would leave the network vulnerable to [[double-spending|double-spend]] attacks. However, the creation of a viable new chain presents considerable difficulty, and the possibility does not present much of a risk.<br />
<br />
Bitcoin will always choose the longer Block Chain and determines the relative length of two branches by the complexities of their hashes. Since the hash of each new block is made from that of the block preceding it, to create a block with a more complex hash, one must be prepared to do more computation than has been done by the entire Bitcoin network from the fork point up to the newest of the blocks one is trying to supersede. Needless to say, such an undertaking would require a very large amount of processing power and since Bitcoin is continually growing and expanding, it will likely only require more with the passage of time.<br />
<br />
A much more distinct and real threat to the Bitcoin use is the development of other, superior virtual currencies, which could supplant Bitcoin and render it obsolete and valueless.<br />
<br />
A great deal of careful thought and ingenuity has gone into the development of Bitcoin, but it is the first of its breed, a prototype, and vulnerable to more highly-evolved competitors. At present, any threatening rivals have yet to rear its head; Bitcoin remains the first and foremost private virtual currency, but we can offer no guarantees that it will retain that position. It would certainly be in keeping with internet history for similar system built from the same principles to supersede and cast Bitcoin into obsolescence, after time had revealed its major shortcomings. Friendster and Myspace suffered similar fates at the hand of Facebook, Napster was ousted by Limeware, Bearshare and torrent applications, and Skype has all but crushed the last few disciples of the Microsoft Messenger army. <br />
<br />
This may sound rather foreboding, so bear in mind that introduction of new and possibly better virtual currencies will not necessarily herald Bitcoin's demise. If Bitcoin establishes itself sufficiently firmly before the inception of the next generation of private, online currencies as to gain widespread acceptance and general stability, future currencies may pose little threat even if they can claim superior design.<br />
<br />
==Sending and Receiving Payments==<br />
<br />
=== Why do I have to wait 10 minutes before I can spend money I received? ===<br />
<br />
10 minutes is the average time taken to find a block. It can be significantly more or less time than that depending on luck; 10 minutes is simply the average case. <br />
<br />
You can see how long all other recent transactions have taken here: [http://bitcoinstats.org/ BitcoinStats.org]. <br />
<br />
[[Blocks]] (shown as "confirmations" in the GUI) are how the Bitcoin achieves consensus on who owns what. Once a block is found everyone agrees that you now own those coins, so you can spend them again. Until then it's possible that some network nodes believe otherwise, if somebody is attempting to defraud the system by reversing a transaction. The more confirmations a transaction has, the less risk there is of a reversal. Only 6 blocks or 1 hour is enough to make reversal computationally impractical. This is dramatically better than credit cards which can see chargebacks occur up to three months after the original transaction!<br />
<br />
Ten minutes was specifically chosen by [[Satoshi]] as a tradeoff between propagation time of new blocks in large networks and the amount of work wasted due to chain splits. For a more technical explanation, see Satoshi's [http://www.bitcoin.org/bitcoin.pdf original technical paper].<br />
<br />
[[File:TransactionConfirmationTimesExample.PNG]]<br />
<br />
=== Do you have to wait until my transactions are confirmed in order to buy or sell things with Bitcoin? ===<br />
<br />
YES, you do, IF the transaction is non-recourse. The Bitcoin reference software does not display transactions as confirmed until six blocks have passed (confirmations). As transactions are burred in the chain they become increasingly non-reversible but are very reversible before the first confirmation. Two to six confirmations are recommended for non-recourse situations depending on the value of the transactions involved.<br />
<br />
When people ask this question they are usually thinking about applications like supermarkets. This generally is a recourse situation: if somebody tries to double-spend on a face-to-face transaction it might work a few times, but probabalistically speaking eventually one of the double-spends will get noticed, and the penalty for shoplifting charges in most localities is calibrated to be several times worse than the proceeds of a single shoplifting event.<br />
<br />
Double-spends might be a concern for something like a snack machine in a low-traffic area with no nearby security cameras. Such a machine shouldn't honor 0-confirmation payments, and should instead use some other mechanism of clearing Bitcoin or validating transactions against reversal, see the wiki article [[Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation|here]] for alternatives.<br />
<br />
Applications that require immediate payment processing, like supermarkets or snack machines, need to manage the risks. Here is one way to reverse an unconfirmed payment:<br />
<br />
A [[Double-spending#Finney_attack|Finney attack]], in which an attacker mines a block containing a movement of some coins back to themselves. Once they find a block solution, they quickly go to a merchant and make a purchase, then broadcast the block, thus taking back the coins. This attack is a risk primarily for goods that are dispatched immediately, like song downloads or currency trades. Because the attacker can't choose the time of the attack, it isn't a risk for merchants such as supermarkets where you can't choose exactly when to pay (due to queues, etc). The attack can fail if somebody else finds a block containing the purchasing transaction before you release your own block, therefore, merchants can reduce but not eliminate the risk by making purchasers wait some length of time that's less than a confirm.<br />
<br />
Because pulling off this attack is not trivial, merchants who need to sell things automatically and instantly are most likely to just price the cost of reversal fraud in, or use insurance.<br />
<br />
=== I was sent some bitcoins and they haven't arrived yet! Where are they? ===<br />
<br />
Don't panic! There are a number of reasons why your bitcoins might not show up yet, and a number of ways to diagnose them. <br />
<br />
The latest version of the Bitcoin-Qt client tells you how far it has yet to go in downloading the blockchain. Hover over the icon in the bottom right corner of the client to learn your client's status.<br />
<br />
If it has not caught up then it's possible that your transaction hasn't been included in a block yet. <br />
<br />
You can check pending transactions in the network by going [http://blockchain.info here] and then searching for your address. If the transaction is listed here then it's a matter of waiting until it gets included in a block before it will show in your client. <br />
<br />
If the transaction is based on a coin that was in a recent transaction then it could be considered a low priority transaction. Transfers can take longer if the transaction fee paid was not high enough. If there is no fee at all the transfer can get a very low priority and take hours or even days to be included in a block.<br />
<br />
=== Why does my Bitcoin address keep changing? ===<br />
<br />
Whenever the address listed in "Your address" receives a transaction, Bitcoin replaces it with a new address. This is meant to encourage you to use a new address for every transaction, which enhances [[anonymity]]. All of your old addresses are still usable: you can see them in ''Settings -> Your Receiving Addresses''.<br />
<br />
===How much will the transaction fee be?===<br />
<br />
Some transactions might require a [[transaction fee]] for them to get confirmed in a timely manner. The transaction fee is processed by and received by the bitcoin miner. The most recent version of the Bitcoin client will estimate an appropriate fee when a fee might be required.<br />
<br />
The fee is added to the payment amount. For example, if you are sending a 1.234 BTC payment and the client requires a 0.0005 BTC fee, then 1.2345 BTC will be subtracted from the wallet balance for the entire transaction and the address for where the payment was sent will receive a payment of 1.234 BTC.<br />
<br />
A fee might be imposed because your transaction looks like a denial of service attack to the Bitcoin system. For example, it might be burdensome to transmit or it might recycle Bitcoins you recently received. The wallet software attempts to avoid generating burdensome transactions, but it isn't always able to do so: The funds in your wallet might be new or composed of many tiny payments. <br />
<br />
Because the fee is related to the amount of data that makes up the transaction and not to the amount of Bitcoins being sent, the fee may seem extremely low (0.0005 BTC for a 1,000 BTC transfer) or unfairly high (0.004 BTC for a 0.02 BTC payment, or about 20%). If you are receiving tiny amounts (''e.g.'' as small payments from a mining pool) then fees when sending will be higher than if your activity follows the pattern of conventional consumer or business transactions. <br />
<br />
As of Bitcoin 0.5.3 the required fee will not be higher than 0.05 BTC. For most users there is usually no required fee at all. If a fee is required it will most commonly be 0.0005 BTC.<br />
<br />
=== What happens when someone sends me a bitcoin but my computer is powered off? ===<br />
<br />
Bitcoins are not actually "sent" to your wallet; the software only uses that term so that we can use the currency without having to learn new concepts. Your wallet is only needed when you wish to spend coins that you've received.<br />
<br />
If you are sent coins when your wallet client program is not running, and you later launch the wallet client program, the coins will eventually appear as if they were just received in the wallet. That is to say, when the client program is started it must download blocks and catch up with any transactions it did not already know about.<br />
<br />
=== How long does "synchronizing" take when the Bitcoin client is first installed? What's it doing? ===<br />
<br />
The popular Bitcoin client software from bitcoin.org implements a "full" Bitcoin node: It can carry out all the duties of the Bitcoin P2P system, it isn't simply a "client". One of the principles behind the operation of full Bitcoin nodes is that they don't assume that the other participants have followed the rules of the Bitcoin system. During synchronization, the software is processing historical Bitcoin transactions and making sure for itself that all of the rules of the system have been correctly followed.<br />
<br />
In normal operation, after synchronizing, the software should use a hardly noticeable amount of your computer's resources.<br />
<br />
When the wallet client program is first installed, its initial validation requires a lot of work from your computer's hard disk, so the amount of time to synchronize depends on your disk speed and, to a lesser extent, your CPU speed. It can take anywhere from a few hours to a day or so. On a slow computer it could take more than 40 hours of continuous synchronization, so check your computer's power-saving settings to ensure that it does not turn its hard disk off when unattended for a few hours. You can use the Bitcoin software during synchronization, but you may not see recent payments to you until the client program has caught up to the point where those transactions happened.<br />
<br />
If you feel that this process takes too long, you can download a pre-synchronized blockchain from [http://eu1.bitcoincharts.com/blockchain/ http://eu1.bitcoincharts.com/blockchain/]. Alternatively, you can try an alternative "lite" client such as Multibit or a super-light client like electrum, though these clients have somewhat weaker security, are less mature, and don't contribute to the health of the P2P network.<br />
<br />
==Networking==<br />
=== Do I need to configure my firewall to run Bitcoin? ===<br />
<br />
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. [[Testnet]] uses TCP port 18333 instead of 8333.<br />
<br />
If you want to restrict your firewall rules to a few IPs, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]].<br />
<br />
=== How does the peer finding mechanism work? ===<br />
<br />
Bitcoin finds peers primarily by forwarding peer announcements within its own network and each node saves a database of peers that it's aware of, for future use. In order to bootstrap this process Bitcoin needs a list of initial peers, these can be provided manually but normally it obtains them by querying a set of DNS domain names which have automatically updated lists, if that doesn't work it falls back to a build-in list which is updated from time to time in new versions of the software. There is also an IRC based mechanism but it is disabled by default.<br />
<br />
==Mining==<br />
===What is mining?===<br />
[[Mining]] is the process of spending computation power to secure Bitcoin transactions against reversal and introducing new Bitcoins to the system.<br />
<br />
Technically speaking, mining is the calculation of a [[hash]] of the a block header, which includes among other things a reference to the previous block, a hash of a set of transactions and a [[nonce]]. If the hash value is found to be less than the current [[target]] (which is inversely proportional to the [[difficulty]]), a new block is formed and the miner gets the newly generated Bitcoins (50 per block at current levels). If the hash is not less than the current target, a new nonce is tried, and a new hash is calculated. This is done millions of times per second by each miner.<br />
<br />
===Is mining used for some useful computation?===<br />
The computations done when mining are internal to Bitcoin and not related to any other distributed computing projects. They serve the purpose of securing the Bitcoin network, which is useful.<br />
<br />
===Is it not a waste of energy?===<br />
Spending energy on creating and securing a free monetary system is hardly a waste. Also, services necessary for the operation of currently widespread monetary systems, such as banks and credit card companies, also spend energy, arguably more than Bitcoin would.<br />
<br />
===Why don't we use calculations that are also useful for some other purpose?===<br />
To provide security for the Bitcoin network, the calculations involved need to have some very specific features. These features are incompatible with leveraging the computation for other purposes.<br />
<br />
===How can we stop miners from creating zero transaction blocks?===<br />
The incentive for miners to include transactions is in the fees that come along with them. If we were to implement some minimum number of transactions per block it would be trivial for a miner to create and include transactions merely to surpass that threshold. As the network matures, the block reward drops, and miners become more dependent on transactions fees to pay their costs, the problem of zero transaction blocks should diminish over time.<br />
<br />
===How does the proof-of-work system help secure Bitcoin?===<br />
To give a general idea of the mining process, imagine this setup:<br />
<br />
payload = <some data related to things happening on the Bitcoin network><br />
nonce = 1<br />
hash = [http://en.wikipedia.org/wiki/SHA2 SHA2]( [http://en.wikipedia.org/wiki/SHA2 SHA2]( payload + nonce ) )<br />
<br />
The cost function use in bitcoin is the [http://en.wikipedia.org/wiki/Hashcash Hashcash] cost-function. Bit coin mining intensively computes a high value Hashcash stamp on the underlying block chain data. The hashcash stamp that Bitcoin miners produce is computed by repeatedly increasing "nonce" until<br />
the hash function yields a value, that has the rare property of being below a certain<br />
target threshold. (In other words: The hash "starts with a certain number of zeroes",<br />
if you display it in the fixed-length representation, that is typically used.)<br />
<br />
As can be seen, the mining process doesn't compute anything special. It merely<br />
tries to find a number (also referred to as nonce) which - in combination with the payload -<br />
results in a hash with special properties.<br />
<br />
The advantage of using the hashcash mechanism consists of the fact, that it is very easy to check a result: Given the payload and a specific nonce, only a single call of the hashing function is needed to verify that the hash has the required properties. Since there is no known way to find these hashes other than brute force, this can be used as a "proof of work" that someone invested a lot of computing power to find the correct nonce for this payload.<br />
<br />
This feature is then used in the Bitcoin network to secure various aspects. An attacker<br />
that wants to introduce malicious payload data into the network, will need to do the<br />
required hashcash proof of work before it will be accepted. And as long as honest miners have more<br />
computing power, they can always outpace an attacker.<br />
<br />
Also see [http://en.wikipedia.org/wiki/Hashcash Hashcash] and [http://en.wikipedia.org/wiki/Proof-of-work_system Proof-of-work system] and [http://en.wikipedia.org/wiki/SHA2 SHA2] and on Wikipedia.<br />
<br />
===Why was the "Generate coin" option of the client software removed?===<br />
<br />
In the early days of Bitcoin, it was easy for anyone to find new blocks using standard CPUs. As more and more people started mining, the [[difficulty]] of finding new blocks has greatly increased to the point where the average time for a CPU to find a single block can be many years. The only cost-effective method of [[Mining|mining]] is using a high-end graphics card with special software (see also [[Why a GPU mines faster than a CPU]]) and/or joining a [[Bitcoin Pool|mining pool]]. Since solo CPU mining is essentially useless, it was removed from the GUI of the Bitcoin software.<br />
<br />
==Security==<br />
<br />
===Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?===<br />
<br />
There are two questions in here. Let's look at them separately.<br />
<br />
;Could miners gang up and give themselves money?<br />
<br />
Mining itself is the process of creating new blocks in the block chain. Each block contains a list of all the transactions that have taken place across the entire Bitcoin network since the last block was created, as well as a hash of the previous block. New blocks are 'mined', or rather, generated, by Bitcoin clients correctly guessing sequences of characters in codes called 'hashes,' which are created using information from previous blocks. Bitcoin users may download specialized 'mining' software, which allows them to dedicate some amount of their processing power – however large or small – to guessing at strings within the hash of the previous block. Whoever makes the right guess first, thus creating a new block, receives a reward in Bitcoins.<br />
<br />
The block chain is one of the two structures that makes Bitcoin secure, the other being the public-key encryption system on which Bitcoin trade is based. The block chain assures that not only is every single transaction that ever takes place recorded, but that every single transaction is recorded on the computer of anyone who chooses to store the relevant information. Many, many users have complete records of every transaction in Bitcoins history readily available to them at any point, and anyone who wants in the information can obtain it with ease. These things make Bitcoin very hard to fool.<br />
<br />
The Bitcoin network takes considerable processing power to run, and since those with the most processing power can make the most guesses, those who put the most power toward to sustaining the network earn the most currency. Each correct guess yields, at present, fifty Bitcoins, and as Bitcoins are presently worth something (although the value still fluctuates) every miner who earns any number of Bitcoins makes money. Some miners pull in Bitcoins on their own; and some also join or form pools wherein all who contribute earn a share of the profits. <br />
<br />
Therefore, first answer is a vehement “yes” – no only can miners collude to get more money, Bitcoin is designed to encourage them to do so. Bitcoin pools are communal affairs, and there is nothing dishonest or underhanded about them.<br />
<br />
Of course, the real question is:<br />
<br />
;Can they do so in ways not sanction by Bitcoin developers? Is there any way to rip off the network and make loads of money dishonestly?<br />
<br />
Bitcoin isn't infallible. It can be cheated, but doing so is extremely difficult. Bitcoin was designed to evade some of the central problems with modern currencies – namely, that their trustworthiness hinges upon that of people who might not have users' best interests in mind. Every currency in the world (other than Bitcoin) is controlled by large institutions who keep track of what's done with it, and who can manipulate its value. And every other currency has value because people trust the institutions that control them.<br />
<br />
Bitcoin doesn't ask that its users trust any institution. Its security is based on the cryptography that is an integral part of its structure, and that is readily available for any and all to see. Instead of one entity keeping track of transactions, the entire network does, so Bitcoins are astoundingly difficult to steal, or double-spend. Bitcoins are created in a regular and predictable fashion, and by many different users, so no one can decide to make a whole lot more and lessen their value. In short, Bitcoin is designed to be inflation-proof, double-spend-proof and completely distributed.<br />
<br />
Nonetheless, there are a few ways that one can acquire Bitcoins dishonestly. Firstly, one can steal private keys. Key theft isn't something that Bitcoin security has been designed to prevent: it's up to users to keep theirs safe. But the cryptography is designed so that it is completely impossible to deduce someone's private key from their public one. As long as you keep your private key to yourself, you don't have much to worry about. Furthermore, one could theoretically create a new block chain, but due to the way in which the block chain is constructed, this would be extremely difficult and require massive amounts of processing power. A full explanation of the difficulties involved can be found in the [[block chain]] article.<br />
<br />
Bitcoin can be ripped off – but doing so would be extremely hard and require considerable expertise and a staggering amount of processing power. And it's only going to get harder with time. Bitcoin isn't impenetrable, but it's close enough to put any real worries in the peripherals.<br />
<br />
;Could miners fundamentally change the nature of Bitcoin?<br />
<br />
Once again, almost certainly not.<br />
<br />
Bitcoin is a distributed network, so any changes implemented to the system must be accepted by all users. Someone trying to change the way Bitcoins are generated would have to convince every user to download and use their software – so the only changes that would go through are those that would be equally benefit all users. <br />
<br />
And thus, it is more or less impossible for anyone to change the function of Bitcoin to their advantage. If users don't like the changes, they won't adopt them, whereas if users do like them, then these will help everyone equally. Of course, one can conceive of a situation where someone manages to get a change pushed through that provides them with an advantage that no one notices, but given that Bitcoin is structurally relatively simple, it is unlikely that any major changes will go through without someone noticing first.<br />
<br />
The fact that such changes are so difficult to make testifies to the fully distributed nature of Bitcoin. Any centrally controlled currency can be modified by its central agency without the consent of its adherents. Bitcoin has no central authority, so it changes only at the behest of the whole community. Bitcoins development represents a kind of collective evolution; the first of its kind among currencies.<br />
<br />
==Help==<br />
===I'd like to learn more. Where can I get help?===<br />
<br />
* Read the [[Introduction|introduction to bitcoin]] <br />
* See the videos, podcasts, and blog posts from the [[Press]]<br />
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]<br />
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels<br />
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works<br />
* Ask questions on the [http://bitcoin.stackexchange.com Bitcoin Stack Exchange]<br />
<br />
==See Also==<br />
<br />
* [[Man page]]<br />
* [[Introduction]]<br />
<br />
[[de:FAQ]]<br />
[[zh-cn:FAQ]]<br />
[[fr:FAQ]]<br />
[[ru:FAQ]]<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=27206Fallback Nodes2012-05-26T01:40:50Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>This is a list of nodes which are considered reliable. <del>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]] </del>.<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running version 0.6 as being down'''.<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you will need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 vso3r6cmjoomhhgg.onion<br />
mapaddress 192.0.2.3 sjdntqu5roj4q6lo.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect).<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
If you would like to use these nodes in addition to the hard-coded node list in the client, you can substitute "connect" with "addnode". However, if you want to keep all your Bitcoin communication strictly within the Tor network, it is recommended that you use "connect."<br />
<br />
Additional suggested settings for hidden node operators:<br />
<br />
noirc=1<br />
upnp=0<br />
listen=1<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
'''Wikibot is currently malfunctioning and is incorrectly marking nodes running 0.6 as being down'''.<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 79.160.221.140 || K-Norway || 79.160.221.140 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| netzbasis.de || unknown3 || 81.169.129.25 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| bauhaus.csail.mit.edu || imsaguy || 128.30.96.44 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 178.32.7.171 || temporary-april-2012 || 178.32.7.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| cheaperinbitcoins.com || Xenland/Shane || 184.154.36.82 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| django.webflows.fr || unknown2 || 188.165.213.169 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Down}} || || Yes<br />
|-<br />
| progressbar.sk || Progressbar hackerspace || 91.210.181.21 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || || Yes<br />
<!-- END NODELIST --><br />
|}<br />
<br />
There is a list of nodes which have been seen on the network recently at http://blockchain.info/connected-nodes<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| 7hxvg2lvr2ashzli.onion || Tuxavant || up || 2012-05-19 || ?<br />
|-<br />
| siqdznszjf4e6v5j.onion || Tuxavant || up || 2012-05-19 || ?<br />
|-<br />
| fpt6orohw2nuf2kn.onion || Tril || up || 2012-05-19 || No<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || up || 2012-05-19 || Yes<br />
|-<br />
| sjdntqu5roj4q6lo.onion || torservers || up || 2012-05-19 || ?<br />
|-<br />
| bitcoin2bkgm3fke.onion || ? || down || 2012-05-19 || Yes<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || up || 2012-05-25 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| kjy2eqzk4zwi5zd3.onion || sipa || up || 2012-05-21 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
==See Also==<br />
<br />
* [[Network|Bitcoin Network]]</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21424Fallback Nodes2011-12-29T07:37:23Z<p>Redemerald: /* Adding a node */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-29 07:00:05 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-29 07:00:05 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-29 07:00:06 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-29 07:00:06 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-29 07:00:06 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-29 07:00:06 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.4.0}} || 2011-12-29 07:00:06 || No<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-29 07:00:06 || ?<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-28 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| esvua6k2gzjj64ad.onion || redemerald || ? || 2011-12-28 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot is supposed to connect to your node every hour to check its status and version. Sadly, this bot appears to be offline.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21408Fallback Nodes2011-12-28T21:04:03Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-28 21:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-28 21:00:03 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-28 21:00:03 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-28 21:00:03 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-28 21:00:11 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-28 21:00:11 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.4.0}} || 2011-12-28 21:00:11 || No<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-28 21:00:11 || ?<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-28 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|-<br />
| esvua6k2gzjj64ad.onion || redemerald || ? || 2011-12-28 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Contingency_plans&diff=21346Contingency plans2011-12-27T22:41:07Z<p>Redemerald: </p>
<hr />
<div>The purpose of this page is to create plans for the first few days after a catastrophic failure of the network in order to save time should any such failure actually occur.<br />
<br />
Only failures that would not allow much time for discussion will be covered here. ''Preventing'' future problems will not be discussed.<br />
<br />
Once the plans themselves are well-accepted, code implementing the plans can be written and tested in case the code is ever required.<br />
<br />
==Getting the word out==<br />
<br />
===Alerts===<br />
These people have alert keys and should be contacted ASAP in case of emergencies:<br />
* Satoshi<br />
* Gavin<br />
* theymos<br />
Email Satoshi, even though he is believed to be gone. A serious issue may "bring him out of retirement", which would be helpful.<br />
<br />
Because alerts are known to be very secure, all information related to an emergency should be sent with alerts. For example, hashes of new releases should be included in alerts.<br />
<br />
The most important part of alert messages should be put at the front, since the remaining text might get cut off. A good way to begin would be: "EMERGENCY: DO NOT ACCEPT OR SEND PAYMENTS".<br />
<br />
===Pools===<br />
The owners of all pools must be contacted, as changes will be required of them.<br />
<br />
===IRC===<br />
All of the IRC channels should have their topics updated to spread info about the emergency.<br />
<br />
===Forum===<br />
A topic should be posted in "development and technical discussion", and a sticky locked topic pointing to the main topic should be created in all other sections. The main topic should not be sticky, as this makes it more difficult to see and it will be bumped to the top constantly, anyway.<br />
<br />
===Sites===<br />
The owners of all big sites, especially exchanges and banks, should be contacted.<br />
<br />
===Stock message===<br />
Here is a message that could be used to spread the word. Preferably it would be updated to reflect specifics and signed by some trusted people.<br />
<br />
A critical bug has been discovered in Bitcoin. Transactions must be considered REVERSIBLE for the time being. Do not send payments, and do not trust payments that you receive.<br />
<br />
If you run a Bitcoin-related site, shut down the site and replace it with this message.<br />
<br />
[Note: The following paragraph only applies to certain attacks and may need to be removed.]<br />
<br />
If you are solo mining or running a pool, you must stop mining until you upgrade to the latest version (which may not be released quite yet). If you are mining in a pool, shut down your miner until your pool upgrades. If you continue mining, any blocks you solve will end up being rejected eventually, and you will be working against the legitimate chain.<br />
<br />
Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty. The most trustworthy source of information is the text that appears at the bottom of the graphical Bitcoin client.<br />
<br />
==Coordination==<br />
<br />
During an emergency, coordination will take place on the #bitcoin-dev channel on chat.freenode.net. All decisions will take place there. Possibly additional channels will be created if there is too much discussion happening for one channel, though #bitcoin-dev is where all developers will naturally go, and it is therefore best if general discussion about the emergency takes place there.<br />
<br />
Channel mode "+q $~a" should be set in order to prevent unregistered users from speaking. The last thing we want is an impersonator or a spam flood. People should also be identified with [[gribble]] if possible. Mode +m may also need to be set if there is too much spam.<br />
<br />
===Backup communication methods===<br />
It is not impossible for an attacker to make #bitcoin-dev unusable, either through abuse or denial-of-service attacks. There must be several backup methods of communication.<br />
<br />
====IRC====<br />
<br />
If #bitcoin-dev becomes unusable due to flooding or other abuse that the Freenode IRC operators are unable/unwilling to handle, then moving #bitcoin-dev to irc.lfnet.org will be useful. The operators of LFnet are Bitcoin users who will be very helpful in fighting abuse.<br />
<br />
If Freenode is taken down by a denial-of-service attack, #bitcoin-dev can be moved to one of the larger networks, which will (presumably) be more resistant to attacks.<br />
<br />
So if the regular #bitcoin-dev is broken, try #bitcoin-dev on these networks:<br />
* LFnet<br />
* IRCnet<br />
* EFnet<br />
* Undernet<br />
* Any other IRC networks you know of<br />
<br />
Gribble can be moved to any network in order to facilitate GPG identification.<br />
<br />
====Other real-time chat====<br />
<br />
In case all IRC networks are made unusable, Google+ multi-user chat might work well, and it is unlikely to be brought down by denial-of-service attacks.<br />
<br />
(A distributed chat network where every participant needs to send his message directly to all other participants would be best, as this would be difficult to attack. Does something like this exist?)<br />
<br />
====Non-realtime communication====<br />
<br />
The SourceForge mailing list can be used for non-realtime communication. In case this list is brought down, participants can send emails manually to a list of people.<br />
<br />
===Issuing statements===<br />
When it has been decided by the developers that action is required by Bitcoin users, a statement will be issued. All statements should contain text encouraging people to distribute the statement. Statements should be numbered sequentially from the start of the incident.<br />
<br />
Statements should be PGP signed by a few people present at the time and then emailed to owners of big sites and posted on bitcoin.org and the forums.<br />
<br />
An alert summarizing the statement will probably need to be issued, as well.<br />
<br />
===Emergency versions===<br />
Emergency versions of Bitcoin should preferably be based on the latest stable version instead of the very latest code in order to avoid introducing new bugs.<br />
<br />
Source releases should be made as soon as a fix is available, even if it can't yet be hosted on SourceForge. In most cases, binary releases can wait for the people who normally build binaries to do it. If source releases are available without binary releases, statements should encourage users to either compile themselves or wait for official binary releases (instead of using binaries provided by third-parties).<br />
<br />
==Contingencies==<br />
===Many historical blocks replaced===<br />
<br />
Situation: 6+ historical blocks have been replaced by new versions all at once, allowing confirmed transactions to be invalidated.<br />
<br />
====Impact====<br />
<br />
* People who have received payments from the attacker might have these payments reversed.<br />
* The double-spent versions of these transactions might immediately get 6+ confirmations. So people receiving the attacker's stolen coins might accept them.<br />
* Other transactions may become unconfirmed again.<br />
<br />
====Response====<br />
<br />
* Alert users to stop accepting payments, as an attacker clearly has too much control over the network. The network will be unusable for weeks or more while the issue is straightened out.<br />
<br />
If more than a few BTC was stolen by the attacker, then the transaction ordering may need to be manually modified. This is done by adding new block checkpoints and/or hardcoding transaction ordering [note: code should be prepared for hardcoded transaction ordering].<br />
<br />
A lot of time should be taken to decide whether and how to re-order the transactions. It may be a very complex issue, as restoring the original versions of transactions could cause damage many times larger than the original transaction reversal. The network will need to be offline for a week or more after an incident of this scale, anyway.<br />
<br />
===SHA-256 is broken===<br />
Situation: Severe, 0-day failure of SHA-256. First/second preimage resistance or collision resistance can be defeated with only a few days of work.<br />
<br />
====Impact====<br />
<br />
* Attacker may be able to defeat OP_CHECKSIG, which hashes transactions before signing.<br />
* Attacker may be able to split the network by creating identical transactions or blocks with the same hashes.<br />
* Attacker may be able to create blocks very quickly.<br />
* The alert system may be compromised.<br />
<br />
====Response====<br />
<br />
* Users will be notified to shut down their clients. Note that the attacker may be able to send valid alerts, which could disrupt notification efforts.<br />
* OP_CHECKSIG will be changed to use some other hash outside of old blocks.<br />
* All addresses in the version-1 chain that have a known public key and at least one unspent output will have their public keys hardcoded into the client. When a version-2 transaction spends one of these version-1 outputs, the hardcoded public key will be used instead of the hash.<br />
* The version-1 chain will be securely hashed into a hash tree. At least the root of the version-1 tree will be hardcoded into the client.<br />
* All hashing Bitcoin does will use the new hashing algorithm.<br />
<br />
[Code for all of this should be prepared.]<br />
<br />
===ECDSA is broken===<br />
Situation: an attacker can sign for a public key that he does not own the private key for in only a few days of work.<br />
<br />
====Impact====<br />
* Attacker can spend money that is not his in a large number of cases. Transactions to addresses that have never been used before may be protected if SHA-256 and RIPEMD-160 are still strong.<br />
* Alert system may be compromised.<br />
<br />
====Response====<br />
<br />
If the attacker can't get the private key from the public key easily and a stronger algorithm that can use ECDSA keys is available:<br />
* Switch to the stronger algorithm.<br />
* Get users to update. Alerts will be compromised.<br />
<br />
Otherwise:<br />
* OP_CHECKSIG should use some other signing algorithm.<br />
* As soon as the new version of Bitcoin is run, it should automatically send all old transactions somewhere else using the new algorithm.<br />
* Get users to update immediately. Alerts will be compromised.<br />
<br />
[Code for all of this should be prepared.]<br />
<br />
===Remote attacker can execute arbitrary code===<br />
Situation: Due to a bug in Bitcoin, a remote attacker is able to run arbitrary code on the machines of some/all Bitcoin users.<br />
<br />
====Impact====<br />
* Attacker can install malware, which could be used to steal private keys from wallets that are decrypted while the malware is installed.<br />
<br />
====Response====<br />
* Issue an alert telling people to shut down their clients immediately and look for updates elsewhere. Put special effort into alerting people through other means.<br />
* Remove critical powers (git push, bitcoin.org update, IRC op, etc.) from people who do not need them, as all Bitcoin users are at a high risk of having their passwords compromised. Trust GPG signatures a bit less than usual.<br />
<br />
Stock alert message: "EMERGENCY: SHUT DOWN YOUR CLIENT RIGHT NOW! Look for updates on popular Bitcoin sites. A bug has been discovered that can allow a remote attacker to install malware on your computer through Bitcoin."<br />
<br />
Stock statement:<br />
<br />
A bug has been discovered in Bitcoin that can allow a remote attacker to execute arbitrary code. The attacker could install malware onto your computer, which could steal your wallet. Shut down Bitcoin now. Under no circumstances should you enter your wallet passphrase until this incident is resolved and you have made absolutely sure that there is no malware on your computer. If possible, carefully copy your wallet to some offline safe location and then securely delete the copy on your computer.<br />
<br />
Look to your favorite HTTPS-enabled Bitcoin sites for more news. Before running any software, check that a consensus exists among several sites. Do not trust information from Google, as it can be manipulated by the attacker. Other sites, such as bitcoin.org, can likewise be manipulated, though with more difficulty.<br />
<br />
===Emergency rule change===<br />
Situation: A core network rule in Bitcoin is broken and needs to be changed ASAP. Like the [[Incidents#Value_overflow|overflow incident]].<br />
<br />
====Response====<br />
* Issue an alert. Tell people to stop mining.<br />
* After the issue is fixed, get people to update.<br />
<br />
It is preferable to make a rule more restrictive than to relax a rule. In the former case, only miners need update.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21311Fallback Nodes2011-12-27T05:00:19Z<p>Redemerald: /* Tor network */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses ([[Fallback_Nodes#Tor_nodes|listed below]]), you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:03 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-27 04:00:03 || ?<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-27 04:01:03 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || 2011-12-27 03:00:04 || No<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-26 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21310Fallback Nodes2011-12-27T04:29:16Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:03 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-27 04:00:03 || ?<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-27 04:01:03 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || 2011-12-27 03:00:04 || No<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-26 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || ?<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21309Fallback Nodes2011-12-27T04:28:13Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:03 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-27 04:00:03 || ?<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-27 04:01:03 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || 2011-12-27 03:00:04 || No<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-26 || No<br />
|-<br />
| bxfna6fhddpzduck.onion || ? || ? || ? || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21308Fallback Nodes2011-12-27T04:27:14Z<p>Redemerald: /* Tor network */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
And then put these IPs in your bitcoin.conf (or run bitcoin with -connect)<br />
<br />
connect=192.0.2.2<br />
connect=192.0.2.3<br />
connect=192.0.2.4<br />
<br />
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 (reference?). 192.0.2.1-192.0.2.255 is the recommended range because it is both non-routable and compatible with Bitcoin.<br />
<br />
It is highly recommended that you use "connect" instead of "addnode" so that all of your communications are kept within the tor network.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:03 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-27 04:00:03 || ?<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-27 04:01:03 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || 2011-12-27 03:00:04 || No<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-26 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Tor&diff=21307Tor2011-12-27T04:22:20Z<p>Redemerald: /* Hidden services */</p>
<hr />
<div>'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.<br />
<br />
Bitcoin can run easily on the Tor network. <br />
<br />
=Tor installation & use=<br />
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers''<br /><br />
<br />
Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.''<br /><br />
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic.<br /><br />
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in.<br /><br />
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.<br />
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]<br />
<br />
=GUI=<br />
Once you have your Tor client up & running, you can configure your Bitcoin client to use it.<br /><br />
Select in menu Settings -> Options<br /><br />
[[{{ns:file}}:20110108-btc-options.png]]<br /><br />
<br />
Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number)<br /><br />
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]]<br /><br />
Configuring an application to use Tor is also called to torify it.<br />
(needs a brief howto here)<br />
<br />
''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''<br />
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.<br />
<br />
=bitcoind=<br />
<br />
Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).<br />
<br />
bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.<br />
<br />
=Hidden services=<br />
These services are running within the tor network. You can connect to them for example using the -connect= parameter to bitcoind. Note that you do not need to use them - tor can also anonymize your normal internet traffic, including bitcoin connections. There are some technical reasons why hidden services may be beneficial, see the tor documentation if you're really interested.<br />
<br />
Services are listed at [[Fallback_Nodes#Tor_network]] along with instructions for using them.<br />
<br />
=Pooled Mining=<br />
<br />
Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.<br />
<br />
==Linux / BSD==<br />
<br />
Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
==Windows / OS X==<br />
<br />
It is possible to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
=mIRC=<br />
<br />
mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC.<br /><br />
==Register your nick with freenode nickserv<br />==<br />
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname.<br /><br />
Connect to Freenode IRC without using tor & execute<br /><br />
/msg nickserv register <password> <email><br /><br />
<br /><br />
You will see something like this<br /><br />
-NickServ- An email containing nickname activation instructions has been sent to <email><br /><br />
-NickServ- If you do not complete registration within one day, your nickname will expire.<br /><br />
<br /><br />
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc.<br /><br />
<br />
==Add SASL support to your mIRC installation<br />==<br />
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory<br /><br />
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit").<br /><br />
[[{{ns:file}}:20110109-sasl-script-loaded.png]]<br /><br />
Type /dialog -m SASL.main SASL.main to open the SASL connection manager.<br /><br />
[[{{ns:file}}:20110109-sasl-dialog.png]]<br /><br />
Add Freenode entry.<br /><br />
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]]<br /><br />
Network is Freenode.<br /><br />
Username and NS Password must match your nickserv reservation.<br /><br />
Auth Type can be PLAIN<br /><br />
<br />
==setup mIRC to use Tor<br />==<br />
Add the entry for Freenode onion IRC server<br /><br />
[[{{ns:file}}:20110109-onion-irc-add.png]]<br /><br />
Configure mIRC to use a Proxy (your local Tor proxy)<br /><br />
[[{{ns:file}}:20110109-mirc-proxy.png]]<br /><br />
<br /><br />
Now you should be able to connect.<br /><br />
[http://www.bitcoin.org/smf/index.php?topic=2602 Bitcoin forum where this topic is discussed]<br />
<br />
=How Tor works=<br />
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.<br />
<br />
Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.<br />
<br />
Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:<br />
Send to this IP: <IP of Relay1><br />
<Encrypted data for Relay1><br />
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:<br />
Send to this Tor node: <Relay2><br />
<Encrypted data for Relay2><br />
Relay2 decrypts his payload:<br />
Send to this Tor node: <Relay3><br />
<Encrypted data for Relay3><br />
Relay3 receives the real TCP payload, which he sends to the destination:<br />
Send to this IP: <IP of destination><br />
<Unencrypted payload><br />
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!<br />
<br />
The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.<br />
<br />
However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:<br />
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination<br />
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.<br />
<br />
Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):<br />
*S-ISP & Relay3<br />
*Relay1 & Relay3<br />
*S-ISP & D-ISP<br />
*Relay1 & D-ISP<br />
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)<br />
<br />
Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.<br />
<br />
These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.<br />
<br />
To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.<br />
<br />
Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:<br />
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.<br />
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.<br />
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.<br />
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.<br />
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.<br />
<br />
For clients, hidden services are more secure than encrypted Tor HTTPS connections because:<br />
*If the destination remains anonymous, they are less likely to become controlled by an evil party.<br />
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:<br />
**S-ISP & Destination<br />
**Relay1 & Destination<br />
<br />
Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:<br />
*Your Internet service is cut off.<br />
*If the hidden service went down at that exact moment, you are unmasked.<br />
The same sort of timing attacks as above are also possible.<br />
<br />
See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.<br />
<br />
=External Tor Hidden Services=<br />
<br />
* [http://vms43o4cqysakvyb.onion Bitcoin 4 Cash] ([[Bitcoin 4 Cash|info]])<br />
* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]<br />
<br />
=External links=<br />
<br />
* [http://tor.eff.org/ Tor project]<br />
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]<br />
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]<br />
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]<br />
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]<br />
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]<br />
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]<br />
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]<br />
* [http://freenode.net/sasl/ Freenode resources on SASL]</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Fallback_Nodes&diff=21306Fallback Nodes2011-12-27T04:19:15Z<p>Redemerald: /* Tor nodes */</p>
<hr />
<div>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]].<br />
<br />
== How to use this list ==<br />
<br />
=== Connect to nodes ===<br />
<br />
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.<br />
<br />
==== Nodes without a fixed ip ====<br />
<br />
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.<br />
<br />
In order to enable hostname lookups for the ''-addnode'' and ''-connect'' parameters, you must additionally provide the ''-dns'' parameter. Example:<br />
bitcoind -dns -addnode=bitcoin.es<br />
<br />
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:<br />
bitcoind -addnode=$(dig +short bitcoin.es)<br />
<br />
=== IP Transactions ===<br />
<br />
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.<br />
<br />
=== Tor network ===<br />
<br />
To use tor .onion addresses, you need to map virtual ips via the ''torrc'' file:<br />
<br />
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion<br />
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion<br />
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion<br />
<br />
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.<br />
<br />
== Nodes list ==<br />
<br />
=== IPv4 Nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! IP !! Fixed !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
<!-- BEGIN NODELIST --><br />
| 88.191.116.112 || ? || 88.191.116.112 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| btcnode.novit.ro || ovidiusoft - novit.ro || 93.187.142.114 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.1}} || 2011-12-27 04:00:02 || Yes<br />
|-<br />
| 98.143.152.14 || osmosis || 98.143.152.14 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| 173.66.83.171 || bitcoin debit || 173.66.83.171 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:02 || ?<br />
|-<br />
| BitcoinStats.org || Atheros || 75.186.58.44 || {{Table Value No}} || {{Fallback Nodes/Node Up|version=0.5.0[.1]}} || 2011-12-27 04:00:03 || No<br />
|-<br />
| vps.CFSworks.com || CFSworks || 108.60.198.108 || {{Table Value Unknown}} || {{Fallback Nodes/Node Up|version=0.5.0}} || 2011-12-27 04:00:03 || ?<br />
|-<br />
| 204.9.55.71 || toasty || 204.9.55.71 || {{Table Value Yes}} || {{Fallback Nodes/Node Up|version=0.3.25}} || 2011-12-27 04:01:03 || ?<br />
|-<br />
| fallback.nodes.bitcoinica.com || Bitcoinica || 173.255.194.34 || {{Table Value No}} || {{Fallback Nodes/Node Down}} || 2011-12-27 03:00:04 || No<br />
<!-- END NODELIST --><br />
|}<br />
<br />
=== Tor nodes ===<br />
<br />
{|class="wikitable sortable"<br />
! Hostname !! Owner !! Status !! Last Seen (GMT) !! Accepts IP transactions<br />
|-<br />
| ijzt2eeizty3p5xe.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| j43z65b6r2usg3vk.onion || Dybbuk || ? || 2011-02-11 || Yes<br />
|-<br />
| pvuif6nonbhj3o3r.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| c5qvugpewwyyy5oz.onion || ? || ? || 2011-02-11 || Yes<br />
|-<br />
| vso3r6cmjoomhhgg.onion || echelon || ? || 2011-02-11 || Yes<br />
|-<br />
| bitcoinbudtoeks7.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| iy6ni3wkqazp4ytu.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| h4kklwodpcmo6cbq.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| vv6kcfscuntybrzm.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| nlnsivjku4x4lu5n.onion || ? || ? || 2011-02-11 || ?<br />
|-<br />
| xqzfakpeuvrobvpj.onion || ? || ? || 2010-11-13 || No<br />
|-<br />
| 4lmduyac3svgrrav.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| usasx4urod3yj4az.onion || ? || ? || 2011-02-11 || No<br />
|-<br />
| sh4ep6zb6vnoa2h5.onion || Gmaxwell || ? || 2011-10-29 || No<br />
|-<br />
| e3tn727fywnioxrc.onion || ? || ? || 2011-11-01 || No<br />
|-<br />
| p2hwc26zdsrqxiix.onion || redemerald || ? || 2011-12-26 || No<br />
|}<br />
<br />
== Adding a node ==<br />
<br />
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.<br />
<br />
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:<br />
<br />
<nowiki>|-<br />
| ip || your name</nowiki><br />
<br />
Please note that a bot will connect to your node every hour to check its status and version.</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Tor&diff=21305Tor2011-12-27T04:17:34Z<p>Redemerald: </p>
<hr />
<div>'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.<br />
<br />
Bitcoin can run easily on the Tor network. <br />
<br />
=Tor installation & use=<br />
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers''<br /><br />
<br />
Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.''<br /><br />
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic.<br /><br />
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in.<br /><br />
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.<br />
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]<br />
<br />
=GUI=<br />
Once you have your Tor client up & running, you can configure your Bitcoin client to use it.<br /><br />
Select in menu Settings -> Options<br /><br />
[[{{ns:file}}:20110108-btc-options.png]]<br /><br />
<br />
Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number)<br /><br />
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]]<br /><br />
Configuring an application to use Tor is also called to torify it.<br />
(needs a brief howto here)<br />
<br />
''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''<br />
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.<br />
<br />
=bitcoind=<br />
<br />
Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).<br />
<br />
bitcoind will detect that you are using a proxy on 9050 and will force the "nolisten" flag. If you are not running tor on 9050, you need to set "nolisten" manually otherwise you will listen on your public IP and possibly reveal that you are running a node.<br />
<br />
=Hidden services=<br />
These services are running within the tor network. You can connect to them for example using the -connect= parameter to bitcoind. Note that you do not need to use them - tor can also anonymize your normal internet traffic, including bitcoin connections. There are some technical reasons why hidden services may be beneficial, see the tor documentation if you're really interested.<br />
<br />
Please add your service here if you run a stable bitcoin node under a tor hidden service.<br />
* sh4ep6zb6vnoa2h5.onion<br />
* iy6ni3wkqazp4ytu.onion<br />
* bxfna6fhddpzduck.onion<br />
* p2hwc26zdsrqxiix.onion<br />
<br />
Note, you do not put these directly in your bitcoin.conf. Bitcoin does not support remote DNS through a proxy, so you must set a mapaddress in your torrc. You can find more hidden services and read about how to use them here: [[Fallback_Nodes#Tor_network]]<br />
<br />
=Pooled Mining=<br />
<br />
Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.<br />
<br />
==Linux / BSD==<br />
<br />
Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
==Windows / OS X==<br />
<br />
It is possible to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
=mIRC=<br />
<br />
mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC.<br /><br />
==Register your nick with freenode nickserv<br />==<br />
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname.<br /><br />
Connect to Freenode IRC without using tor & execute<br /><br />
/msg nickserv register <password> <email><br /><br />
<br /><br />
You will see something like this<br /><br />
-NickServ- An email containing nickname activation instructions has been sent to <email><br /><br />
-NickServ- If you do not complete registration within one day, your nickname will expire.<br /><br />
<br /><br />
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc.<br /><br />
<br />
==Add SASL support to your mIRC installation<br />==<br />
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory<br /><br />
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit").<br /><br />
[[{{ns:file}}:20110109-sasl-script-loaded.png]]<br /><br />
Type /dialog -m SASL.main SASL.main to open the SASL connection manager.<br /><br />
[[{{ns:file}}:20110109-sasl-dialog.png]]<br /><br />
Add Freenode entry.<br /><br />
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]]<br /><br />
Network is Freenode.<br /><br />
Username and NS Password must match your nickserv reservation.<br /><br />
Auth Type can be PLAIN<br /><br />
<br />
==setup mIRC to use Tor<br />==<br />
Add the entry for Freenode onion IRC server<br /><br />
[[{{ns:file}}:20110109-onion-irc-add.png]]<br /><br />
Configure mIRC to use a Proxy (your local Tor proxy)<br /><br />
[[{{ns:file}}:20110109-mirc-proxy.png]]<br /><br />
<br /><br />
Now you should be able to connect.<br /><br />
[http://www.bitcoin.org/smf/index.php?topic=2602 Bitcoin forum where this topic is discussed]<br />
<br />
=How Tor works=<br />
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.<br />
<br />
Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.<br />
<br />
Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:<br />
Send to this IP: <IP of Relay1><br />
<Encrypted data for Relay1><br />
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:<br />
Send to this Tor node: <Relay2><br />
<Encrypted data for Relay2><br />
Relay2 decrypts his payload:<br />
Send to this Tor node: <Relay3><br />
<Encrypted data for Relay3><br />
Relay3 receives the real TCP payload, which he sends to the destination:<br />
Send to this IP: <IP of destination><br />
<Unencrypted payload><br />
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!<br />
<br />
The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.<br />
<br />
However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:<br />
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination<br />
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.<br />
<br />
Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):<br />
*S-ISP & Relay3<br />
*Relay1 & Relay3<br />
*S-ISP & D-ISP<br />
*Relay1 & D-ISP<br />
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)<br />
<br />
Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.<br />
<br />
These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.<br />
<br />
To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.<br />
<br />
Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:<br />
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.<br />
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.<br />
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.<br />
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.<br />
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.<br />
<br />
For clients, hidden services are more secure than encrypted Tor HTTPS connections because:<br />
*If the destination remains anonymous, they are less likely to become controlled by an evil party.<br />
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:<br />
**S-ISP & Destination<br />
**Relay1 & Destination<br />
<br />
Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:<br />
*Your Internet service is cut off.<br />
*If the hidden service went down at that exact moment, you are unmasked.<br />
The same sort of timing attacks as above are also possible.<br />
<br />
See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.<br />
<br />
=External Tor Hidden Services=<br />
<br />
* [http://vms43o4cqysakvyb.onion Bitcoin 4 Cash] ([[Bitcoin 4 Cash|info]])<br />
* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]<br />
<br />
=External links=<br />
<br />
* [http://tor.eff.org/ Tor project]<br />
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]<br />
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]<br />
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]<br />
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]<br />
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]<br />
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]<br />
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]<br />
* [http://freenode.net/sasl/ Freenode resources on SASL]</div>Redemeraldhttps://en.bitcoin.it/w/index.php?title=Tor&diff=21234Tor2011-12-25T02:05:13Z<p>Redemerald: </p>
<hr />
<div>'''Tor''' is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran. Preserving privacy means not only hiding the content of messages, but also hiding who is talking to whom (traffic analysis). Tor provides anonymous connections that are strongly resistant to both eavesdropping and traffic analysis.<br />
<br />
Bitcoin can run easily on the Tor network. <br />
<br />
=Tor installation & use=<br />
''todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers''<br /><br />
<br />
Please follow the instructions provided with installation files and read the [http://www.torproject.org/download/download.html.en#warning list of warnings]. ''Tor doesn't magically anonymize all your traffic just because you install it.''<br /><br />
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic.<br /><br />
[http://www.torproject.org/docs/tor-doc-windows.html.en This] is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in.<br /><br />
[[{{ns:file}}:20110109-tor-running.png]] On the taskbar of your compute you'll see a small green onion when Tor is running.<br />
[[{{ns:file}}:20110109-bitcoin-mirc-vidalia.png]]<br />
<br />
=GUI=<br />
Once you have your Tor client up & running, you can configure your Bitcoin client to use it.<br /><br />
Select in menu Settings -> Options<br /><br />
[[{{ns:file}}:20110108-btc-options.png]]<br /><br />
<br />
Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number)<br /><br />
[[{{ns:file}}:20110108-btc-client-tor-as-proxy.png]]<br /><br />
Configuring an application to use Tor is also called to torify it.<br />
(needs a brief howto here)<br />
<br />
''the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC''<br />
Conducting business using [[bitcoin-otc]] can be done more anonymously when directly connected to a Freenode IRC hidden service.<br />
<br />
=bitcoind=<br />
<br />
Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).<br />
<br />
=Hidden services=<br />
These services are running within the tor network. You can connect to them for example using the -connect= parameter to bitcoind. Note that you do not need to use them - tor can also anonymize your normal internet traffic, including bitcoin connections. There are some technical reasons why hidden services may be beneficial, see the tor documentation if you're really interested.<br />
<br />
Please add your service here if you run a stable bitcoin node under a tor hidden service.<br />
* sh4ep6zb6vnoa2h5.onion<br />
* iy6ni3wkqazp4ytu.onion<br />
* bxfna6fhddpzduck.onion<br />
* p2hwc26zdsrqxiix.onion<br />
<br />
=Pooled Mining=<br />
<br />
Some mining pools are available as a hidden service on the tor network. Any pool can be reached over tor. The general methodology here is to tell your mining client to use your local Tor proxy. This is client specific but there are some helpful hints.<br />
<br />
==Linux / BSD==<br />
<br />
Any client can have its traffic routed via Tor by using the torify command and invoking the miner with that. Another method is to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
==Windows / OS X==<br />
<br />
It is possible to set the http_proxy environment variable as some miners use libraries which support that.<br />
<br />
=mIRC=<br />
<br />
mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC.<br /><br />
==Register your nick with freenode nickserv<br />==<br />
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname.<br /><br />
Connect to Freenode IRC without using tor & execute<br /><br />
/msg nickserv register <password> <email><br /><br />
<br /><br />
You will see something like this<br /><br />
-NickServ- An email containing nickname activation instructions has been sent to <email><br /><br />
-NickServ- If you do not complete registration within one day, your nickname will expire.<br /><br />
<br /><br />
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc.<br /><br />
<br />
==Add SASL support to your mIRC installation<br />==<br />
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory<br /><br />
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit").<br /><br />
[[{{ns:file}}:20110109-sasl-script-loaded.png]]<br /><br />
Type /dialog -m SASL.main SASL.main to open the SASL connection manager.<br /><br />
[[{{ns:file}}:20110109-sasl-dialog.png]]<br /><br />
Add Freenode entry.<br /><br />
[[{{ns:file}}:20110109-sasl-manager.png]][[{{ns:file}}:20110109-sasl-manager-network.png]]<br /><br />
Network is Freenode.<br /><br />
Username and NS Password must match your nickserv reservation.<br /><br />
Auth Type can be PLAIN<br /><br />
<br />
==setup mIRC to use Tor<br />==<br />
Add the entry for Freenode onion IRC server<br /><br />
[[{{ns:file}}:20110109-onion-irc-add.png]]<br /><br />
Configure mIRC to use a Proxy (your local Tor proxy)<br /><br />
[[{{ns:file}}:20110109-mirc-proxy.png]]<br /><br />
<br /><br />
Now you should be able to connect.<br /><br />
[http://www.bitcoin.org/smf/index.php?topic=2602 Bitcoin forum where this topic is discussed]<br />
<br />
=How Tor works=<br />
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.<br />
<br />
Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple ''layers'' of encryption that are ''pulled away'' for each node. Hence the name '''T'''he '''O'''nion '''R'''outer, which is always capitalized as '''Tor''', and never TOR or t.o.r.<br />
<br />
Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:<br />
Send to this IP: <IP of Relay1><br />
<Encrypted data for Relay1><br />
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:<br />
Send to this Tor node: <Relay2><br />
<Encrypted data for Relay2><br />
Relay2 decrypts his payload:<br />
Send to this Tor node: <Relay3><br />
<Encrypted data for Relay3><br />
Relay3 receives the real TCP payload, which he sends to the destination:<br />
Send to this IP: <IP of destination><br />
<Unencrypted payload><br />
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the ''exit node'') can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!<br />
<br />
The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.<br />
<br />
However, Tor is weak to a ''timing attack'' that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:<br />
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination<br />
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.<br />
<br />
Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):<br />
*S-ISP & Relay3<br />
*Relay1 & Relay3<br />
*S-ISP & D-ISP<br />
*Relay1 & D-ISP<br />
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)<br />
<br />
Because the first relay (the ''entry node'') is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three ''entry guards'' that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.<br />
<br />
These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an [[EWallet]] instead of the Bitcoin client when using Tor.<br />
<br />
To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a ''network status consensus'' document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many ''directory mirrors'', which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.<br />
<br />
Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:<br />
*The destination tells several Tor relays to act as ''introduction points'' for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.<br />
*The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.<br />
*The sender creates a four-node Tor circuit. The fourth node is called the ''rendezvous point''.<br />
*The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.<br />
*The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.<br />
<br />
For clients, hidden services are more secure than encrypted Tor HTTPS connections because:<br />
*If the destination remains anonymous, they are less likely to become controlled by an evil party.<br />
*The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:<br />
**S-ISP & Destination<br />
**Relay1 & Destination<br />
<br />
Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:<br />
*Your Internet service is cut off.<br />
*If the hidden service went down at that exact moment, you are unmasked.<br />
The same sort of timing attacks as above are also possible.<br />
<br />
See the [http://www.usenix.org/events/sec04/tech/full_papers/dingledine/dingledine_html/index.html Tor design paper] for more info.<br />
<br />
=External Tor Hidden Services=<br />
<br />
* [http://vms43o4cqysakvyb.onion Bitcoin 4 Cash] ([[Bitcoin 4 Cash|info]])<br />
* [irc://p4fsi4ockecnea7l.onion Freenode hidden service]<br />
<br />
=External links=<br />
<br />
* [http://tor.eff.org/ Tor project]<br />
* [http://www.torproject.org/docs/tor-doc-windows.html.en Tor installation guide - Windows]<br />
* [https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ Tor FAQ]<br />
* [http://www.torproject.org/about/overview.html.en how Tor works - overview]<br />
* [http://freenode.net/irc_servers.shtml#tor Freenode over Tor info]<br />
* [http://wiki.honk-honk.org/wiki/SaslServ#mIRC howto enable SASL in mIRC]<br />
* [http://honk-honk.org/SASL/SASL.dll SASL.dll library for mIRC]<br />
* [http://honk-honk.org/SASL/sasl.mrc sasl script for mIRC]<br />
* [http://freenode.net/sasl/ Freenode resources on SASL]</div>Redemerald