Satoshi Nakamoto

2012-03-08T08:15:13Z

T18ftw:

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

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

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

==Possible Motives==

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

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

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

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

==Possible identity==

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

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

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

==References==
<references/>

[[de:Satoshi Nakamoto]]

Network

2012-03-08T08:10:22Z

T18ftw:

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is currently not supported.

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

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

== Connection ==

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

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

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. ''addr'' messages often contain only one address, but sometimes contain up to 1000. This is most common at the beginning of an exchange.

== Standard relaying ==

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

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

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

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

== Initial block download ==

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

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

== Bootstrapping ==

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

Bitcoin has three methods of finding peers.

=== Addr ===

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

Bitcoin comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.

The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node.

=== DNS ===

Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is intended to replace the IRC seeding mechanism in future releases.

=== IRC ===

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

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

== Heartbeat ==

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

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

== See Also ==

* [[Protocol Specification]]
* [http://bitcoinstatus.rowit.co.uk/ Current Network Status]
* [http://ubg.com.uy/ Network Researchers]

[[Category:Technical]]

[[pl:Sieć]]

Bitcoin Wiki - User contributions [en]

Satoshi Nakamoto

Network