Re: Bitcoin v0.1 released

Private email with Dustin Trammell · 12 messages · from 12 January 2009 · with Dustin D. Trammell, Satoshi Nakamoto

Dustin D. Trammell to satoshi@vistomail.com · 12 January 2009, 05:14 UTC · original

On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:
Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.

I'm currently reading through your paper. At the timestamp server section you mention newspapers and usenet, so I thought you might be interested in this if you have not seen it already: http://www.publictimestamp.org/ By the way, I'm also currently running the alpha code on one of my workstations. So far it has two "Generated" messages, however the "Credit" field for those is 0.00 and the balance hasn't changed. Is this due to the age/maturity requirement for a coin to be valid? Cheers, -- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

Dustin D. Trammell to satoshi@vistomail.com · 12 January 2009, 05:14 UTC · original

On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:
Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.

Satoshi Nakamoto to dtrammell@dustintrammell.com · 12 January 2009, 18:33 UTC · original

I'm currently reading through your paper. At the timestamp server section you mention newspapers and usenet, so I thought you might be interested in this if you have not seen it already: http://www.publictimestamp.org/

Thanks, I hadn't seen that yet. It looks very well presented. There was an older one that's been running for a long time that publishes its hashes to Usenet. I'm surprised this one isn't using Usenet, although it is kind of difficult to get access to post to Usenet in an automated way these days. If they can get a magazine or newspaper to publish their hashes, it would work a lot easier in court for their purposes. Bitcoin and all timestamp servers share the basic functionality of periodically collecting things into blocks and hashing them into a chain.

By the way, I'm also currently running the alpha code on one of my workstations. So far it has two "Generated" messages, however the "Credit" field for those is 0.00 and the balance hasn't changed. Is this due to the age/maturity requirement for a coin to be valid?

Right, the credit field stays 0.00 until it matures, then it'll be 50.00. Do you think it would be clearer if I left the credit field blank until it matures? I should put some text in the transaction details (when you double click on it) explaining how it works. (was it obvious you can doubleclick on a line for details?) Be sure to upgrade to v0.1.3 if you haven't already. This version has really stabilized things. Satoshi

Dustin D. Trammell to satoshi@vistomail.com · 13 January 2009, 03:29 UTC · original

On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
Thanks, I hadn't seen that yet. It looks very well presented. There was an older one that's been running for a long time that publishes its hashes to Usenet. I'm surprised this one isn't using Usenet, although it is kind of difficult to get access to post to Usenet in an automated way these days. If they can get a magazine or newspaper to publish their hashes, it would work a lot easier in court for their purposes. Bitcoin and all timestamp servers share the basic functionality of periodically collecting things into blocks and hashing them into a chain.

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.

Right, the credit field stays 0.00 until it matures, then it'll be 50.00. Do you think it would be clearer if I left the credit field blank until it matures? I should put some text in the transaction details (when you double click on it) explaining how it works. (was it obvious you can doubleclick on a line for details?)

No, I think having $0.00 there is more appropriate than being blank. The entries in my BitCoin software (4 of them now) all say 'unconfirmed' however, so I'm not sure what that means, but I did grok that the coins were generated and just not 'mature' yet, but I had also read your whitepaper so I may have understood that concept from there. When the coins mature, will that generate a new 'credit' transaction, or will the existing generation transaction line's credit field be updated? No, I was unaware that you could double-click a transaction line for further details... I just did that and it currently just has the same information there that is in the transaction line. Putting more information there would definitely be useful.

Be sure to upgrade to v0.1.3 if you haven't already. This version has really stabilized things.

