Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement