Bitcoin Wiki - User contributions [en]

Controlled supply

2014-03-03T05:55:42Z

Wyager: Added possible justifications for the 21 million Bitcoin cap

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The
[http://en.wikipedia.org/wiki/Monetary_base monetary base] is controlled by a central bank. In the United States, the [http://en.wikipedia.org/wiki/Federal_Reserve_System Fed] increases the monetary base by issuing currency, increasing the amount banks have on reserve, and more recently, printing money electronically in a process called [http://en.wikipedia.org/wiki/Quantitative_easing Quantitative Easing].

In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

==Currency with Finite Supply==

Bitcoins are created each time a user discovers a new [[block]].
The rate of block creation is approximately constant over time: 6 per hour. The
number of Bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 4 years. The result is that the number of Bitcoins in existence will
never exceed 21 million<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref>. This algorithm was chosen because it approximates the rate at which commodities like gold are mined. Possible justifications for the value 21 million are that it matches a 4-year reward halving schedule or that 2.1*10^15 (the maximum number of Satoshis) is close to the maximum exact capacity of a 64-bit floating point number. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].

==Projected Bitcoins Short Term ==
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.
{| class="wikitable"
|-
! Block!!Reward Era!! BTC/block!! Year!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
|0||1||50.00||2009||0||2625000||2625000||infinite||12.500%
|-
|52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%
|-
|105000||1||50.00||2011||5250000||2625000||7875000||50.00%||37.500%
|-
|157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%
|-
|210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%
|-
|262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%
|-
|315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%
|-
|367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%
|-
|420000||3||12.50||2017||15750000||656250||16406250||4.17%||78.125%
|-
|472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%
|-
|525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%
|-
|577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%
|-
|630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%
|-
|682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%
|-
|735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%
|-
|787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%
|}

==Projected Bitcoins Long Term ==