I was running 0.1.1... I will update now. Perhaps a new version notification or auto-update feature is in order? (: 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. Cheers, -- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

Dustin D. Trammell to satoshi@vistomail.com · 13 January 2009, 03:40 UTC · original

On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
Be sure to upgrade to v0.1.3 if you haven't already. This version has really stabilized things.

Two issues with upgrading: When closing my previous version (help said 0.1.1 but I think it was really 0.1.0), the process did not exit. The UI exited but the process remained. I had to manually kill the process before I was able to start version 0.1.3. 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? I'll watch this instance and see how it goes... Thanks, -- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

Satoshi Nakamoto to dtrammell@dustintrammell.com · 13 January 2009, 07:39 UTC · original

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

Dustin D. Trammell to satoshi@vistomail.com · 14 January 2009, 00:40 UTC · original

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.

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... -- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

Satoshi Nakamoto to dtrammell@dustintrammell.com · 15 January 2009, 19:10 UTC · original

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.

There's at least one node who's inbound IP keeps changing all the time within the same class B. Maybe every time the program is run. I wasn't expecting that. Do you mind if I CC the rest of this to bitcoin-list or Cryptography? BTW, bitcoin-list is: bitcoin-list@lists.sourceforge.net Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

Dustin D. Trammell wrote: > Satoshi Nakamoto wrote: > 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. 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.

Hal sort of alluded to the possibility that it could be seen as a long-odds investment. I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the TTP gets cold feet. Even if it doesn't take off straight away, it's now available for use by the next guy who comes up with a plan that needs some kind of token or electronic currency. It could get started in a closed system or narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. "Send X bitcoins to my priority hotline at this IP and I'll read the message personally." Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial. Satoshi

Dustin D. Trammell to satoshi@vistomail.com · 16 January 2009, 01:14 UTC · original

On Fri, 2009-01-16 at 03:10 +0800, Satoshi Nakamoto wrote:
There's at least one node who's inbound IP keeps changing all the time within the same class B. Maybe every time the program is run. I wasn't expecting that.

Pretty sure that's not me. My BitCoin application at work should be coming from our static NAT address and my connection at home has had the IP that I gave you for at least 3 days now (that I've been transferring coins between them for test purposes).

Do you mind if I CC the rest of this to bitcoin-list or Cryptography?

Sure, no problem.

BTW, bitcoin-list is: bitcoin-list@lists.sourceforge.net Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list

I'll join right now, thanks (:

Hal sort of alluded to the possibility that it could be seen as a long-odds investment. I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the TTP gets cold feet.

Yes, I saw that message and was one of the other reasons I started up a node so quickly. My systems aren't doing much of anything else while idle, so why not create BitCoins? And if they're worth something someday...? Bonus!

Even if it doesn't take off straight away, it's now available for use by the next guy who comes up with a plan that needs some kind of token or electronic currency. It could get started in a closed system or narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.

I can see how various types of sites that have a need for micropayments could use them, however I also see an impedement to adoption if they want to use an existing BitCoin peer group rather than a closed system since they would first have to generate enough coins to support what they intend to do (or buy them from someone else). A closed system obviously doesn't have that problem.

It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. "Send X bitcoins to my priority hotline at this IP and I'll read the message personally."

Interesting application (:

Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.

Another good idea. -- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com

Satoshi Nakamoto to dtrammell@dustintrammell.com · 16 January 2009, 16:03 UTC · original

Dustin D. Trammell wrote: > Satoshi Nakamoto wrote: > 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. 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.

I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite. It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. "Send X bitcoins to my priority hotline at this IP and I'll read the message personally." Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial. It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. Satoshi Nakamoto http://www.bitcoin.org

Satoshi Nakamoto to dtrammell@dustintrammell.com · 16 January 2009, 16:03 UTC · original

Dustin D. Trammell wrote: > Satoshi Nakamoto wrote: > 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. 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.

The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

Satoshi Nakamoto to dtrammell@dustintrammell.com · 25 January 2009, 15:47 UTC · original

Hal Finney wrote:
> * Spammer botnets could burn through pay-per-send email filters > trivially If POW tokens do become useful, and especially if they become money, machines will no longer sit idle. Users will expect their computers to be earning them money (assuming the reward is greater than the cost to operate). A computer whose earnings are being stolen by a botnet will be more noticeable to its owner than is the case today, hence we might expect that in that world, users will work harder to maintain their computers and clean them of botnet infestations.

Another factor that would mitigate spam if POW tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They'd essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don't read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective. The process has the potential to establish the POW token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers. Interestingly, one of the e-gold systems already has a form of spam called "dusting". Spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field. If the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam. Satoshi Nakamoto