https://en.bitcoin.it/w/api.php?action=feedcontributions&feedformat=atom&user=Wickrick22 2026-04-29T03:38:29Z User contributions MediaWiki 1.43.8 https://en.bitcoin.it/w/index.php?title=Bitcoind&diff=17231 2011-09-24T04:26:44Z

<p>Wickrick22: </p> <hr /> <div>[[Image:Bitcoin Original Client.png|thumb|350px|right|The bitcoin original client]]<br /> <br /> The '''Original Bitcoin client''' is the first [[bitcoin]] client in the network's history. It is also the official client of the bitcoin project. It's available under the [http://www.opensource.org/licenses/mit-license.php MIT license] for Windows, 32 and 64-bit GNU/Linux-based OSes and Mac OS X.<br /> <br /> The client comes with two executables, a GUI and an command line interface (CLI).<br /> <br /> == Executables ==<br /> See [[Running_Bitcoin|running bitcoin]] for more detail and an example of the configuration file.<br /> === Bitcoin (GUI) ===<br /> <br /> The bitcoin GUI provides an easy to use wxWidgets-based interface. It allows to send coins and to monitor:<br /> * transactions from and to the opened wallet<br /> * block creations<br /> * confirmations of transactions<br /> * balance of the wallet<br /> <br /> === Bitcoind (CLI) ===<br /> <br /> Bitcoind is both a headless daemon and a client for the same daemon. It also provides a JSON-RPC interface, allowing it to be controlled locally (via bitcoind or another CLI client) or remotely. [[Original Bitcoin client/API Calls list|Various commands]] are made available by the API.<br /> <br /> To use locally, first start the program in daemon mode:<br /> :bitcoind -daemon<br /> <br /> <br /> Then you can use the same program to execute [[Original Bitcoin client/API Calls list|API commands]], e.g.:<br /> :bitcoind listreceivedbyaddress 0 true<br /> :bitcoind getbalance<br /> <br /> To stop the bitcoin daemon, execute:<br /> :bitcoind stop<br /> <br /> ==History==<br /> <br /> * Version 0.3.24 was released for all supported platforms on July 8th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=27187.0 Bitcoin version 0.3.24 released]&lt;/ref&gt;.<br /> * Version 0.3.23 was released for all supported platforms on June 13th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=16553.0 Bitcoin version 0.3.23 released]&lt;/ref&gt;.<br /> * Version 0.3.22 was released for all supported platforms on May 19th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=8894.0 Version 0.3.22]&lt;/ref&gt;.<br /> * Version 0.3.20 was released for all supported platforms on February 21st, 2011&lt;ref&gt;[http://www.bitcoin.org/smf/index.php?topic=3704.0 Version 0.3.20]&lt;/ref&gt;.<br /> <br /> <br /> <br /> ==Theory of Operation==<br /> <br /> Satoshi's Original Bitcoin client is a multithreaded C++ program. It is designed to be portable across Windows, Mac, and Linux systems. The multithreaded aspect leads to some complexity and the use of certain code patterns to deal with concurrency that may be unfamiliar to many programmers. Also, the code is aggressive in the use of C++ constructs, so it will help to be fluent with map, multmap, set, string, vector, iostream, and templates. As typical of a C++ program, l a lot of code tends to end up in the header files so be sure to search both the .cpp and .h files when looking for a function.<br /> <br /> The client is oriented around several major operations, which are described in separate detailed articles and summarized in the following sections.<br /> <br /> <br /> ===[[Satoshi Client Initialization and Startup|Initialization and Startup]]===<br /> Upon startup, the client performs various initilization routines including starting multiple threads to handle concurrent operations.<br /> <br /> ===[[Satoshi Client Node Discovery|Node Discovery]]===<br /> The client uses various techniques find out about other bitcoin nodes that may exist.<br /> <br /> ===[[Satoshi Client Node Connectivity|Node Connectivity]]===<br /> The client initiates and maintains connections to other nodes.<br /> <br /> ===[[Satoshi Client Sockets and Messages|Sockets and Messages]]===<br /> The client processes messages from other nodes and sends messages to other nodes using socket connections.<br /> <br /> ===[[Satoshi Client Block Exchange|Block Exchange]]===<br /> Nodes advertise their inventory of blocks to each other and exchange blocks to build block chains.<br /> <br /> ===[[Satoshi Client Transaction Exchange|Transaction Exchange]]===<br /> Nodes exchange and relay transactions with each other. The client associates transactions with bitcoin addresses in the local wallet.<br /> <br /> ===Wallet Services===<br /> The client can create transactions using the local wallet. The client associates transactions with bitcoin addresses in the local wallet. The client provides a service for managing the local wallet.<br /> <br /> ===RPC Interface===<br /> The client offers an JSON-RPC interface over HTTP over sockets to perform various operational functions and to manage the local wallet.<br /> <br /> ===User Interface===<br /> The user interface code is currently based on [http://www.wxwidgets.org wxWidgets] and is scheduled to be superseded by [[Bitcoin-qt]] in version 0.5.0. <br /> <br /> ==See Also==<br /> <br /> * [[Original Bitcoin client/API calls list]]<br /> * [[Protocol specification|Bitcoin network protocol]]<br /> * [[Development process]]<br /> * [[Changelog]]<br /> <br /> ==External Links==<br /> * [http://sourceforge.net/projects/bitcoin/ Bitcoin Client project on SourceForge]<br /> * [https://github.com/bitcoin/bitcoin/ Bitcoin Client project on Github]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Category:Nodes]]<br /> [[Category:Wallets]]<br /> [[Category:User Interfaces]]<br /> [[Category:Clients]]<br /> [[Category:Developer]]<br /> [[Category:Technical]]<br /> [[Category:Free Software]]<br /> [[Category:License/MIT-X11]]<br /> [[Category:Open Source]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Transaction_Exchange&diff=17230 2011-09-24T04:16:51Z

<p>Wickrick22: Initial content</p> <hr /> <div>==Overview==<br /> <br /> The Satoshi client advertises locally generated transactions and relays<br /> transactions from other nodes. This article describes the operations<br /> that deal with this exchange of transactions.<br /> <br /> See this article for more information on how transactions are validated:<br /> [https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages Protocol Rules]<br /> <br /> <br /> == Wallet Send ==<br /> <br /> The client periodically calls SendMessages() (in main.cpp) which calls<br /> ResendWalletTransactions to send transactions generated locallly.<br /> This routine looks to see if there has been a new block since last time,<br /> and if so, and the local transaction are still not in a block,<br /> then the transactions are sent to all nodes.<br /> This is done only about every 30 minutes.<br /> <br /> Transactions are only rebroadcast if they have a timestamp at least<br /> 5 minutes older than the last block was received. They are sorted<br /> and sent oldest first.[1]<br /> <br /> <br /> == Periodic Advertisement ==<br /> <br /> The client periodically calls SendMessages() (in main.cpp) which<br /> determines if a message should be sent to a remote node.<br /> For each message processing iteration, one node is chosen as the<br /> &quot;trickle node&quot;.[2] This node is the only one chosen to receive<br /> an &quot;addr&quot; message, if appropriate.[3]<br /> <br /> In the section for inventory, the client sends 1/4 of the transaction<br /> inventory, determined randomly [4], UNLESS they are the trickle node,<br /> in which case they receive ALL transactions.[5] Yes that seems reversed,<br /> but it is what it is. If the node is to receive 1/4 (not all), then the<br /> code also avoids sending any transactions that came from the local<br /> wallet.[6] The comments indicate this is intended to increase privacy.<br /> <br /> <br /> <br /> == Relay ==<br /> <br /> When the client receives a transaction via a &quot;tx&quot; messages,<br /> it calls RelayMessage, which calls RelayInventory, which queues the<br /> inventory to be sent to all other nodes.[7]<br /> <br /> <br /> <br /> ==Footnotes==<br /> <br /> 1. See CWallet::ResendWalletTransactions in wallet.cpp.<br /> <br /> 2. See:<br /> pnodeTrickle = vNodesCopy[GetRand(vNodesCopy.size())];<br /> and<br /> SendMessages(pnode, pnode == pnodeTrickle);<br /> in ThreadMessageHandler2() in net.cpp.<br /> <br /> 3. See:<br /> //<br /> // Message: addr<br /> //<br /> if (fSendTrickle)<br /> { <br /> in SendMessages() in main.cpp.<br /> <br /> 4. See:<br /> bool fTrickleWait = ((hashRand &amp; 3) != 0);<br /> in SendMessages() in main.cpp.<br /> <br /> 5. See:<br /> // trickle out tx inv to protect privacy<br /> if (inv.type == MSG_TX &amp;&amp; !fSendTrickle)<br /> { <br /> in SendMessages() in main.cpp.<br /> <br /> 6. See:<br /> // always trickle our own transactions<br /> if (!fTrickleWait)<br /> { <br /> CWalletTx wtx;<br /> if (GetTransaction(inv.hash, wtx))<br /> if (wtx.fFromMe)<br /> fTrickleWait = true;<br /> }<br /> in SendMessages() in main.cpp.<br /> <br /> 7. Both RelayMessage and RelayInventory in net.h.<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Block_Exchange&diff=17118 2011-09-22T02:53:54Z

<p>Wickrick22: initial content</p> <hr /> <div>==Overview==<br /> This article describes how blocks are exchanged between nodes.<br /> See this article for more information on how blocks are validated:<br /> https://en.bitcoin.it/wiki/Protocol_rules#Blocks<br /> <br /> Upon initial connection, if the connection was not inbound[1],<br /> or in other words, if the connection was initiated by the local node,<br /> the version message is queued for sending immediately. When the remote node<br /> receives the version message it replies with its own version message.[2]<br /> <br /> When a node receives a &quot;version&quot; message, it may send a &quot;getblocks&quot; request<br /> to the remote node if EITHER:<br /> <br /> # The node has never sent an initial getblocks request to any node yet.<br /> # Or, this is the only active node connection. Presumably the node had zero connections prior to this connection, so maybe it was disconnected for a long time. So, it will ask for blocks to catch up.<br /> <br /> The getblocks message contains multiple block hashes that the requesting<br /> node already possesses, in order to help the remote note find the latest<br /> common block between the nodes. The list of hashes starts with the latest<br /> block and goes back ten and then doubles in an exponential progression<br /> until the genesis block is reached.[3] Since both nodes are hard coded<br /> with the genesis block, they are guaranteed to a least start there.<br /> If that block does not match for some reason, no blocks are exchanged.<br /> <br /> <br /> == Inventory Messages ==<br /> <br /> Note that the node receiving the getblocks request does not actually send<br /> full blocks in response. The node sends an &quot;inv&quot; message containing just<br /> the hashes of the series of blocks that fit the request, which verifies<br /> that the node does indeed have blocks to send that the remote node does<br /> not have (but does not presume the remote node wants the full blocks yet).<br /> <br /> When the local node receives the &quot;inv&quot; message, it will request the actual<br /> blocks with a &quot;getdata&quot; message. See Below.<br /> <br /> But first, here is more detail how the remote node sends the &quot;inv&quot; message<br /> in response to the &quot;getblocks&quot; request sent by the local node. The remote<br /> node calls pFrom-&gt;PushInventory which is a method on the CNode instance that<br /> represents the node that requested the blocks (the local node in this<br /> walkthrough), and PushInventory adds the block hash to the vInventoryToSend<br /> variable of the CNode. The SendMessages function in main.cpp will take the<br /> inv items out of vInventoryToSend and add it to a vInv variable which<br /> means they are really ready for sending.[4]<br /> The reason for the seperate variable is that some inventory items<br /> (transactions only right now) may be &quot;trickled&quot; to the remote node,<br /> which means they may kept from from being sent right away.<br /> When the vInv variable fills up with 1000 entries, a message is queued<br /> with those 1000 entries and the loop continues. At the end, any<br /> remaining entries are sent in a final &quot;inv&quot; message.<br /> <br /> When the local node receives the &quot;inv&quot; message, it will request the actual<br /> block with a &quot;getdata&quot; message. To be precise, the node calls pfrom-&gt;AskFor<br /> to request the block, and that method queues the request for the blocks in<br /> mapAskFor, and the multipurpose SendMessage() sends the &quot;getdata&quot; requests<br /> in batches of 1000 entries from the map.[5]<br /> <br /> The code attempts to limit redundant requests to every 2 minutes for the<br /> same block by using a map called mapAlreadyAskedFor to delay the message<br /> if necessary.[6]<br /> <br /> <br /> == Block Batching ==<br /> <br /> The responding node to a &quot;getblocks&quot; request attempts to limit the response<br /> to the requestor to 500 blocks.[7]<br /> <br /> However, in a peculiar twist, if the requestor appears to have diverged<br /> from the main branch, the node will send as many blocks as necessary to<br /> replace the entire bad chain of the requestor, from the lastest common block<br /> between the nodes, up to the last block the requestor has (on their bad main<br /> branch). That is in addition to the 500 &quot;catch up&quot; blocks for main branch<br /> updates that will also be sent.[8]<br /> <br /> Note that in addition to a flat limit on the number of blocks queued for<br /> sending, bitcoind also limits the total size of the blocks that are being<br /> queued. This is currently limited to half the send buffer size[9], which is<br /> 10MB, for a limit of 5MB of queued blocks for send.[10]<br /> <br /> == Batch Continue Mechanism ==<br /> <br /> When a node is finished sending a batch of block inventory, it records the<br /> hash of the last block in the batch.[11] When the node receives a request<br /> for that full block, it realizes the remove node is done with the current<br /> batch and directly queues a special &quot;inv&quot; message (bypassing the normal<br /> SendMessage mechanism) with one block hash entry containing the<br /> latest block hash.[12] When the remote node receives that &quot;inv&quot; message,<br /> it will see that it does not have that block and it it will ask for that<br /> block as described above. However, this time when it receives the block<br /> and processes it, it will notice that it does not have the previous block,<br /> so it will record the latest block as an &quot;orphan&quot; block, and will request a<br /> block update starting with the latest block it has up to the block before<br /> the orphan [13], in order to fill in the gap. That goes out as a &quot;getblocks&quot;<br /> request and the whole batch process repeats itself.<br /> <br /> However, there is a twist. When the next batch finishes, the remote node<br /> sending the blocks will send the &quot;inv&quot; with latest block hash as usual, and<br /> the local node will notice it already has this block in the orphan block<br /> map this time and so it will skip requesting the block and directly ask<br /> for a block update.[14] This process will continue until the last<br /> block prior to the latest block is received. At the end of processing <br /> that block, it will notice there is an orphan that pointed to this block<br /> and will process the orphan block, (and any other orphans, recursively)<br /> thus completing the entire process.[15]<br /> <br /> <br /> == Stall Recovery ==<br /> <br /> If the batching processes is interrupted for some reason, such as the<br /> remote node failing to honor the &quot;Batch Continue Mechanism&quot; or if a <br /> disconnection occurs, there is a way for the process to restart. When<br /> a new block is solved and advertised around[16], any nodes that are<br /> behind will notice the new block in the &quot;inv&quot; and that will trigger it<br /> to request a &quot;getblocks&quot; update from the node that sent it the message.<br /> That will cause blocks to be sent starting from wherever in the block<br /> chain that the node that is behind is currently at.<br /> <br /> <br /> == Long Orphan Chains ==<br /> <br /> In various tests, it has proven relatively common (say more than one<br /> in ten) to discover nodes that are significantly behind on the block<br /> chain, probably because they are in the process of catching up as well.<br /> Since a well connected node will have at least 8 and up to dozens of<br /> connections, it is fairly likely that a new node will connect to<br /> another node that is also catching up.<br /> <br /> Nodes that are catching up will advertise the blocks they are processing,<br /> as they accept blocks into their main chain, to every other node.[16]<br /> While there is code to prevent advertising old blocks before a certain<br /> checkpoint, that code also has a clause that does advertise blocks to<br /> remote nodes if the block height is over the remote node's current best<br /> height minus 2000 blocks.[17] This appears to allow nodes to &quot;help&quot; other<br /> nodes catch up, even if they are both processing old blocks.<br /> <br /> These advertisements cause the local node to request those blocks<br /> from the remote node, which could be blocks well into the future compared<br /> to what has been processed locally. Due to the way blocks are requested,<br /> the remote node will send a large batch of blocks in response and will<br /> continue sending blocks to the local node until it reaches the end.<br /> Note that this is likely to occur at the same time the local node is<br /> downloading earlier blocks on the main chain from another node. That<br /> process may eventually catch up with the orphan chain and produce a <br /> very, very long operation to revalidate and connect up all the orphan<br /> blocks. Orphan chains over ten thousand blocks long, taking over an hour<br /> to process are possible.<br /> <br /> Therefore, two nodes talking to each other that are both catching up can<br /> lead to suboptimal interactions, especially when one both are far behind<br /> and one is far ahead of the other.<br /> <br /> <br /> == Flood Limit Effects ==<br /> <br /> Even with the batching mechanism described above, there are scenarios<br /> that occur that result in the remote node overflowing the local receive<br /> buffer while blocks are being exchanged.<br /> <br /> For example, if a remote node is &quot;catching up&quot;, it will advertise each block<br /> it processes to the local node in certain circumstances (see above [17]).<br /> The local node will request each of those blocks right away. There is no<br /> protection against the local node requesting too many of these blocks.<br /> The remote node will send all blocks requested. There is no protection<br /> against the remote node sending too many blocks before the local node has<br /> time to process them, in this circumstance.<br /> <br /> The local receive buffer can fill up. When the local node notices a receive<br /> buffer is full, it disconnects that node connection.[18]<br /> If sets the fDisconnect flag, and once the buffers are empty[19], the<br /> socket is closed.<br /> <br /> <br /> == Performance ==<br /> <br /> As of September 1, 2011, on a server class computer circa 2005 running<br /> Ubuntu with a Comcast cable internet connection takes over 10 hours <br /> to download and process the block chain. While it is debatable what<br /> the bottleneck is early in the download process, it is clear from<br /> the processing of recent blocks that the network is not the bottleneck<br /> for all but the slowest internet connections.<br /> <br /> Blocks are taking over a second, on average, to process once downloaded.[20]<br /> However, the average size of a block is only around 24 kilobytes<br /> in August 2011. It certainly does not take 1 second to download 24K.<br /> Also, testing reveals very large queues of blocks being processed per<br /> message loop, which is not what you would expect if the thread was<br /> pulling them out of the queue as they arrive on the sockets. <br /> <br /> There are a number of &quot;false signals&quot; that lead one to believe the problem<br /> is with network performance. The first false signal is that, as of<br /> August 2011, nearly all of the first 60 or 70% of blocks downloaded are<br /> very small. Recent average block sizes are around one hundred times bigger!<br /> So, almost all of a sudden, the block rate goes from very fast to very slow.<br /> It looks like something went wrong. In reality, if you measure the rate<br /> of block processing by kilobyte, the rate remains relatively constant.<br /> <br /> <br /> Another false signal is related to the fact that message queues are<br /> processed to completion, one at a time per node. This can result in big<br /> backups of messages from other nodes. So, a long period of increasing<br /> blocks may freeze for long periods as other nodes are serviced. Consider<br /> that block downloads typically come from just one remote node (at<br /> least until a miner or other relaying or downloading node advertises<br /> a late block and disrupts the process) and so all the work might<br /> be on one node. Things go fast processing the blocks from a node,<br /> and then that looks like it stops as &quot;addr&quot; messages are processed from<br /> other nodes and other work is done. But it looks like something is wrong.<br /> <br /> Also, the orphaning effects described above can lead to excessive block<br /> processing with nothing to show for it until the orphan chain is connected.<br /> Also, you do ocassionally run into a node that is slow to respond, perhaps<br /> because they are also processing blocks or because they have a slow machine<br /> or connection.<br /> <br /> All of the above contributes to heavy &quot;jitter&quot; in the block download process,<br /> and that is a more frustrating user experience than a constant download rate.<br /> <br /> <br /> ==Footnotes==<br /> 1. See pfrom-&gt;fInbound where pfrom is a CNode.<br /> <br /> 2. See ProcessMessage() in main.cpp where strCommand == &quot;version&quot;.<br /> <br /> 3. See CBlockLocator in main.h.<br /> <br /> 4. See Message: inventory in SendMessage in main.cpp.<br /> <br /> 5. See Message: getdata at the end of SendMessage in main.cpp.<br /> <br /> 6. See CNode::AskFor in net.h.<br /> <br /> 7. See ProcessMessage() in main.cpp where strCommand ==&quot;getblocks&quot;.<br /> <br /> 8. See<br /> int nLimit = 500 + locator.GetDistanceBack();<br /> in ProcessMessage in main.cpp where strCommand ==&quot;getblocks&quot;.<br /> <br /> 9. See<br /> if (--nLimit &lt;= 0 || nBytes &gt;= SendBufferSize()/2)<br /> in ProcessMessage() in main.cpp where strCommand ==&quot;getblocks&quot;.<br /> <br /> 10. See<br /> inline unsigned int SendBufferSize() {<br /> return 1000*GetArg(&quot;-maxsendbuffer&quot;, 10*1000); }<br /> in net.h.<br /> <br /> 11. See pfrom-&gt;hashContinue = pindex-&gt;GetBlockHash();<br /> in ProcessMessage() in main.cpp where strCommand ==&quot;getblocks&quot;.<br /> 12. See: if (inv.hash == pfrom-&gt;hashContinue)<br /> in ProcessMessage() in main.cpp where strCommand ==&quot;getdata&quot;.<br /> <br /> 13. See:<br /> // Ask this guy to fill in what we're missing<br /> if (pfrom)<br /> pfrom-&gt;PushGetBlocks(pindexBest, GetOrphanRoot(pblock2));<br /> in ProcessBlock() in main.cpp.<br /> <br /> 14. See:<br /> else if (inv.type == MSG_BLOCK &amp;&amp; mapOrphanBlocks.count(inv.hash))<br /> pfrom-&gt;PushGetBlocks(pindexBest, GetOrphanRoot(mapOrphanBlocks[inv.hash]));<br /> in ProcessMessage() in main.cpp where strCommand ==&quot;inv&quot;.<br /> <br /> 15. See:<br /> // Recursively process any orphan blocks that depended on this one<br /> in ProcessBlock() in main.cpp.<br /> <br /> 16. See the last block of code in AcceptBlock in main.cpp.<br /> <br /> 17. See:<br /> if (nBestHeight &gt; (pnode-&gt;nStartingHeight != -1 ? pnode-&gt;nStartingHeight - 2000 : 134444))<br /> in AcceptBlock() in main.cpp.<br /> <br /> 18. See:<br /> if (nPos &gt; ReceiveBufferSize()) {<br /> in ThreadSocketHandler2() in net.cpp.<br /> <br /> 19. See:<br /> if (pnode-&gt;fDisconnect ||<br /> (pnode-&gt;GetRefCount() &lt;= 0 &amp;&amp; pnode-&gt;vRecv.empty() &amp;&amp; pnode-&gt;vSend.empty()))<br /> in ThreadSocketHandler2() in net.cpp.<br /> <br /> 20. This is from the authors experience and also<br /> see https://bitcointalk.org/index.php?topic=31376.0.<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Sockets_and_Messages&diff=17117 2011-09-22T02:43:06Z

<p>Wickrick22: </p> <hr /> <div>==Overview==<br /> The original bitcoin client uses a multithreaded approach to socket<br /> handling and messages processing. There is one thread that handles<br /> socket communication (ThreadSocketHandler) and one (ThreadMessageHandler)<br /> which handles pulling messages off sockets and calling the<br /> processing routines. Both of these threads are in net.cpp.<br /> The message processing routines are in main.cpp, however.<br /> <br /> ==Socket Thread==<br /> The socket thread reads the sockets and places data into a CDataStream<br /> associated with each node called vRecv. The Satoshi client uses C++<br /> serialization operators &gt;&gt; and &lt;&lt; to read and write to a CDataStream<br /> and then it uses generic routines to move the data between the streams<br /> and sockets.<br /> <br /> ==Message Thread==<br /> The message thread reads and processes all messages from each node in<br /> sequence, and then it sends messages to each node that should be sent<br /> messages. That is all it does.<br /> <br /> Specifically, ThreadMessageHandler2 calls ProcessMessages(), which is<br /> located in main.cpp, to pull messages off each node's socket and<br /> process them. Then it calls SendMessages(), which is also located<br /> in main.cpp to create and send any messages appropriate for each node.<br /> <br /> ProcessMessages() attempts to find a message start signature in the<br /> vRecv stream. If it finds a message start, it deletes everything<br /> prior to the start. Then it reads the header, extracts the message<br /> type, and calls ProcessMessage on the message.<br /> <br /> SendMessages() actually creates and sends messages; it does not<br /> just send preexisting queued messages. It goes through various<br /> maps looking for work to do and produces a message and calls<br /> PushMessage method of CNode to send the message. PushMessage<br /> queues outbound data in the vSend data stream. (See PushMessage() in<br /> net.cpp). The socket thread handler then pulls data off the<br /> vSend data stream and calls send on the socket to send the data.<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Connectivity&diff=16803 2011-09-17T22:42:40Z

<p>Wickrick22: formatting</p> <hr /> <div>==&lt;br/&gt;Overview==<br /> <br /> The Satoshi bitcoin client creates a thread to manage making<br /> connections to other nodes. The code for that thread is in a<br /> function called ThreadOpenConnections2 in net.cpp.<br /> <br /> The client also handles accepting new inbound connections and <br /> disconnecting nodes when appropriate in a a thread called<br /> ThreadSocketHandler2, which is also in net.cpp.<br /> <br /> The thread making connections does not discover the addresses of other<br /> nodes. That information is gathered in various ways (See the article<br /> on Node Discovery). The connection thread chooses among the available<br /> addresses and makes connections and disconnects nodes when appropriate.<br /> That is all it does.<br /> <br /> Node addresses are chosen based on the following set of rules.<br /> <br /> <br /> <br /> ==Connection Rules==<br /> <br /> ===Outbound Static Addresses===<br /> <br /> If the user specified addresses with -connect, the node uses <br /> those addresses only. It tries to establish a connection to each node<br /> and then sleeps for a half second, and then repeats that in a loop<br /> until shut down. The code establishes a connection by calling<br /> OpenNetworkConnection(addr). If the connection is already open,<br /> OpenNetworkConnection just returns.<br /> <br /> <br /> If the user specified addresses with -node, then connections are<br /> made to those nodes (with a half second delay between each) upon<br /> startup. After those connections are attempted, the code proceeds<br /> to the regular connection handling code.<br /> <br /> <br /> ===Outbound Limiting===<br /> <br /> The connection handling code is one loop that performs various functions until shutdown. The first thing the loop does is count<br /> the number of outbound connections, and if the maximum has been<br /> reached (8 or -maxconnections), then it goes into a 2 second delay<br /> loop until the count is below the max.<br /> <br /> Assuming the number of connections is below the limit, the node attempts<br /> to connect to another node. See the next section.<br /> <br /> <br /> ===Seed Nodes===<br /> <br /> If the node has not been able to learn about other addresses, presumably<br /> because those methods have failed, the node will use an internal list<br /> of 320 node addresses hard coded into the software to populate<br /> the list of known node addresses.<br /> <br /> There is code to move away from seed nodes when possible. The presumption<br /> is that this is to avoid overloading seed nodes. Once the local node has<br /> enough addresses (presumably learned from the seed nodes), the<br /> connection thread will close seed node connections.<br /> <br /> <br /> ===Outbound Random Selection===<br /> <br /> First the code puts the addresses into a.b.c.* buckets so only one<br /> connection is made to each 24 bit netmasked network.<br /> <br /> Next, it loops through every address and determines whether it is &quot;ready&quot;,<br /> and then, using a complex calculation, computes a score for every address.<br /> The address with the highest score wins and OpenNetworkConnection is<br /> called for it. Then the code completes the main loop of the thread and<br /> continues.<br /> <br /> In order to determine readiness, the code hashes the IP and other entropy<br /> into a deterministic random number between 1 and 3600. If the address<br /> specifies a nonstandard port, a 2 hour (7200) penalty is added to the number.<br /> This is an adjustment number to the retry interval.<br /> <br /> The main retry interval is basically the square root of the last time seen<br /> plus the &quot;random&quot; adjustment from the previous paragraph. If the node<br /> has been seen in the last hour, however, the retry interval is set to<br /> ten minutes. The following table is in the code:<br /> <br /> // Last seen Base retry frequency<br /> // &lt;1 hour 10 min<br /> // 1 hour 1 hour<br /> // 4 hours 2 hours<br /> // 24 hours 5 hours<br /> // 48 hours 7 hours<br /> // 7 days 13 hours<br /> // 30 days 27 hours<br /> // 90 days 46 hours<br /> // 365 days 93 hours<br /> <br /> After computing the interval, if the address has already been contacted in<br /> the interval, the address is skipped.<br /> <br /> If the address is over a day old, we may skip it. If we are successfully<br /> getting IRC addresses, and have node connections, then we skip it with<br /> the assumption that we will see the address advertisement if it is really<br /> active.<br /> <br /> Finally, for all addresses that appear to be ready for a retry, the<br /> address that has not been contacted the longest is chosen with a maximum<br /> of 24 hours. However, there is a twist. The calculation for the score is this:<br /> int64 nScore = min(nSinceLastTry, (int64)24 * 60 * 60) - nSinceLastSeen - nRandomizer;<br /> So, the address is penalized for every second since it is last seen (and<br /> a random adjustment).<br /> <br /> <br /> ===Inbound Accepting and Disconnecting===<br /> <br /> The client handles accepting new inbound connections and disconnecting<br /> nodes when appropriate in a a thread called ThreadSocketHandler2,<br /> which is in net.cpp.<br /> <br /> The socket thread is simply a loop which disconnects sockets that<br /> have the fDisconnect flag set on them (and have empty buffers),<br /> prepares all sockets for &quot;select&quot; and calls &quot;select&quot;. &quot;select&quot; is <br /> a system call which waits for activity on a set of sockets.<br /> When that call returns, the node accepts any new connections,<br /> receives and sends on any ready sockets, and marks any inactive sockets<br /> for disconnect with the fDisconnect flag.<br /> <br /> Sockets are disconnected if they are 60 seconds old and have not sent<br /> or received data.<br /> <br /> Sockets are disconnected if they have not sent or received data in<br /> the last 90 minutes.<br /> <br /> Sockets are disconnected if the current inbound data exceeds a buffer limit.<br /> (Search for: if (nPos &gt; ReceiveBufferSize()) in net.cpp)<br /> <br /> Sockets are disconnected if the current outbound data exceeds a buffer limit.<br /> (Search for: if (vSend.size() &gt; SendBufferSize()) in net.cpp)<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Connectivity&diff=16802 2011-09-17T22:34:18Z

<p>Wickrick22: formatting</p> <hr /> <div>==Overview==<br /> The Satoshi bitcoin client creates a thread to manage making<br /> connections to other nodes. The code for that thread is in a<br /> function called ThreadOpenConnections2 in net.cpp.<br /> <br /> The client also handles accepting new inbound connections and <br /> disconnecting nodes when appropriate in a a thread called<br /> ThreadSocketHandler2, which is also in net.cpp.<br /> <br /> The thread making connections does not discover the addresses of other<br /> nodes. That information is gathered in various ways (See the article<br /> on Node Discovery). The connection thread chooses among the available<br /> addresses and makes connections and disconnects nodes when appropriate.<br /> That is all it does.<br /> <br /> Node addresses are chosen based on the following set of rules.<br /> <br /> <br /> <br /> <br /> ==Connection Rules==<br /> <br /> ===Outbound Static Addresses===<br /> <br /> If the user specified addresses with -connect, the node uses <br /> those addresses only. It tries to establish a connection to each node<br /> and then sleeps for a half second, and then repeats that in a loop<br /> until shut down. The code establishes a connection by calling<br /> OpenNetworkConnection(addr). If the connection is already open,<br /> OpenNetworkConnection just returns.<br /> <br /> <br /> If the user specified addresses with -node, then connections are<br /> made to those nodes (with a half second delay between each) upon<br /> startup. After those connections are attempted, the code proceeds<br /> to the regular connection handling code.<br /> <br /> <br /> ===Outbound Limiting===<br /> <br /> The connection handling code is one loop that performs various functions until shutdown. The first thing the loop does is count<br /> the number of outbound connections, and if the maximum has been<br /> reached (8 or -maxconnections), then it goes into a 2 second delay<br /> loop until the count is below the max.<br /> <br /> <br /> Assuming the number of connections is below the limit, the node attempts<br /> to connect to another node. See the next section.<br /> <br /> <br /> ===Seed Nodes===<br /> <br /> If the node has not been able to learn about other addresses, presumably<br /> because those methods have failed, the node will use an internal list<br /> of 320 node addresses hard coded into the software to populate<br /> the list of known node addresses.<br /> <br /> There is code to move away from seed nodes when possible. The presumption<br /> is that this is to avoid overloading seed nodes. Once the local node has<br /> enough addresses (presumably learned from the seed nodes), the<br /> connection thread will close seed node connections.<br /> <br /> <br /> ===Outbound Random Selection===<br /> <br /> First the code puts the addresses into a.b.c.* buckets so only one<br /> connection is made to each 24 bit netmasked network.<br /> <br /> Next, it loops through every address and determines whether it is &quot;ready&quot;,<br /> and then, using a complex calculation, computes a score for every address.<br /> The address with the highest score wins and OpenNetworkConnection is<br /> called for it. Then the code completes the main loop of the thread and<br /> continues.<br /> <br /> In order to determine readiness, the code hashes the IP and other entropy<br /> into a deterministic random number between 1 and 3600. If the address<br /> specifies a nonstandard port, a 2 hour (7200) penalty is added to the number.<br /> This is an adjustment number to the retry interval.<br /> <br /> The main retry interval is basically the square root of the last time seen<br /> plus the &quot;random&quot; adjustment from the previous paragraph. If the node<br /> has been seen in the last hour, however, the retry interval is set to<br /> ten minutes. The following table is in the code:<br /> <br /> // Last seen Base retry frequency<br /> // &lt;1 hour 10 min<br /> // 1 hour 1 hour<br /> // 4 hours 2 hours<br /> // 24 hours 5 hours<br /> // 48 hours 7 hours<br /> // 7 days 13 hours<br /> // 30 days 27 hours<br /> // 90 days 46 hours<br /> // 365 days 93 hours<br /> <br /> After computing the interval, if the address has already been contacted in<br /> the interval, the address is skipped.<br /> <br /> If the address is over a day old, we may skip it. If we are successfully<br /> getting IRC addresses, and have node connections, then we skip it with<br /> the assumption that we will see the address advertisement if it is really<br /> active.<br /> <br /> Finally, for all addresses that appear to be ready for a retry, the<br /> address that has not been contacted the longest is chosen with a maximum<br /> of 24 hours. However, there is a twist. The calculation for the score is this:<br /> int64 nScore = min(nSinceLastTry, (int64)24 * 60 * 60) - nSinceLastSeen - nRandomizer;<br /> So, the address is penalized for every second since it is last seen (and<br /> a random adjustment).<br /> <br /> <br /> ===Inbound Accepting and Disconnecting===<br /> <br /> The client handles accepting new inbound connections and disconnecting<br /> nodes when appropriate in a a thread called ThreadSocketHandler2,<br /> which is in net.cpp.<br /> <br /> The socket thread is simply a loop which disconnects sockets that<br /> have the fDisconnect flag set on them (and have empty buffers),<br /> prepares all sockets for &quot;select&quot; and calls &quot;select&quot;. &quot;select&quot; is <br /> a system call which waits for activity on a set of sockets.<br /> When that call returns, the node accepts any new connections,<br /> receives and sends on any ready sockets, and marks any inactive sockets<br /> for disconnect with the fDisconnect flag.<br /> <br /> Sockets are disconnected if they are 60 seconds old and have not sent<br /> or received data.<br /> <br /> Sockets are disconnected if they have not sent or received data in<br /> the last 90 minutes.<br /> <br /> Sockets are disconnected if the current inbound data exceeds a buffer limit.<br /> (Search for: if (nPos &gt; ReceiveBufferSize()) in net.cpp)<br /> <br /> Sockets are disconnected if the current outbound data exceeds a buffer limit.<br /> (Search for: if (vSend.size() &gt; SendBufferSize()) in net.cpp)<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Connectivity&diff=16801 2011-09-17T22:29:20Z

<p>Wickrick22: Initial content</p> <hr /> <div>==Overview==<br /> The Satoshi bitcoin client creates a thread to manage making<br /> connections to other nodes. The code for that thread is in a<br /> function called ThreadOpenConnections2 in net.cpp.<br /> <br /> The client also handles accepting new inbound connections and <br /> disconnecting nodes when appropriate in a a thread called<br /> ThreadSocketHandler2, which is also in net.cpp.<br /> <br /> The thread making connections does not discover the addresses of other<br /> nodes. That information is gathered in various ways (See the article<br /> on Node Discovery). The connection thread chooses among the available<br /> addresses and makes connections and disconnects nodes when appropriate.<br /> That is all it does.<br /> <br /> Node addresses are chosen based on the following set of rules.<br /> <br /> <br /> <br /> <br /> ==Connection Rules==<br /> <br /> ===Outbound Static Addresses===<br /> <br /> If the user specified addresses with -connect, the node uses <br /> those addresses only. It tries to establish a connection to each node<br /> and then sleeps for a half second, and then repeats that in a loop<br /> until shut down. The code establishes a connection by calling<br /> OpenNetworkConnection(addr). If the connection is already open,<br /> OpenNetworkConnection just returns.<br /> <br /> <br /> If the user specified addresses with -node, then connections are<br /> made to those nodes (with a half second delay between each) upon<br /> startup. After those connections are attempted, the code proceeds<br /> to the regular connection handling code.<br /> <br /> <br /> ===Outbound Limiting===<br /> <br /> The connection handling code is one loop that performs various<br /> <br /> functions until shutdown. The first thing the loop does is count<br /> the number of outbound connections, and if the maximum has been<br /> reached (8 or -maxconnections), then it goes into a 2 second delay<br /> loop until the count is below the max.<br /> <br /> <br /> Assuming the number of connections is below the limit, the node attempts<br /> to connect to another node. See the next section.<br /> <br /> <br /> ===Seed Nodes===<br /> <br /> If the node has not been able to learn about other addresses, presumably<br /> because those methods have failed, the node will use an internal list<br /> of 320 node addresses hard coded into the software to populate<br /> the list of known node addresses.<br /> <br /> There is code to move away from seed nodes when possible. The presumption<br /> is that this is to avoid overloading seed nodes. Once the local node has<br /> enough addresses (presumably learned from the seed nodes), the<br /> connection thread will close seed node connections.<br /> <br /> <br /> ===Outbound Random Selection===<br /> <br /> First the code puts the addresses into a.b.c.* buckets so only one<br /> connection is made to each 24 bit netmasked network.<br /> <br /> Next, it loops through every address and determines whether it is &quot;ready&quot;,<br /> and then, using a complex calculation, computes a score for every address.<br /> The address with the highest score wins and OpenNetworkConnection is<br /> called for it. Then the code completes the main loop of the thread and<br /> continues.<br /> <br /> In order to determine readiness, the code hashes the IP and other entropy<br /> into a deterministic random number between 1 and 3600. If the address<br /> specifies a nonstandard port, a 2 hour (7200) penalty is added to the number.<br /> This is an adjustment number to the retry interval.<br /> <br /> The main retry interval is basically the square root of the last time seen<br /> <br /> plus the &quot;random&quot; adjustment from the previous paragraph. If the node<br /> has been seen in the last hour, however, the retry interval is set to<br /> ten minutes. The following table is in the code:<br /> <br /> // Last seen Base retry frequency<br /> // &lt;1 hour 10 min<br /> // 1 hour 1 hour<br /> // 4 hours 2 hours<br /> // 24 hours 5 hours<br /> // 48 hours 7 hours<br /> // 7 days 13 hours<br /> // 30 days 27 hours<br /> // 90 days 46 hours<br /> // 365 days 93 hours<br /> <br /> After computing the interval, if the address has already been contacted in<br /> the interval, the address is skipped.<br /> <br /> If the address is over a day old, we may skip it. If we are successfully<br /> getting IRC addresses, and have node connections, then we skip it with<br /> the assumption that we will see the address advertisement if it is really<br /> active.<br /> <br /> Finally, for all addresses that appear to be ready for a retry, the<br /> address that has not been contacted the longest is chosen with a maximum<br /> of 24 hours. However, there is a twist. The calculation for the score is this:<br /> int64 nScore = min(nSinceLastTry, (int64)24 * 60 * 60) - nSinceLastSeen - nRandomizer;<br /> So, the address is penalized for every second since it is last seen (and<br /> a random adjustment).<br /> <br /> <br /> ===Inbound Accepting and Disconnecting===<br /> <br /> The client handles accepting new inbound connections and disconnecting<br /> <br /> nodes when appropriate in a a thread called ThreadSocketHandler2,<br /> which is in net.cpp.<br /> <br /> The socket thread is simply a loop which disconnects sockets that<br /> have the fDisconnect flag set on them (and have empty buffers),<br /> prepares all sockets for &quot;select&quot; and calls &quot;select&quot;. &quot;select&quot; is <br /> a system call which waits for activity on a set of sockets.<br /> When that call returns, the node accepts any new connections,<br /> receives and sends on any ready sockets, and marks any inactive sockets<br /> for disconnect with the fDisconnect flag.<br /> <br /> Sockets are disconnected if they are 60 seconds old and have not sent<br /> or received data.<br /> <br /> Sockets are disconnected if they have not sent or received data in<br /> the last 90 minutes.<br /> <br /> Sockets are disconnected if the current inbound data exceeds a buffer limit.<br /> (Search for: if (nPos &gt; ReceiveBufferSize()) in net.cpp)<br /> <br /> Sockets are disconnected if the current outbound data exceeds a buffer limit.<br /> (Search for: if (vSend.size() &gt; SendBufferSize()) in net.cpp)<br /> <br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Discovery&diff=16800 2011-09-17T22:21:58Z

<p>Wickrick22: Initial content</p> <hr /> <div>==Overview==<br /> <br /> The Satoshi client discovers the IP address and port of nodes in several different ways.<br /> <br /> # Nodes discover their own external address by various methods.<br /> # Nodes receive the callback address of remote nodes that connect to them.<br /> # Nodes connect to IRC to receive addresses.<br /> # Nodes makes DNS request to receive IP addresses.<br /> # Nodes can use addresses hard coded into the software.<br /> # Nodes exchange addresses with other nodes.<br /> # Nodes store addresses in a database and read that database on startup.<br /> # Nodes can be provided addresses as command line arguments<br /> # Nodes read addresses from a user provided text file on startup<br /> <br /> A timestamp is kept for each address to keep track of when the node<br /> address was last seen. The AddressCurrentlyConnected in net.cpp handles<br /> updating the timestamp whenever a message is received from a node.<br /> Timestamps are only updated on an address and saved to the database<br /> when the timestamp is over 20 minutes old.<br /> <br /> See the Node Connectivity article for information on which type of<br /> addresses take precedence when actually connecting to nodes.<br /> <br /> In the first section we will cover how a node handles a request for<br /> addresses via the &quot;getaddr&quot; message. By understanding the role of<br /> timestamps, it will become more clear why timestamps are kept the way<br /> they are for each of the different ways an address is discovered.<br /> <br /> <br /> ==Handling Message &quot;getaddr&quot;==<br /> <br /> When a node receives a &quot;getaddr&quot; request, it first figures out how many<br /> addresses it has that have a timestamp in the last 3 hours.<br /> Then it sends those addresses, but if there are more than 2500 addresses<br /> seen in the last 3 hours, it selects around 2500 out of the available<br /> recent addresses by using random selection.<br /> <br /> <br /> Now lets look at the ways a node finds out about node addresses.<br /> <br /> <br /> <br /> ==Discovery Methods==<br /> <br /> <br /> ===Local Client's External Address===<br /> The client uses two methods to determine its own external, routable IP<br /> address: it uses IRC, preferably, and if that does not succeed, it uses<br /> public web services which return the information.<br /> <br /> From a thread created for this work (called ThreadIRCSeed in irc.cpp),<br /> the client makes an IRC connection to 92.243.23.21 or irc.lfnet.org,<br /> if the direct IP connection fails. The port is 6667.[1]<br /> If the connection succeeds, the client issues a USERHOST command to<br /> the IRC server, in order to get their own IP address.[2]<br /> <br /> The client also runs a thread called ThreadGetMyExternalIP (in net.cpp)<br /> which attempts to determine the client's IP address as seen from the outside<br /> world. It gives the IRC thread a chance to discover the IP address<br /> first, sleeping and checking periodically for 2 minutes, and then it<br /> proceeds if the IRC method did not succeed.<br /> <br /> First, it attempts to connect to 91.198.22.70 port 80, which should be<br /> the checkip.dyndns.org server. If connection fails, a DNS request is made<br /> for checkip.dyndns.org and a connection is attempted to that address.<br /> Next, it attemps to connect to 74.208.43.192 port 80, which should be<br /> the www.showmyip.com server. If connection fails, a DNS request is made<br /> for www.showmyip.com and a connection is attempted to that address.<br /> <br /> For each address attempted above, the client attempts to connect,<br /> send a HTTP request, read the appropriate response line, and parse the<br /> IP address from it.<br /> If this succeeds, the IP is returned, it is advertised to any connected<br /> nodes, and then the thread finishes (without proceeding to the next<br /> address).<br /> <br /> <br /> <br /> ===Connect Callback Address===<br /> When a node receives an initial &quot;version&quot; message, and that node initiated<br /> the connection, then the node advertises its address to the remote so<br /> that it can connect back to the local node if it wants to.[3]<br /> After sending its own address, it sends a &quot;getaddr&quot; request message<br /> to the remote node to learn about more addresses, if the remote node<br /> version is recent or if the local node does not yet have 1000 addresses.<br /> <br /> <br /> ===IRC Addresses===<br /> <br /> In addition to learning and sharing its own address, the node<br /> learns about other node addresses via an IRC channel. See irc.cpp.<br /> After learning its own address, a node encodes its own address into a string<br /> to be used as a nickname. Then, it randomly joins an IRC channel named<br /> between #bitcoin00 and #bitcoin99. Then it issues a WHO command.<br /> The thread reads the lines as they appear in the channel and decodes<br /> the IP addresses of other nodes in the channel. It does this in<br /> a loop, forever, until the node is shutdown.<br /> <br /> When the client discovers an address from IRC, it sets the timestamp<br /> on the address to the current time, but it uses a &quot;penalty&quot;<br /> of 51 minutes, which means it looks like it was actually seen<br /> almost an hour ago.<br /> <br /> <br /> ===DNS Addresses===<br /> Upon startup, the client makes DNS requests to hard coded DNS names<br /> in order to learn about the addresses of other nodes.[4] As of version<br /> v0.3.24, these addresses were[5]:<br /> <br /> bitseed.xf2.org<br /> bitseed.bitcoin.org.uk<br /> dnsseed.bluematt.me<br /> <br /> A recent query of these addresses returned 48 nodes. Note that a<br /> DNS reply can contain multiple IP addresses for a requested name.<br /> <br /> <br /> Addresses discovered via DNS are initially given a zero timestamp,<br /> therefore they are not advertised in response to a &quot;getaddr&quot; request.<br /> <br /> <br /> <br /> ===Hard Coded &quot;Seed&quot; Addresses===<br /> The client contains hard coded IP addresses that represent bitcoin nodes.[6]<br /> These addresses are only used as a last resort, if no other method<br /> has produced any addresses at all.[7]<br /> When the loop in the connection handling thread ThreadOpenConnections2()<br /> sees an empty address map, it uses the &quot;seed&quot; IP addresses as backup.<br /> <br /> There is code is move away from seed nodes when possible. The presumption<br /> is that this is to avoid overloading those nodes. Once the local node has<br /> enough addresses (presumably learned from the seed nodes), the<br /> connection thread will close seed node connections.[8]<br /> <br /> Seed Addresses are initially given a zero timestamp,<br /> therefore they are not advertised in response to a &quot;getaddr&quot; request.<br /> <br /> <br /> <br /> ===Ongoing &quot;addr&quot; advertisements===<br /> Nodes may receive addresses in an &quot;addr&quot; message after having<br /> sent a &quot;getaddr&quot; request, or &quot;addr&quot; messages may arrive <br /> unsolicited, because nodes advertise addresses gratuitously<br /> when they relay addresses (see below), when they advertise<br /> their own address periodically, and when a connection is made.<br /> <br /> If the address is from a really old version, it is ignored; if from<br /> a not-so-old version, it is ignored if we have 1000 addresses already.<br /> <br /> If the sender sent over 1000 addresses, they are all ignored.<br /> <br /> Addresses received from an &quot;addr&quot; message have a timestamp, but the<br /> timestamp is not necessarily honored directly.<br /> <br /> <br /> For every address in the message:<br /> # If the timestamp is too low or too high, it is set to 5 days ago.<br /> # We subtract 2 hours from the timestamp and add the address.<br /> <br /> Note that when any address is added, for any reason, the code that calls<br /> AddAddress() does not check to see if it already exists. The AddAddresss()<br /> function in net.cpp will do that, and if the address already exists, further<br /> processing is done to update the address record. If the advertised services<br /> of the address have changed, that is updated and stored.<br /> If the address has been seen in the last 24 hours and the timestamp is<br /> currently over 60 minutes old, then it is updated to 60 minutes ago.<br /> If the address has NOT been seen in the last 24 hours, and the timestamp is<br /> currently over 24 hours old, then it is updated to 24 hours ago.<br /> <br /> ====Address Relay====<br /> <br /> Once addresses are added from an &quot;addr&quot; message (see above), they then<br /> may be relayed to the other nodes. First, the following criteria<br /> must be set [9]:<br /> <br /> #The address timestamp, after processing, is within 60 minutes of the current time<br /> #The &quot;addr&quot; message contains 10 addresses or less<br /> #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.<br /> #The address must be routable.<br /> <br /> When they meet the above criteria, the node hashes all the eligible<br /> node IP addresses, as well as the current day in the form of an integer,<br /> and the two nodes with the lowest hash value are chosen to have<br /> the address relayed to them.<br /> <br /> ====Self broadcast====<br /> <br /> Every 24 hours, the node advertises its own address to all connected nodes.<br /> It also clears the list of the addresses we think the remote node has, which<br /> will trigger a refresh of sends to nodes. This code is in SendMessages()<br /> in main.cpp.<br /> <br /> ====Old Address Cleanup====<br /> <br /> In SendMessages() in main.cpp, there is code to remove old addresses.<br /> This is done every ten minutes, as long as there are 3 active connections.<br /> The node erases messages that have not been used in 14 days as<br /> long as there are at least 1000 addresses in the map, and as long<br /> as the erasing process has not taken more than 20 seconds.<br /> <br /> <br /> <br /> ===Addresses stored in the Database===<br /> Addresses are stored in the database when AddAddress() is called.<br /> <br /> Addresses are read on startup when AppInit2() calls LoadAddresses(),<br /> which is located in db.cpp.<br /> <br /> Currently, it appears all addresses are stored all at once whenever<br /> any address is stored or updated [10]. Indeed, AddAddress is seen<br /> to take over .01 seconds in various testing and is typically called <br /> tens of thousands of times in the initial 12 hours of running the<br /> client.<br /> <br /> <br /> <br /> ===Command Line Provided Addresses===<br /> <br /> The user can specify nodes to connect to with the -addnode &lt;ip&gt;<br /> command line argument. Multiple nodes may be specified.<br /> <br /> Addresses provided on the command line are initially given a zero<br /> timestamp, therefore they are not advertised in response to a &quot;getaddr&quot;<br /> request.<br /> <br /> The user can also specify an address to connect to with the -connect &lt;ip&gt;<br /> command line argument. Multiple nodes may be specified.<br /> The -connect argument differs from -addnode in that -connect addresses<br /> are not added to the address database and when -connect is specified,<br /> only those addresses are used.<br /> <br /> <br /> <br /> ===Text File Provided Addresses===<br /> The client will automatically read a file named &quot;addr.txt&quot; in the<br /> bitcoin data directory and will add any addresses it finds in there<br /> as node addresses. These nodes are given no special preference over<br /> other addresses. They are just added to the pool.<br /> <br /> Addresses loaded from the text file are initially given a zero timestamp,<br /> therefore they are not advertised in response to a &quot;getaddr&quot; request.<br /> <br /> <br /> <br /> <br /> ==Footnotes==<br /> 1. See: <br /> CAddress addrConnect(&quot;92.243.23.21&quot;, 6667); // irc.lfnet.org<br /> in ThreadIRCSeed2() in irc.cpp.<br /> <br /> 2. See:<br /> GetIPFromIRC()<br /> in irc.cpp.<br /> <br /> 3. See:<br /> // Advertise our address<br /> in ProcessMessage() in main.cpp where strCommand == &quot;version&quot;<br /> <br /> 4. See <br /> DNSAddressSeed()<br /> in net.cpp.<br /> <br /> 5. See <br /> static const char *strDNSSeed[] = {<br /> in net.cpp<br /> <br /> 6. See<br /> pnSeed <br /> in net.cpp<br /> <br /> 7. See:<br /> if (mapAddresses.empty() &amp;&amp; (GetTime() - nStart &gt; 60 || fTOR) &amp;&amp; !fTestNet)<br /> in ThreadOpenConnections2() in net.cpp.<br /> <br /> 8. See:<br /> if (fSeedUsed &amp;&amp; mapAddresses.size() &gt; ARRAYLEN(pnSeed) + 100)<br /> { <br /> // Disconnect seed nodes<br /> in ThreadOpenConnections2() in net.cpp.<br /> <br /> 9. See:<br /> if (addr.nTime &gt; nSince &amp;&amp; !pfrom-&gt;fGetAddr &amp;&amp; vAddr.size() &lt;= 10 &amp;&amp; addr.IsRoutable())<br /> in ProcessMessage() in main.cpp where strCommand == &quot;addr&quot;<br /> <br /> 10. See [https://bitcointalk.org/index.php?topic=26436.0 bitcointalk.org]<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Initialization_and_Startup&diff=16799 2011-09-17T22:01:31Z

<p>Wickrick22: Initial content</p> <hr /> <div><br /> ==Startup Process==<br /> <br /> The client uses a fixed number of threads that are created on startup. All of the reading and writing on active network sockets are handled by one thread.<br /> <br /> The main() entry point to the program is in init.cpp. Do not go looking in main.cpp for main() - you will not find it.<br /> <br /> The first thing main() does is call AppInit, which calls AppInit2 which performs a bunch of initialization busy work mostly related to how the application handles errors. At some point AppInit2 calls ParseParameters, and then some argument handling code processes some basic arguments.<br /> <br /> Now it checks to see if an existing GUI window is already present and if so, brings it to the foreground.<br /> <br /> Next it creates a lock file in the bitcoin directory and if bitcoin is already running, displays a message and exits.<br /> <br /> Next it attemps to listen on the bitcoin port, and if the port is already in user or other error, displays a message and exits.<br /> <br /> Next it loads IP addresses from a database, then it loads the block index, and then it loads the wallet.<br /> <br /> Next it gets the top block number from the wallet, or zero if -rescan is used. Then It scans the block chain from the block number above.<br /> <br /> Side Note: printf has been redefined in util.h. So printf is really OutputDebugStringF which directs to a file if appropriate (see util.h and util.cpp). Also &quot;loop&quot; is defined in util.h as for ( ; ; ).<br /> <br /> Then it does a bit more initialization and parameter processing and then it finally opens the GUI main window.<br /> <br /> Next it creates two threads:<br /> <br /> # StartNode()<br /> # And if acting as server: ThreadRPCServer()<br /> <br /> This is the only place where these threads are created.<br /> <br /> StartNode() is in net.cpp and ThreadRPCServer() is in rpc.cpp.<br /> <br /> Last, if not compiled for the GUI it sleeps for 5 seonds in an infinite loop.<br /> <br /> == fClient Mode ==<br /> <br /> It is worth noting that there is code in the client to allow it to operate in a mode where it only downloads block headers. The implementation is intended to be used as a lightweight client mode which can operate without verifying and storing all blocks and transactions. This is controlled by the fClient variable in the code which is currently hard coded to false. This is currently not considered to be finished code. This mode is known as fClient mode and the phrase Simplified Payment Verification (or SPV) mode has also been used to describe a lightweight client approach.<br /> <br /> <br /> <br /> ==Thread StartNode() in net.cpp==<br /> <br /> StartNode is sort of a master networking thread.<br /> <br /> First it creates a CNode for the localhost 127.0.0.1 internal addresss to<br /> handle communication.<br /> <br /> Next, it gets the local IP address. On windows, its a lookup using the<br /> local host name. On Linux, it is the first IP address it finds on an<br /> interface that is up and is not the loopback interface.<br /> <br /> Next it creates a thread (ThreadGetMyExternalIP) to confirm the local IP<br /> address using 3rd party verification. If using a proxy, it does not<br /> bother, because it will not take incoming connections.<br /> <br /> Next, if Universal Plug and Play is used, then a thread (ThreadMapPort)<br /> to deal with port mapping is created.<br /> <br /> Next it creates a thread (ThreadIRCSeed) to exchange IP addresses.<br /> <br /> Next it creates a thread (ThreadSocketHandler) to &quot;Send and receive from<br /> sockets, accept connections&quot;.<br /> <br /> Next it creates a thread (ThreadOpenConnections) to initiate outbound<br /> connections.<br /> <br /> Next it creates a thread (ThreadMessageHandler) to process messages.<br /> <br /> Finally, if you have specified so, it will start a bitcoin mining thread.<br /> <br /> <br /> <br /> ==Thread IRCSeed in net.cpp==<br /> <br /> Connects to 92.243.23.21 port 6667, JOINs the channel, and then<br /> reads lines one at a time looking for other users.<br /> <br /> <br /> ==Thread ThreadSocketHandler in net.cpp==<br /> <br /> Goes into an endless loop servicing sockets that need servicing.<br /> Handles disconnected nodes.<br /> Prepares &quot;select&quot; descriptor list and then calls select, waiting for<br /> I/O on all the relevant sockets with a 50ms timeout.<br /> Process new incoming connection on listening socket. Create a CNode for them.<br /> Handle receiving and sending.<br /> Set sockets that have not done anything to disconnected state.<br /> <br /> <br /> ==Thread ThreadOpenConnecions in net.cpp==<br /> <br /> Figures out nodes from parameters, seeds, irc, etc, and then goes into a<br /> loop, connecting to each one by one.<br /> <br /> <br /> ==Thread ThreadMessageHandler in net.cpp==<br /> <br /> This thread goes through all the nodes and calls ProcessMessages(pnode) in<br /> main.cpp which looks for valid messages on the node receive<br /> queue (pFrom-&gt;vRecv) and if it finds one, it calls <br /> ProcessMessage(CNode* pfrom, string strCommand, CDataStream&amp; vRecv), which<br /> is also in main.cpp.<br /> <br /> Then the thread calls SendMessages for each node (which is in main.cpp)<br /> which handles creating and sending any messages appropriate for that node.<br /> <br /> <br /> ==Thread ThreadRPCServer in rpc.cpp==<br /> <br /> <br /> This thread will be rather complicated in that it implements an<br /> HTTP(S)+JSONRPC server using boost classes that are probably going<br /> to be unfamiliar to most developers.<br /> <br /> You will see lines like this:<br /> acceptor.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));<br /> <br /> and this:<br /> boost::thread api_caller(ReadHTTP, boost::ref(stream), boost::ref(mapHeaders), boost::ref(strRequest));<br /> if (!api_caller.timed_join(boost::posix_time::seconds(GetArg(&quot;-rpctimeout&quot;, 30))))<br /> <br /> It appears the code above is creating a thread in order to apply 30<br /> second timeout to reading an HTTPrequest. When HTTP requests are<br /> read, they are parsed, and then a routine corresponding to the<br /> request command name is called to handle the request. This happens<br /> in a loop until shutdown.<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Transaction_Exchange&diff=16794 2011-09-17T21:38:40Z

<p>Wickrick22: Initial stub</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Block_Exchange&diff=16793 2011-09-17T21:38:27Z

<p>Wickrick22: Initial stub</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Sockets_and_Messages&diff=16792 2011-09-17T21:38:16Z

<p>Wickrick22: Created page with &quot;{{stub}} Category:Developer Category:Technical&quot;</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Connectivity&diff=16791 2011-09-17T21:38:07Z

<p>Wickrick22: Initial stub</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Node_Discovery&diff=16790 2011-09-17T21:37:09Z

<p>Wickrick22: Initial stub</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Satoshi_Client_Initialization_and_Startup&diff=16789 2011-09-17T21:36:17Z

<p>Wickrick22: Initial stub</p> <hr /> <div>{{stub}}<br /> <br /> [[Category:Developer]]<br /> [[Category:Technical]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Bitcoind&diff=16788 2011-09-17T21:28:41Z

<p>Wickrick22: Added Theory of Operation. (The dead links will be populated right away.)</p> <hr /> <div>[[Image:Bitcoin Original Client.png|thumb|350px|right|The bitcoin original client]]<br /> <br /> The '''Original Bitcoin client''' is the first [[bitcoin]] client in the network's history. It is also the official client of the bitcoin project. It's available under the [http://www.opensource.org/licenses/mit-license.php MIT license] for Windows, 32 and 64-bit GNU/Linux-based OSes and Mac OS X.<br /> <br /> The client comes with two executables, a GUI and an command line interface (CLI).<br /> <br /> == Executables ==<br /> See [[Running_Bitcoin|running bitcoin]] for more detail and an example of the configuration file.<br /> === Bitcoin (GUI) ===<br /> <br /> The bitcoin GUI provides an easy to use wxWidgets-based interface. It allows to send coins and to monitor:<br /> * transactions from and to the opened wallet<br /> * block creations<br /> * confirmations of transactions<br /> * balance of the wallet<br /> <br /> === Bitcoind (CLI) ===<br /> <br /> Bitcoind is both a headless daemon and a client for the same daemon. It also provides a JSON-RPC interface, allowing it to be controlled locally (via bitcoind or another CLI client) or remotely. [[Original Bitcoin client/API Calls list|Various commands]] are made available by the API.<br /> <br /> To use locally, first start the program in daemon mode:<br /> :bitcoind -daemon<br /> <br /> <br /> Then you can use the same program to execute [[Original Bitcoin client/API Calls list|API commands]], e.g.:<br /> :bitcoind listreceivedbyaddress 0 true<br /> :bitcoind getbalance<br /> <br /> To stop the bitcoin daemon, execute:<br /> :bitcoind stop<br /> <br /> ==History==<br /> <br /> * Version 0.3.24 was released for all supported platforms on July 8th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=27187.0 Bitcoin version 0.3.24 released]&lt;/ref&gt;.<br /> * Version 0.3.23 was released for all supported platforms on June 13th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=16553.0 Bitcoin version 0.3.23 released]&lt;/ref&gt;.<br /> * Version 0.3.22 was released for all supported platforms on May 19th, 2011 &lt;ref&gt;[http://forum.bitcoin.org/index.php?topic=8894.0 Version 0.3.22]&lt;/ref&gt;.<br /> * Version 0.3.20 was released for all supported platforms on February 21st, 2011&lt;ref&gt;[http://www.bitcoin.org/smf/index.php?topic=3704.0 Version 0.3.20]&lt;/ref&gt;.<br /> <br /> <br /> <br /> ==Theory of Operation==<br /> <br /> Satoshi's Original Bitcoin client is a multithreaded C++ program. It is designed to be portable across Windows, Mac, and Linux systems. The multithreaded aspect leads to some complexity and the use of certain code patterns to deal with concurrency that may be unfamiliar to many programmers. Also, the code is aggressive in the use of C++ constructs, so it will help to be fluent with map, multmap, set, string, vector, iostream, and templates. As typical of a C++ program, l a lot of code tends to end up in the header files so be sure to search both the .cpp and .h files when looking for a function.<br /> <br /> The client is oriented around several major operations, which are described in separate detailed articles and summarized in the following sections.<br /> <br /> <br /> ===[[Satoshi Client Initialization and Startup|Initialization and Startup]]===<br /> Upon startup, the client performs various initilization routines including starting multiple threads to handle concurrent operations.<br /> <br /> ===[[Satoshi Client Node Discovery|Node Discovery]]===<br /> The client uses various techniques find out about other bitcoin nodes that may exist.<br /> <br /> ===[[Satoshi Client Node Connectivity|Node Connectivity]]===<br /> The client initiates and maintains connections to other nodes.<br /> <br /> ===[[Satoshi Client Sockets and Messages|Sockets and Messages]]===<br /> The client processes messages from other nodes and sends messages to other nodes using socket connections.<br /> <br /> ===[[Satoshi Client Block Exchange|Block Exchange]]===<br /> Nodes advertise their inventory of blocks to each other and exchange blocks to build block chains.<br /> <br /> ===[[Satoshi Client Transaction Exchange|Transaction Exchange]]===<br /> Nodes exchange and relay transactions with each other. The client associates transactions with bitcoin addresses in the local wallet.<br /> <br /> ===[[Satoshi Client Wallet Services|Wallet Services]]===<br /> The client can create transactions using the local wallet. The client associates transactions with bitcoin addresses in the local wallet. The client provides a service for managing the local wallet.<br /> <br /> ===[[Satoshi Client RPC Interface|RPC Interface]]===<br /> The client offers an JSON-RPC interface over HTTP over sockets to perform various operational functions and to manage the local wallet.<br /> <br /> ===User Interface===<br /> The user interface code is currently based on [http://www.wxwidgets.org wxWidgets] and is scheduled to be superseded by [[Bitcoin-qt]] in version 0.5.0. <br /> <br /> ==See Also==<br /> <br /> * [[Original Bitcoin client/API calls list]]<br /> * [[Protocol specification|Bitcoin network protocol]]<br /> * [[Development process]]<br /> * [[Changelog]]<br /> <br /> ==External Links==<br /> * [http://sourceforge.net/projects/bitcoin/ Bitcoin Client project on SourceForge]<br /> * [https://github.com/bitcoin/bitcoin/ Bitcoin Client project on Github]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Category:Nodes]]<br /> [[Category:Wallets]]<br /> [[Category:User Interfaces]]<br /> [[Category:Clients]]<br /> [[Category:Developer]]<br /> [[Category:Technical]]<br /> [[Category:Free Software]]<br /> [[Category:License/MIT-X11]]<br /> [[Category:Open Source]]</div>

Wickrick22 https://en.bitcoin.it/w/index.php?title=Controlled_supply&diff=14896 2011-08-13T23:20:00Z

<p>Wickrick22: </p> <hr /> <div>__TOC__<br /> <br /> In a centralized economy, currency is issued by a central bank, at a rate <br /> that is supposed to match the growth of the amount of physical goods that <br /> are exchanged, so that these goods can be traded with stable prices. The <br /> &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Money_supply money supply]&lt;/span&gt; is controlled by a central bank through &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Open_market_operations Open Market Operations]&lt;/span&gt;. In the United States, the &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Federal_Reserve_System Fed]&lt;/span&gt; sets the &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Federal_Funds_Rate Federal Funds]&lt;/span&gt; rate, and more recently, prints money electronically in a process called &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Quantitative_easing Quantitative Easing]&lt;/span&gt;.<br /> <br /> In a fully decentralized monetary system, there is no central authority that regulates the amount of currency in circulation. 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.<br /> <br /> ==Currency with Finite Supply==<br /> <br /> [[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time]]<br /> <br /> Bitcoins are created each time a user discovers a new [[block]]. <br /> The rate of block creation is approximately constant over time: 6 per hour. The <br /> 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 <br /> never exceed 21 million&lt;ref&gt;[http://www.bitcoin.org/smf/index.php?topic=3366.msg47522#msg47522 21 million cap]&lt;/ref&gt;.<br /> <br /> <br /> <br /> ==Projected Bitcoins Short Term ==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Block!!Reward Era!! BTC/block!! Year!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br /> |-<br /> |0||1||50.00||2009||0||2625000||2625000||infinite||12.500%<br /> |-<br /> |52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%<br /> |-<br /> |105000||1||50.00||2011||5250000||2625000||7875000||50.00%||37.500%<br /> |-<br /> |157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%<br /> |-<br /> |210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%<br /> |-<br /> |262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%<br /> |-<br /> |315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%<br /> |-<br /> |367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%<br /> |-<br /> |420000||3||12.50||2017||15750000||656250||16406250||4.17%||78.125%<br /> |-<br /> |472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%<br /> |-<br /> |525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%<br /> |-<br /> |577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%<br /> |-<br /> |630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%<br /> |-<br /> |682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%<br /> |-<br /> |735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%<br /> |-<br /> |787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%<br /> |}<br /> <br /> <br /> ==Projected Bitcoins Long Term ==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Block!!Reward Era!! BTC/block!! Year!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br /> |-<br /> | 0|| 1|| 50.00000000||2009.007|| 0.00000000|| 10500000.00000000|| 10500000.00000000|| infinite|| 50.00000006%<br /> |-<br /> | 210000|| 2|| 25.00000000||2013.000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%<br /> |-<br /> | 420000|| 3|| 12.50000000||2016.993|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%<br /> |-<br /> | 630000|| 4|| 6.25000000||2020.986|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%<br /> |-<br /> | 840000|| 5|| 3.12500000||2024.978|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%<br /> |-<br /> | 1050000|| 6|| 1.56250000||2028.971|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%<br /> |-<br /> | 1260000|| 7|| 0.78125000||2032.964|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%<br /> |-<br /> | 1470000|| 8|| 0.39062500||2036.956|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%<br /> |-<br /> | 1680000|| 9|| 0.19531250||2040.949|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%<br /> |-<br /> | 1890000|| 10|| 0.09765625||2044.942|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%<br /> |-<br /> | 2100000|| 11|| 0.04882812||2048.934|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%<br /> |-<br /> | 2310000|| 12|| 0.02441406||2052.927|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%<br /> |-<br /> | 2520000|| 13|| 0.01220703||2056.920|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%<br /> |-<br /> | 2730000|| 14|| 0.00610351||2060.913|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%<br /> |-<br /> | 2940000|| 15|| 0.00305175||2064.905|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%<br /> |-<br /> | 3150000|| 16|| 0.00152587||2068.898|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%<br /> |-<br /> | 3360000|| 17|| 0.00076293||2072.891|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%<br /> |-<br /> | 3570000|| 18|| 0.00038146||2076.883|| 20999839.77420000|| 80.10660000|| 20999919.88080001|| 0.00038146%|| 99.99961859%<br /> |-<br /> | 3780000|| 19|| 0.00019073||2080.876|| 20999919.88080001|| 40.05330000|| 20999959.93410001|| 0.00019073%|| 99.99980932%<br /> |-<br /> | 3990000|| 20|| 0.00009536||2084.869|| 20999959.93410001|| 20.02560000|| 20999979.95970001|| 0.00009536%|| 99.99990468%<br /> |-<br /> | 4200000|| 21|| 0.00004768||2088.861|| 20999979.95970001|| 10.01280000|| 20999989.97250001|| 0.00004768%|| 99.99995236%<br /> |-<br /> | 4410000|| 22|| 0.00002384||2092.854|| 20999989.97250001|| 5.00640000|| 20999994.97890001|| 0.00002384%|| 99.99997620%<br /> |-<br /> | 4620000|| 23|| 0.00001192||2096.847|| 20999994.97890001|| 2.50320000|| 20999997.48210001|| 0.00001192%|| 99.99998812%<br /> |-<br /> | 4830000|| 24|| 0.00000596||2100.840|| 20999997.48210001|| 1.25160000|| 20999998.73370001|| 0.00000596%|| 99.99999408%<br /> |-<br /> | 5040000|| 25|| 0.00000298||2104.832|| 20999998.73370001|| 0.62580000|| 20999999.35950001|| 0.00000298%|| 99.99999706%<br /> |-<br /> | 5250000|| 26|| 0.00000149||2108.825|| 20999999.35950001|| 0.31290000|| 20999999.67240001|| 0.00000149%|| 99.99999855%<br /> |-<br /> | 5460000|| 27|| 0.00000074||2112.818|| 20999999.67240001|| 0.15540000|| 20999999.82780001|| 0.00000074%|| 99.99999929%<br /> |-<br /> | 5670000|| 28|| 0.00000037||2116.810|| 20999999.82780001|| 0.07770000|| 20999999.90550001|| 0.00000037%|| 99.99999966%<br /> |-<br /> | 5880000|| 29|| 0.00000018||2120.803|| 20999999.90550001|| 0.03780000|| 20999999.94330001|| 0.00000018%|| 99.99999984%<br /> |-<br /> | 6090000|| 30|| 0.00000009||2124.796|| 20999999.94330001|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%<br /> |-<br /> | 6300000|| 31|| 0.00000004||2128.788|| 20999999.96220000|| 0.00840000|| 20999999.97060001|| 0.00000004%|| 99.99999997%<br /> |-<br /> | 6510000|| 32|| 0.00000002||2132.781|| 20999999.97060001|| 0.00420000|| 20999999.97480001|| 0.00000002%|| 99.99999999%<br /> |-<br /> | 6720000|| 33|| 0.00000001||2136.774|| 20999999.97480001|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%<br /> |-<br /> | 6930000|| 34|| 0.00000000||2140.767|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%<br /> |}<br /> ==Inflation and Deflation==<br /> <br /> 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 greatly exceed 21 million due to [http://en.wikipedia.org/wiki/Fractional-reserve_banking Fractional-reserve Banking]. So while the limited number of &quot;hard&quot; bitcoins will cause deflation in the long term due to positive non-zero reserve requirements, a fast increase in the money supply due to an adoption of Fractional-reserve banking can cause inflation in the medium term.<br /> <br /> Worth noting are the Keynesian economic arguments against [[Deflationary spiral|deflation]]; such that deflation tends to reduce profits and hence provides a dis-incentive for entrepreneurs to continue their operations. The &lt;span class=&quot;plainlinks&quot;&gt;[http://en.wikipedia.org/wiki/Austrian_School Austrian school]&lt;/span&gt; of thought adequately counters this theory, as deflation occurs in all stages of production and entrepreneurs also benefit from it. As a result, profit ratios tend to stay the same, 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 at all.<br /> <br /> 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.<br /> <br /> ==See also==<br /> <br /> * [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<br /> * [[Deflationary spiral]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Category:Economics]]</div>

Wickrick22