{| class="wikitable"
|-
! Block!!Reward Era!! BTC/block!! Year!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit
|-
| 0|| 1|| 50.00000000||2009.007|| 0.00000000|| 10500000.00000000|| 10500000.00000000|| infinite|| 50.00000006%
|-
| 210000|| 2|| 25.00000000||2013.000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%
|-
| 420000|| 3|| 12.50000000||2016.993|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%
|-
| 630000|| 4|| 6.25000000||2020.986|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%
|-
| 840000|| 5|| 3.12500000||2024.978|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%
|-
| 1050000|| 6|| 1.56250000||2028.971|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%
|-
| 1260000|| 7|| 0.78125000||2032.964|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%
|-
| 1470000|| 8|| 0.39062500||2036.956|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%
|-
| 1680000|| 9|| 0.19531250||2040.949|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%
|-
| 1890000|| 10|| 0.09765625||2044.942|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%
|-
| 2100000|| 11|| 0.04882812||2048.934|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%
|-
| 2310000|| 12|| 0.02441406||2052.927|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%
|-
| 2520000|| 13|| 0.01220703||2056.920|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%
|-
| 2730000|| 14|| 0.00610351||2060.913|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%
|-
| 2940000|| 15|| 0.00305175||2064.905|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%
|-
| 3150000|| 16|| 0.00152587||2068.898|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%
|-
| 3360000|| 17|| 0.00076293||2072.891|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%
|-
| 3570000|| 18|| 0.00038146||2076.883|| 20999839.77420000|| 80.10660000|| 20999919.88080001|| 0.00038146%|| 99.99961859%
|-
| 3780000|| 19|| 0.00019073||2080.876|| 20999919.88080001|| 40.05330000|| 20999959.93410001|| 0.00019073%|| 99.99980932%
|-
| 3990000|| 20|| 0.00009536||2084.869|| 20999959.93410001|| 20.02560000|| 20999979.95970001|| 0.00009536%|| 99.99990468%
|-
| 4200000|| 21|| 0.00004768||2088.861|| 20999979.95970001|| 10.01280000|| 20999989.97250001|| 0.00004768%|| 99.99995236%
|-
| 4410000|| 22|| 0.00002384||2092.854|| 20999989.97250001|| 5.00640000|| 20999994.97890001|| 0.00002384%|| 99.99997620%
|-
| 4620000|| 23|| 0.00001192||2096.847|| 20999994.97890001|| 2.50320000|| 20999997.48210001|| 0.00001192%|| 99.99998812%
|-
| 4830000|| 24|| 0.00000596||2100.840|| 20999997.48210001|| 1.25160000|| 20999998.73370001|| 0.00000596%|| 99.99999408%
|-
| 5040000|| 25|| 0.00000298||2104.832|| 20999998.73370001|| 0.62580000|| 20999999.35950001|| 0.00000298%|| 99.99999706%
|-
| 5250000|| 26|| 0.00000149||2108.825|| 20999999.35950001|| 0.31290000|| 20999999.67240001|| 0.00000149%|| 99.99999855%
|-
| 5460000|| 27|| 0.00000074||2112.818|| 20999999.67240001|| 0.15540000|| 20999999.82780001|| 0.00000074%|| 99.99999929%
|-
| 5670000|| 28|| 0.00000037||2116.810|| 20999999.82780001|| 0.07770000|| 20999999.90550001|| 0.00000037%|| 99.99999966%
|-
| 5880000|| 29|| 0.00000018||2120.803|| 20999999.90550001|| 0.03780000|| 20999999.94330001|| 0.00000018%|| 99.99999984%
|-
| 6090000|| 30|| 0.00000009||2124.796|| 20999999.94330001|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%
|-
| 6300000|| 31|| 0.00000004||2128.788|| 20999999.96220000|| 0.00840000|| 20999999.97060001|| 0.00000004%|| 99.99999997%
|-
| 6510000|| 32|| 0.00000002||2132.781|| 20999999.97060001|| 0.00420000|| 20999999.97480001|| 0.00000002%|| 99.99999999%
|-
| 6720000|| 33|| 0.00000001||2136.774|| 20999999.97480001|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%
|-
| 6930000|| 34|| 0.00000000||2140.767|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%
|}
==Money Supply==

While the number of bitcoins in existence will never exceed 21 million, the [http://en.wikipedia.org/wiki/Money_supply money supply] of bitcoins can exceed 21 million due to [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional-reserve Banking]. 

==Deflation==

Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used.
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [http://en.wikipedia.org/wiki/Austrian_School Austrian school] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding — hence savings — which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.

==See also==

* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually
* [[Deflationary spiral]]
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]
==References==
<references />

[[Category:Economics]]

Satoshi Client Node Discovery

2013-07-04T00:03:00Z

Wyager: /* Address Relay */

==Overview==

The Satoshi client discovers the IP address and port of nodes in several different ways.

# Nodes discover their own external address by various methods.
# Nodes receive the callback address of remote nodes that connect to them.
# Nodes makes DNS request to receive IP addresses.
# Nodes can use addresses hard coded into the software.
# Nodes exchange addresses with other nodes.
# Nodes store addresses in a database and read that database on startup.
# Nodes can be provided addresses as command line arguments
# Nodes read addresses from a user provided text file on startup

A timestamp is kept for each address to keep track of when the node
address was last seen. The AddressCurrentlyConnected in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] handles
updating the timestamp whenever a message is received from a node.
Timestamps are only updated on an address and saved to the database
when the timestamp is over 20 minutes old.

See the Node Connectivity article for information on which type of
addresses take precedence when actually connecting to nodes.

In the first section we will cover how a node handles a request for
addresses via the "getaddr" message. By understanding the role of
timestamps, it will become more clear why timestamps are kept the way
they are for each of the different ways an address is discovered.

==Handling Message "getaddr"==

When a node receives a "getaddr" request, it first figures out how many
addresses it has that have a timestamp in the last 3 hours.
Then it sends those addresses, but if there are more than 2500 addresses
seen in the last 3 hours, it selects around 2500 out of the available
recent addresses by using random selection.

