nakamoto-archive/docs/emails/dustin-trammel/2.md

---
layout: default
title: 'Re: Bitcoin v0.1 released'
date: 2009-01-13 07:55:20
grand_parent: Emails
parent: Dustin Trammel
nav_order: 2
---

# Re: Bitcoin v0.1 released

The email on the Cryptography Mailing List that announced Bitcoin publicly to the world.
{: .fs-6 .fw-300 } 

---

```
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: <CHILKAT-MID-4796e86e-a686-4a4b-2438-8bec9d82ecfe@server123>
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
```