Mar 14th, 2014
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. From satoshi@vistomail.com Tue Jan 13 07:55:20 2009
  2. Return-Path: <satoshi@vistomail.com>
  3. Delivered-To: dustintrammell-dtrammell@dustintrammell.com
  4. Received: (qmail 27444 invoked from network); 13 Jan 2009 07:55:20 -0000
  5. Received: from anonymousspeech.com (HELO mail.anonymousspeech.com)
  6. ( by oaklabs.net with SMTP; 13 Jan 2009 07:55:20 -0000
  7. Received: from server123 ([]) by anonymousspeech.com with
  8. MailEnable ESMTP; Tue, 13 Jan 2009 15:55:13 +0800
  9. MIME-Version: 1.0
  10. Date: Tue, 13 Jan 2009 15:39:31 +0800
  11. X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
  12. X-Priority: 3 (Normal)
  13. Subject: Re: Bitcoin v0.1 released
  14. Content-Type: text/plain
  15. From: "Satoshi Nakamoto" <satoshi@vistomail.com>
  16. Reply-To: satoshi@vistomail.com
  17. To: dtrammell@dustintrammell.com
  18. Message-ID: <CHILKAT-MID-4796e86e-a686-4a4b-2438-8bec9d82ecfe@server123>
  19. X-Evolution-Source: pop://dustintrammell-dtrammell@mail.oaklabs.net/
  20. Content-Transfer-Encoding: 8bit
  22. > It actually posts the hash blocks to a Google Group called
  23. > 'proof-hashes', so similar result as if it were posting to Usenet.
  24. >
  25. > http://groups.google.com/group/proof-hashes
  26. >
  27. > Since I run that group, and it's sole purpose is to archive
  28. > proof-of-work hashes, feel free to join an account to have your system
  29. > post there as well if you like.
  31. Sweet, I was looking for a group like that on Usenet at one point to see
  32. what I would use if I needed, and nothing really fit. I'm sure Google
  33. groups is a lot easier to post to.
  35. There are some scenarios where a Usenet or Google group could be used as
  36. a supplemental defence. Bitcoin is at its most vulnerable in the
  37. beginning when the total network CPU power is small. That's offset by
  38. the fact that the incentive to attack it is also low when it's small.
  39. Hopefully the easy solution of just growing up and getting past that
  40. stage will work. If not, there are ways a Google group could help, if
  41. it really came to that.
  44. > Electronic currency and cryptography are two things that I am very
  45. > interested in so as you would assume I was drawn to this project
  46. > immediately when I saw it posted to the Cryptography email list. Feel
  47. > free to ping me for feedback or to test out new features, I'll be happy
  48. > to help out.
  50. We definitely have similar interests!
  52. You know, I think there were a lot more people interested in the 90's,
  53. but after more than a decade of failed Trusted Third Party based systems
  54. (Digicash, etc), they see it as a lost cause. I hope they can make the
  55. distinction, that this is the first time I know of that we're trying a
  56. non-trust based system.
  59. > When the
  60. > coins mature, will that generate a new 'credit' transaction, or will the
  61. > existing generation transaction line's credit field be updated?
  63. The existing transaction line will change.
  66. > Upon opening version 0.1.3, all four of my transaction entries still say
  67. > 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'.
  68. > Does this mean that some other node had extended the chain first and my
  69. > coins were generated in a dead branch? If so, why did the previous
  70. > instance of the software not detect this immediately and begin
  71. > generating coins in the winning branch? Bug in 0.1.0?
  73. You're right, sorry about that. It's the bug that was fixed in 0.1.3.
  74. The communications thread would get blocked, so you would make
  75. connections, but they would go silent after a while. When you found a
  76. block, you couldn't broadcast it to the network, so it didn't get into
  77. the chain. You weren't receiving anything either to know that the
  78. network had gone on without you, until you restarted it.
  80. The bug is also what caused bitcoin.exe to fail to exit. The
  81. communications thread was blocked and failed to exit. Bitcoin does a
  82. careful shutdown in case it might be in the middle of an important
  83. transaction, but actually it's completely safe to kill it.
  85. This is all fixed in 0.1.3. If you give me your IP, I'll send you some
  86. coins.
  89. > One other question I had... What prevents the single node with the most
  90. > CPU power from generating and retaining the majority of the BitCoins?
  91. > If every node is working independently of all others, if one is
  92. > significantly more powerful than the others, isn't it probable that this
  93. > node will reach the proper conclusion before other nodes? An
  94. > underpowered node may get lucky once in a while, but if they are at a
  95. > significant horsepower advantage I would expect the majority of BitCoins
  96. > to be generated by the most powerful node.
  98. It's not like a race where if one car is twice as fast, it'll always
  99. win. It's an SHA-256 that takes less than a microsecond, and each guess
  100. has an independent chance of success. Each computer's chance of finding
  101. a hash collision is linearly proportional to it's CPU power. A computer
  102. that's half as fast would get half as many coins.
  105. > I'll watch this instance and see how it goes...
  107. Let me know how it goes. If you have any trouble with it, send me your
  108. debug.log file. I can often figure out what went wrong just from that.
  110. Satoshi
RAW Paste Data