Now lets look at the ways a node finds out about node addresses.

==Discovery Methods==

===Local Client's External Address===
The client uses public web services which return the information to determine its own external, routable IP address.

The client runs a thread called ThreadGetMyExternalIP (in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp])
which attempts to determine the client's IP address as seen from the outside
world.

First, it attempts to connect to 91.198.22.70 port 80, which should be
the checkip.dyndns.org server. If connection fails, a DNS request is made
for checkip.dyndns.org and a connection is attempted to that address.
Next, it attempts to connect to 74.208.43.192 port 80, which should be
the www.showmyip.com server. If connection fails, a DNS request is made
for www.showmyip.com and a connection is attempted to that address.

For each address attempted above, the client attempts to connect,
send a HTTP request, read the appropriate response line, and parse the
IP address from it.
If this succeeds, the IP address is returned, it is advertised to any connected
nodes, and then the thread finishes (without proceeding to the next
address).

===Connect Callback Address===
When a node receives an initial "version" message, and that node initiated the connection, then the node advertises its address to the remote so that it can connect back to the local node if it wants to.

After sending its own address, it sends a "getaddr" request message to the remote node to learn about more addresses, if the remote node version is recent or if the local node does not yet have 1000 addresses.

===IRC Addresses===

As of version 0.6.x the Bitcoin client no longer uses IRC bootstrapping by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. This documentation below is accurate for most prior versions.

In addition to learning and sharing its own address, the node learned about other node addresses via an IRC channel. See [https://github.com/bitcoin/bitcoin/blob/847593228de8634bf6ef5933a474c7e63be59146/src/irc.cpp irc.cpp].

After learning its own address, a node encoded its own address into a string to be used as a nickname. Then, it randomly joined an IRC channel named between #bitcoin00 and #bitcoin99. Then it issued a WHO command. The thread read the lines as they appeared in the channel and decoded the IP addresses of other nodes in the channel. It did this in a loop, forever, until the node was shutdown.

When the client discovered an address from IRC, it set the timestamp on the address to the current time, but it used a "penalty" of 51 minutes, which means it looked like it was actually seen almost an hour earlier.

===DNS Addresses===
Upon startup, if peer node discovery is needed, the client then issues DNS requests to learn about the addresses of other peer nodes. The client includes a list of host names for DNS services that are seeded. As-of May 17, 2012 the list (from chainparams.cpp<ref>[https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L139 bitcoin/src/chainparams.cpp at master]</ref>) includes:

* bitseed.xf2.org
* dnsseed.bluematt.me
* seed.bitcoin.sipa.be
* dnsseed.bitcoin.dashjr.org

A DNS reply can contain multiple IP addresses for a requested name.

Addresses discovered via DNS are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

===Hard Coded "Seed" Addresses===
The client contains hard coded IP addresses that represent bitcoin nodes.

These addresses are only used as a last resort, if no other method has produced any addresses at all. When the loop in the connection handling thread ThreadOpenConnections2() sees an empty address map, it uses the "seed" IP addresses as backup.

There is code is move away from seed nodes when possible. The presumption is that this is to avoid overloading those nodes. Once the local node has enough addresses (presumably learned from the seed nodes), the connection thread will close seed node connections.

Seed Addresses are initially given a zero timestamp,
therefore they are not advertised in response to a "getaddr" request.

===Ongoing "addr" advertisements===
Nodes may receive addresses in an "addr" message after having sent a "getaddr" request, or "addr" messages may arrive unsolicited, because nodes advertise addresses gratuitously when they relay addresses (see below), when they advertise their own address periodically, and when a connection is made.

If the address is from a really old version, it is ignored; if from a not-so-old version, it is ignored if we have 1000 addresses already.

If the sender sent over 1000 addresses, they are all ignored.

Addresses received from an "addr" message have a timestamp, but the timestamp is not necessarily honored directly.

For every address in the message:
# If the timestamp is too low or too high, it is set to 5 days ago.
# We subtract 2 hours from the timestamp and add the address.

Note that when any address is added, for any reason, the code that calls AddAddress() does not check to see if it already exists. The AddAddresss() function in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] will do that, and if the address already exists, further processing is done to update the address record. If the advertised services of the address have changed, that is updated and stored.

