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:
1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdiI 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 <satoshi@vistomail.com>” 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 24.28.79.95, but that’s dynamic so it may change. I’ve
Dustin 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 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi.
The transaction information from my wallet is as follows:
Address: 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi
Date: 1/14/2009 19:46
From: Satoshi
To: 24.28.79.95
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: 0Proof that I control address 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi can be cryptographically confirmed using most Bitcoin wallet software with the following message and signature:
Message:
Address 1DCbY2GYVaAMCBpuBNN5GVg3a47pNK1wdi is owned by Dustin D. TrammellSignature:
HGiWX71TZDZXq7hknuwqezxyaoVA5YJIaw22LGKYfeSqak6aaRyW0OYPaRgs68370+/7I8LtX2l4GaP6SCi/uVA=The 25.0 BTC that arrived at my address originated from the following address:
1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9This 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.
Analyzing 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:
00ff9e64c9a2e7793e6f8c2b04072b4b22648cdedd46cd1c3ae3d6a23c8ec1ebSatoshi 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.
Appendix A.1
From satoshi@vistomail.com Tue Jan 13 07:55:20 2009
Return-Path: satoshi@vistomail.com
Delivered-To: dustintrammell-dtrammell@dustintrammell.com
Received: (qmail 27444 invoked from network); 13 Jan 2009 07:55:20 -0000
Received: from anonymousspeech.com (HELO mail.anonymousspeech.com)
(124.217.253.42) by oaklabs.net with SMTP; 13 Jan 2009 07:55:20 -0000
Received: from server123 ([124.217.253.42]) 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" satoshi@vistomail.com
Reply-To: satoshi@vistomail.com
To: dtrammell@dustintrammell.com
Message-ID:
X-Evolution-Source: pop://dustintrammell-dtrammell@mail.oaklabs.net/
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
Appendix A.2
From dtrammell@dustintrammell.com Tue Jan 13 18:40:28 2009
Subject: Re: Bitcoin v0.1 released
From: "Dustin D. Trammell" <dtrammell@dustintrammell.com>
To: satoshi@vistomail.com
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 proof-hashes@googlegroups.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 24.28.79.95, 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
dtrammell@dustintrammell.com
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--