On Jan 14th, 2009, Satoshi Nakamoto sent me 25.0 BTC in a single transaction. The address that my wallet provided to receive the bitcoin was:
I have previously published in 2013 the entirety of my email correspondence with Satoshi. The intent to send me “some coins” was documented in an email from “Satoshi Nakamoto <firstname.lastname@example.org>” on Jan 13th 2009 at 01:55 entitled “Re: Bitcoin v0.1 released” (Appendix A.1) when Satoshi said:
This is all fixed in 0.1.3. If you give me your IP, I’ll send you some coins.Satoshi Nakamoto
To this, I responded in a subsequent email dated Jan 13th 2009 at 18:40 entitled “Re: Bitcoin v0.1 released” (Appendix A.2):
I’m currently at 22.214.171.124, but that’s dynamic so it may change. I’veDustin D. Trammell
had that address for a while though so hopefully my dhcp client is being
successful at renewing and not losing my address. It does change from
time to time, but that address should be good for a while.
In the first few publicly-available versions of the software, you could send bitcoin by either bitcoin address or by IP address. Connecting by IP address would allow the receiving wallet to provide to the sending wallet a recipient bitcoin address for the coins to be received by on-chain. The recipient address chosen and provided by my wallet was
The transaction information from my wallet is as follows:
Address: 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi Date: 1/14/2009 19:46 From: Satoshi To: 126.96.36.199 Credit: 25.00000000 BTC Net amount: +25.00000000 BTC Message: Hello Transaction ID: d71fd2f64c0b34465b7518d240c00e83f6a5b10138a7079d1252858fe7e6b577 Transaction total size: 275 bytes Transaction virtual size: 275 bytes Output index: 0
Proof that I control address
1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi can be cryptographically confirmed using most Bitcoin wallet software with the following message and signature:
Address 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi is owned by Dustin D. Trammell
The 25.0 BTC that arrived at my address originated from the following address:
This address previously contained a total of 50.0 BTC. The software’s behavior at the time (later changed to use a new address every time) was to use the originating address as the “change” address, so the “change” address in the transaction was the originating address, causing the remainder 25.0 BTC to be sent back to the originating address.
1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9, other than the transaction to send 25.0 BTC to my address with the change returning to the originating address, there is only one other associated transaction which is a mined block issuing its block reward to this address on Jan 12th 2009. This transaction can be identified by transaction ID:
Satoshi clearly controlled this address at the time in order to send me 25.0 BTC from it, and the transaction details were negotiated in private email with Satoshi at the time, so it is therefore presumable that Satoshi mined block 286 that originally funded the address.
From email@example.com Tue Jan 13 07:55:20 2009 Return-Path: firstname.lastname@example.org Delivered-To: email@example.com Received: (qmail 27444 invoked from network); 13 Jan 2009 07:55:20 -0000 Received: from anonymousspeech.com (HELO mail.anonymousspeech.com) (188.8.131.52) by oaklabs.net with SMTP; 13 Jan 2009 07:55:20 -0000 Received: from server123 ([184.108.40.206]) by anonymousspeech.com with MailEnable ESMTP; Tue, 13 Jan 2009 15:55:13 +0800 MIME-Version: 1.0 Date: Tue, 13 Jan 2009 15:39:31 +0800 X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com) X-Priority: 3 (Normal) Subject: Re: Bitcoin v0.1 released Content-Type: text/plain From: "Satoshi Nakamoto" firstname.lastname@example.org Reply-To: email@example.com To: firstname.lastname@example.org Message-ID: X-Evolution-Source: pop://email@example.com/ Content-Transfer-Encoding: 8bit > It actually posts the hash blocks to a Google Group called > 'proof-hashes', so similar result as if it were posting to Usenet. > > http://groups.google.com/group/proof-hashes > > Since I run that group, and it's sole purpose is to archive > proof-of-work hashes, feel free to join an account to have your system > post there as well if you like. Sweet, I was looking for a group like that on Usenet at one point to see what I would use if I needed, and nothing really fit. I'm sure Google groups is a lot easier to post to. There are some scenarios where a Usenet or Google group could be used as a supplemental defence. Bitcoin is at its most vulnerable in the beginning when the total network CPU power is small. That's offset by the fact that the incentive to attack it is also low when it's small. Hopefully the easy solution of just growing up and getting past that stage will work. If not, there are ways a Google group could help, if it really came to that. > Electronic currency and cryptography are two things that I am very > interested in so as you would assume I was drawn to this project > immediately when I saw it posted to the Cryptography email list. Feel > free to ping me for feedback or to test out new features, I'll be happy > to help out. We definitely have similar interests! You know, I think there were a lot more people interested in the 90's, but after more than a decade of failed Trusted Third Party based systems (Digicash, etc), they see it as a lost cause. I hope they can make the distinction, that this is the first time I know of that we're trying a non-trust based system. > When the > coins mature, will that generate a new 'credit' transaction, or will the > existing generation transaction line's credit field be updated? The existing transaction line will change. > Upon opening version 0.1.3, all four of my transaction entries still say > 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'. > Does this mean that some other node had extended the chain first and my > coins were generated in a dead branch? If so, why did the previous > instance of the software not detect this immediately and begin > generating coins in the winning branch? Bug in 0.1.0? You're right, sorry about that. It's the bug that was fixed in 0.1.3. The communications thread would get blocked, so you would make connections, but they would go silent after a while. When you found a block, you couldn't broadcast it to the network, so it didn't get into the chain. You weren't receiving anything either to know that the network had gone on without you, until you restarted it. The bug is also what caused bitcoin.exe to fail to exit. The communications thread was blocked and failed to exit. Bitcoin does a careful shutdown in case it might be in the middle of an important transaction, but actually it's completely safe to kill it. This is all fixed in 0.1.3. If you give me your IP, I'll send you some coins. > One other question I had... What prevents the single node with the most > CPU power from generating and retaining the majority of the BitCoins? > If every node is working independently of all others, if one is > significantly more powerful than the others, isn't it probable that this > node will reach the proper conclusion before other nodes? An > underpowered node may get lucky once in a while, but if they are at a > significant horsepower advantage I would expect the majority of BitCoins > to be generated by the most powerful node. It's not like a race where if one car is twice as fast, it'll always win. It's an SHA-256 that takes less than a microsecond, and each guess has an independent chance of success. Each computer's chance of finding a hash collision is linearly proportional to it's CPU power. A computer that's half as fast would get half as many coins. > I'll watch this instance and see how it goes... Let me know how it goes. If you have any trouble with it, send me your debug.log file. I can often figure out what went wrong just from that. Satoshi
From firstname.lastname@example.org Tue Jan 13 18:40:28 2009 Subject: Re: Bitcoin v0.1 released From: "Dustin D. Trammell" <email@example.com> To: firstname.lastname@example.org In-Reply-To: <CHILKAT-MID-4796e86e-a686-4a4b-2438-8bec9d82ecfe@server123> References: <CHILKAT-MID-4796e86e-a686-4a4b-2438-8bec9d82ecfe@server123> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6Uj1TgItQqnGup73toZt" Message-Id: <1231893628.9962.116.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Dropline GNOME Date: Tue, 13 Jan 2009 18:40:28 -0600 X-Evolution-Format: text/plain X-Evolution-Account: 1169982963.29994.8@slimer X-Evolution-Transport: smtp://dustintrammell-dtrammell;auth=CRAM-MD5@mail.oaklabs.net/;use_ssl=always X-Evolution-Fcc: mbox:/home/druid/.evolution/mail/local#Sent --=-6Uj1TgItQqnGup73toZt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-01-13 at 15:39 +0800, Satoshi Nakamoto wrote: > Sweet, I was looking for a group like that on Usenet at one point to see > what I would use if I needed, and nothing really fit. I'm sure Google > groups is a lot easier to post to. Yea, that particular group is completely open, you don't have to join to post (in fact I think I made it difficult for people to actually join), you just email email@example.com and the content of the email gets posted to the group. > There are some scenarios where a Usenet or Google group could be used as > a supplemental defence. Bitcoin is at its most vulnerable in the > beginning when the total network CPU power is small. That's offset by > the fact that the incentive to attack it is also low when it's small. > Hopefully the easy solution of just growing up and getting past that > stage will work. If not, there are ways a Google group could help, if > it really came to that. Yea, I was thinking you could have a client post the current block chain every 10k blocks or something, just to occasionally document the current winning proof-of-work chain. > We definitely have similar interests! Indeed. > You know, I think there were a lot more people interested in the 90's, > but after more than a decade of failed Trusted Third Party based systems > (Digicash, etc), they see it as a lost cause. I hope they can make the > distinction, that this is the first time I know of that we're trying a > non-trust based system.=20 Yea, that was the primary feature that caught my eye. The real trick will be to get people to actually value the BitCoins so that they become currency. Currently, they're just collections of bits... > This is all fixed in 0.1.3. If you give me your IP, I'll send you some > coins. I'm currently at 220.127.116.11, but that's dynamic so it may change. I've had that address for a while though so hopefully my dhcp client is being successful at renewing and not losing my address. It does change from time to time, but that address should be good for a while. > It's not like a race where if one car is twice as fast, it'll always > win. It's an SHA-256 that takes less than a microsecond, and each guess > has an independent chance of success. Each computer's chance of finding > a hash collision is linearly proportional to it's CPU power. A computer > that's half as fast would get half as many coins. Ahh I see... So each guess is like the spin of a roulette wheel, completely independent from all other guesses and the extra CPU power just translates to more successful guesses than anyone else. Unfortunately my ability to understand complex mathematics is conversely proportional to how interested I am in cryptography (: > Let me know how it goes. If you have any trouble with it, send me your > debug.log file. I can often figure out what went wrong just from that. Will do... --=20 Dustin D. Trammell firstname.lastname@example.org http://www.dustintrammell.com --=-6Uj1TgItQqnGup73toZt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBJbTR59zsZk8QKxrkRAurUAJ95x1lb27KMZyLMpyzJP0BICoDEkwCeOt8W 0NGNPMOAVfeU9mCvVlSQ2WA= =J8Ru -----END PGP SIGNATURE----- --=-6Uj1TgItQqnGup73toZt--