If the address has been seen in the last 24 hours and the timestamp is currently over 60 minutes old, then it is updated to 60 minutes ago.

If the address has NOT been seen in the last 24 hours, and the timestamp is currently over 24 hours old, then it is updated to 24 hours ago.

====Address Relay====

Once addresses are added from an "addr" message (see above), they then may be relayed to the other nodes. First, the following criteria must be set [9]:

#The address timestamp, after processing, is within 60 minutes of the current time
#The "addr" message contains 10 addresses or less
#And fGetAddr is not set on the node. fGetAddr starts false, is set to true when we request addresses from a node, and it is cleared when we receive less than 1000 addresses from a node.
#The address must be routable.

For every address that meets the above criteria, the node hash the address, the current day (in the form of an integer), and a random 256 bit value (generated at client startup). The node takes the two addresses with the lowest hash values and relays "addr" messages to them. This ensures that each node only relays "addr" messages to two other clients at any given time, that the two other clients are randomly selected, and that the random selection starts over at least once every 24 hours.

====Self broadcast====

Every 24 hours, the node advertises its own address to all connected nodes.

It also clears the list of the addresses we think the remote node has, which will trigger a refresh of sends to nodes. This code is in SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp].

====Old Address Cleanup====

In SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp], there is code to remove old addresses.

This is done every ten minutes, as long as there are 3 active connections.

The node erases messages that have not been used in 14 days as long as there are at least 1000 addresses in the map, and as long as the erasing process has not taken more than 20 seconds.

===Addresses stored in the Database===
Addresses are stored in the database when AddAddress() is called.

