69. Emails to Dustin Trammell

69

Emails to DustinTrammell

THE FOLLOWING are direct email exchanges between Satoshi Nakamoto and Dustin Trammell that Dustin Trammell has generously made available for publication.

Email 1—Timestamp and bitcoin maturity

This first exchange concerns timestamp document services and Bitcoin mining maturity. These were discussed later in a public forum, but Satoshi addressed them first in a private conversation with Dustin Trammell.

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Tue, 13 Jan 2009 02:33:28 +0800

Subject: Re: Bitcoin v0.1 released

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 timethat 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 amagazine 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

Email 2—Follow up

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Tue, 13 Jan 2009 15:55:13 +0800

Subject: Re: Bitcoin v0.1 released

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 archiveproof-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 pointto see what I would use if I needed, and nothing really fit. I’m sureGoogle 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 the90’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 detectthis 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 youfound 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

Email 3—On Bitcoin’s potential

This exchange seems to indicate that Satoshi was not expecting such rapid acceptance of Bitcoin.

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Fri, 16 Jan 2009 03:15:14 +0800

Subject: Re: Bitcoin v0.1 released

I’ve had that address for a while though so hopefully mydhcp 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:

[e-mail] 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 the90’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 useby 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 fewcents 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

Email 4—On attacks and IP addresses involved in sending bitcoins

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Fri, 16 Jan 2009 03:46:30 +0800

Subject: Re: A few thoughts . . .

I group attacks into two classes:

1) Attacks that can only be done by someone actually in the chain of communication

2) Attacks that can be done by anyone on the Internet from anywhere

Type 1 exposes you to people in your house or company on your local LAN, admins at ISPs in between, and the LAN on the recipient’s side. Type 2 exposes you to a billion people who can self-select to be attackers and get economy of scale when they develop one technique to attack multiple victims.

Sending by IP requests a new public key, so yes, it’s vulnerable to type 1 man-in-the-middle. If that’s a concern, sending to a

Bitcoin address doesn’t have that vulnerability, although there’s a small privacy tradeoff. I have a feeling most of the time people will get Bitcoin addresses off of non-SSL websites and unsigned cleartext e-mail, which is already vulnerable to type 1 and type 2 through DNS poisoning.

One solution would be to use both the IP and Bitcoin addresses when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses the public key of the Bitcoin address to sign the new public key to prove that you’re sending to who you think you are. If the system starts to be used for real business purposes, I will certainly implement that. Another solution is to use SSL.

For now, it’s pretty obvious that if you send to an IP, you didn’t give any other identifying information about the recipient, so you’re blindly sending to whoever answers that IP.

Another feature for later is an option to encrypt your wallet.

If I understand how that is done correctly, you just compute the transaction into the block chain and let the intended recipient‘discover’ it, correct?

That’s correct.

An alternative could be to allow the network nodes to provide a resolution service, where they ask around for the network address of a

BitCoin address, and if that node is online, once a consensus is agreed upon by the network for that address the sending BitCoin application connects directly there.

It would be nice to only need the Bitcoin address and have the IP worked out behind the scenes. Might have privacy or denial of service issues. Certainly before another sending method isimplemented, there’s plenty of time now to fully think through the design and make sure it’s the best way.

Satoshi

Email 5—On potential loss and the need for backup

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Sat, 17 Jan 2009 02:32:48 +0800

Subject: Re: A few thoughts . . .

One thing that came to mind on this topic is the potential forBitCoin

loss if you have a system failure. The application doesn’t seem to store any data in the directory that it runs in, so I assumeit’s stored in the registry and other places (haven’t crackedout ProcessExplorer yet to check myself), so it may be a good idea to have the application be able to export everything that it needs for recovery to a file that could be backed up off of the system.

The files are in “%appdata%\Bitcoin”, that’s the directory to backup. The data is stored in a transactional database DBM, so it should be safe from loss if there’s a crash or power failure.

%appdata% is per-user access privilege. Most new programs like Firefox store their settings files there, despite the headwind of Microsoft changing the directory name with every Windows release and being full of spaces and so long it runs off the screen.

One other thing I noticed today is that if you close the application it doesn’t appear to cleanly close it’s network sockets (TCP RST’s start flying). Probably an item for the lowpriority todo list (:

Just now added code to the next release for that.

Satoshi

Email 6—Satoshi sent bitcoins

From: “Satoshi Nakamoto” [e-mail]

To: [e-mail]

Date: Mon, 19 Jan 2009 00:54:32 +0800

Subject: Re: Bitcoin Transfer

It should be your Bitcoin address at home that you received it with. There’s no way for it to know who it’s from, so the best it can do is tell which of your addresses it was received on.

You can create multiple addresses and give a different address to each person and label them to help figure out who’s sending to you.

It doesn’t know any names other than what you tell it. The name printed there is what’s associated in your address book for that address, either under the Address Book button or the “Change...” button to the right of your Bitcoin address.

Hey Satoshi,

After that first transfer of 25.00, you didn’t send me another100.00

did you? I sent myself 100.00 from my BitCoin application at work to my one at home using the BitCoin address rather than by IP. My application at home has a 100.00 transfer received, however it’s transaction details say

“Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv”.

That is not my BitCoin address from work, so I assume this means that I received the payment encoded with a block that was computed by your client? If so, how did it know your name in addition to the BitCoin address that generated it? I don’t recall there being a place in my application to even put my name.

--

Dustin D. Trammell

[e-mail]

http://www.dustintrammell.com