From fce2ef87f844bcc071197dbf14186232d4e79a8e Mon Sep 17 00:00:00 2001 From: wakgill <76528604+wakgill@users.noreply.github.com> Date: Sat, 2 Jan 2021 00:20:21 -0600 Subject: [PATCH] Create 2.md --- docs/emails/dustin-trammel/2.md | 128 ++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 docs/emails/dustin-trammel/2.md diff --git a/docs/emails/dustin-trammel/2.md b/docs/emails/dustin-trammel/2.md new file mode 100644 index 0000000..99b5dca --- /dev/null +++ b/docs/emails/dustin-trammel/2.md @@ -0,0 +1,128 @@ +--- +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: +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" +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 +```