Addresses are read on startup when AppInit2() calls LoadAddresses(), which is located in [https://github.com/bitcoin/bitcoin/blob/master/src/db.cpp db.cpp].

Currently, it appears all addresses are stored all at once whenever any address is stored or updated<ref>[http://bitcointalk.org/index.php?topic=26436.0 Lots of disk activity on Bitcoin startup: easy fix?]</ref>. Indeed, AddAddress is seen to take over .01 seconds in various testing and is typically called tens of thousands of times in the initial 12 hours of running the client.

===Command Line Provided Addresses===

The user can specify nodes to connect to with the
-addnode <ip>
command line argument. Multiple nodes may be specified.

Addresses provided on the command line are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

The user can also specify an address to connect to with the -connect <ip>
command line argument. Multiple nodes may be specified.

The -connect argument differs from -addnode in that -connect addresses are not added to the address database and when -connect is specified, only those addresses are used.

===Text File Provided Addresses===

The client will automatically read a file named "addr.txt" in the bitcoin data directory and will add any addresses it finds in there as node addresses. These nodes are given no special preference over other addresses. They are just added to the pool.

Addresses loaded from the text file are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

==See Also==

* [[Network#Bootstrapping|Network - Boostrapping]]

==References==
<references />

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

Satoshi Client Node Discovery

2013-07-04T00:02:16Z

Wyager:

==Overview==

The Satoshi client discovers the IP address and port of nodes in several different ways.

# Nodes discover their own external address by various methods.
# Nodes receive the callback address of remote nodes that connect to them.
# Nodes makes DNS request to receive IP addresses.
# Nodes can use addresses hard coded into the software.
# Nodes exchange addresses with other nodes.
# Nodes store addresses in a database and read that database on startup.
# Nodes can be provided addresses as command line arguments
# Nodes read addresses from a user provided text file on startup

A timestamp is kept for each address to keep track of when the node
address was last seen. The AddressCurrentlyConnected in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] handles
updating the timestamp whenever a message is received from a node.
Timestamps are only updated on an address and saved to the database
when the timestamp is over 20 minutes old.

See the Node Connectivity article for information on which type of
addresses take precedence when actually connecting to nodes.

In the first section we will cover how a node handles a request for
addresses via the "getaddr" message. By understanding the role of
timestamps, it will become more clear why timestamps are kept the way
they are for each of the different ways an address is discovered.

==Handling Message "getaddr"==

When a node receives a "getaddr" request, it first figures out how many
addresses it has that have a timestamp in the last 3 hours.
Then it sends those addresses, but if there are more than 2500 addresses
seen in the last 3 hours, it selects around 2500 out of the available
recent addresses by using random selection.

Now lets look at the ways a node finds out about node addresses.

==Discovery Methods==

===Local Client's External Address===
The client uses public web services which return the information to determine its own external, routable IP address.

The client runs a thread called ThreadGetMyExternalIP (in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp])
which attempts to determine the client's IP address as seen from the outside
world.

First, it attempts to connect to 91.198.22.70 port 80, which should be
the checkip.dyndns.org server. If connection fails, a DNS request is made
for checkip.dyndns.org and a connection is attempted to that address.
Next, it attempts to connect to 74.208.43.192 port 80, which should be
the www.showmyip.com server. If connection fails, a DNS request is made
for www.showmyip.com and a connection is attempted to that address.

For each address attempted above, the client attempts to connect,
send a HTTP request, read the appropriate response line, and parse the
IP address from it.
If this succeeds, the IP address is returned, it is advertised to any connected
nodes, and then the thread finishes (without proceeding to the next
address).

===Connect Callback Address===
When a node receives an initial "version" message, and that node initiated the connection, then the node advertises its address to the remote so that it can connect back to the local node if it wants to.

After sending its own address, it sends a "getaddr" request message to the remote node to learn about more addresses, if the remote node version is recent or if the local node does not yet have 1000 addresses.

===IRC Addresses===

As of version 0.6.x the Bitcoin client no longer uses IRC bootstrapping by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. This documentation below is accurate for most prior versions.

In addition to learning and sharing its own address, the node learned about other node addresses via an IRC channel. See [https://github.com/bitcoin/bitcoin/blob/847593228de8634bf6ef5933a474c7e63be59146/src/irc.cpp irc.cpp].

After learning its own address, a node encoded its own address into a string to be used as a nickname. Then, it randomly joined an IRC channel named between #bitcoin00 and #bitcoin99. Then it issued a WHO command. The thread read the lines as they appeared in the channel and decoded the IP addresses of other nodes in the channel. It did this in a loop, forever, until the node was shutdown.

When the client discovered an address from IRC, it set the timestamp on the address to the current time, but it used a "penalty" of 51 minutes, which means it looked like it was actually seen almost an hour earlier.

===DNS Addresses===
Upon startup, if peer node discovery is needed, the client then issues DNS requests to learn about the addresses of other peer nodes. The client includes a list of host names for DNS services that are seeded. As-of May 17, 2012 the list (from chainparams.cpp<ref>[https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L139 bitcoin/src/chainparams.cpp at master]</ref>) includes:

* bitseed.xf2.org
* dnsseed.bluematt.me
* seed.bitcoin.sipa.be
* dnsseed.bitcoin.dashjr.org

A DNS reply can contain multiple IP addresses for a requested name.

Addresses discovered via DNS are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

===Hard Coded "Seed" Addresses===
The client contains hard coded IP addresses that represent bitcoin nodes.

These addresses are only used as a last resort, if no other method has produced any addresses at all. When the loop in the connection handling thread ThreadOpenConnections2() sees an empty address map, it uses the "seed" IP addresses as backup.

There is code is move away from seed nodes when possible. The presumption is that this is to avoid overloading those nodes. Once the local node has enough addresses (presumably learned from the seed nodes), the connection thread will close seed node connections.

Seed Addresses are initially given a zero timestamp,
therefore they are not advertised in response to a "getaddr" request.

===Ongoing "addr" advertisements===
Nodes may receive addresses in an "addr" message after having sent a "getaddr" request, or "addr" messages may arrive unsolicited, because nodes advertise addresses gratuitously when they relay addresses (see below), when they advertise their own address periodically, and when a connection is made.

If the address is from a really old version, it is ignored; if from a not-so-old version, it is ignored if we have 1000 addresses already.

If the sender sent over 1000 addresses, they are all ignored.

Addresses received from an "addr" message have a timestamp, but the timestamp is not necessarily honored directly.

For every address in the message:
# If the timestamp is too low or too high, it is set to 5 days ago.
# We subtract 2 hours from the timestamp and add the address.

Note that when any address is added, for any reason, the code that calls AddAddress() does not check to see if it already exists. The AddAddresss() function in [https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp net.cpp] will do that, and if the address already exists, further processing is done to update the address record. If the advertised services of the address have changed, that is updated and stored.

If the address has been seen in the last 24 hours and the timestamp is currently over 60 minutes old, then it is updated to 60 minutes ago.

If the address has NOT been seen in the last 24 hours, and the timestamp is currently over 24 hours old, then it is updated to 24 hours ago.

====Address Relay====

Once addresses are added from an "addr" message (see above), they then may be relayed to the other nodes. First, the following criteria must be set [9]:

#The address timestamp, after processing, is within 60 minutes of the current time
#The "addr" message contains 10 addresses or less
#And fGetAddr is not set on the node. fGetAddr starts false, is set to true when we request addresses from a node, and it is cleared when we receive less than 1000 addresses from a node.
#The address must be routable.

For every address that meets the above criteria, the node hash the address, the current day (in the form of an integer), and a random 256 bit value (generated at client startup). The node takes the two addresses with the lowest hash values and relays "addr" messages to them. This ensures that each node only relays "addr" messages to two other clients, that the two other clients are randomly selected, and that the random selection starts over at least once every 24 hours.

====Self broadcast====

Every 24 hours, the node advertises its own address to all connected nodes.

It also clears the list of the addresses we think the remote node has, which will trigger a refresh of sends to nodes. This code is in SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp].

====Old Address Cleanup====

In SendMessages() in [https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp main.cpp], there is code to remove old addresses.

This is done every ten minutes, as long as there are 3 active connections.

The node erases messages that have not been used in 14 days as long as there are at least 1000 addresses in the map, and as long as the erasing process has not taken more than 20 seconds.

===Addresses stored in the Database===
Addresses are stored in the database when AddAddress() is called.

Addresses are read on startup when AppInit2() calls LoadAddresses(), which is located in [https://github.com/bitcoin/bitcoin/blob/master/src/db.cpp db.cpp].

Currently, it appears all addresses are stored all at once whenever any address is stored or updated<ref>[http://bitcointalk.org/index.php?topic=26436.0 Lots of disk activity on Bitcoin startup: easy fix?]</ref>. Indeed, AddAddress is seen to take over .01 seconds in various testing and is typically called tens of thousands of times in the initial 12 hours of running the client.

===Command Line Provided Addresses===

The user can specify nodes to connect to with the
-addnode <ip>
command line argument. Multiple nodes may be specified.

Addresses provided on the command line are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

The user can also specify an address to connect to with the -connect <ip>
command line argument. Multiple nodes may be specified.

The -connect argument differs from -addnode in that -connect addresses are not added to the address database and when -connect is specified, only those addresses are used.

===Text File Provided Addresses===

The client will automatically read a file named "addr.txt" in the bitcoin data directory and will add any addresses it finds in there as node addresses. These nodes are given no special preference over other addresses. They are just added to the pool.

Addresses loaded from the text file are initially given a zero timestamp, therefore they are not advertised in response to a "getaddr" request.

==See Also==

* [[Network#Bootstrapping|Network - Boostrapping]]

==References==
<references />

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