From: Satoshi Nakamoto <[email protected]>
Date: Mon, Apr 13, 2009 at 11:00 PM
To: Mike Hearn <[email protected]>
Subject: Re: Questions about BitCoin
Mike Hearn wrote:
>My best guess - it
>is the length of the global chain, and the rapid advance at the start
>is as the software downloads and verifies the preceding blocks in the
>chain as being valid.
Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
>If we assume that 0.1% is a good risk rate, then z=5 thus
>any transaction must wait a bit less than an hour before being
>solidified in the chain. As micropayments for things like web content
>or virtual goods are by definition something that requires low
>overhead, waiting an hour seems like quite a significant hurdle.
For the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers.
For micropayments, you can safely accept the payment immediately. The size of the payment is too small for the effort to steal it. Micropayments are almost always for intellectual property, where there's no physical loss to the merchant. Anyone trying to steal a micropayment would probably not be a paying customer anyway, and if they want to steal intellectual property they can use the file sharing networks.
Currently, businesses accept a certain chargeoff rate. I believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions.
The usual scam against a merchant that doesn't wait for confirming blocks would be to send a payment to a merchant, then quickly try to propagate a double-spend to the network before the merchant's copy. What the merchant can do is broadcast his transaction and then monitor the network for any double-spend copies. The thief would not be able to broadcast during the monitoring period or else the merchant's node would receive a copy. The merchant would only have to monitor for a minute or two until most of the network nodes have his version and it's too late for the thief's version to catch up and reach many nodes. With just a minute or two delay, the chance of getting away without paying could be made much too low to scam. A thief usually needs a high probability of getting an item for free to make it worthwhile. Using a lot of CPU power to do the brute force attack discussed in the paper in addition to the above scam would not increase the thief's chances very much.
Anything that grants access to something, like something that takes a while to download, access to a website, web hosting, a subscription or service, can be cancelled a few minutes later if the transaction is rejected.
>is confusing for me, because it appears the only way the honest chain
>can grow faster than a chain worked on by 1 attacking cpu is if the
>keyspace to scan looking for a partial collision is sharded evenly
>amongst the participating honest nodes. That way the speed at which
>collisions are found would be proportional to the number of nodes. Yet
>I don't see any discussion of such work sharding, which obviously adds
>complexity.
The keyspace is huge, 2^256. The thing being hashed includes the node's public key and a random nonce, so the chance of any two nodes duplicating work on the same space is negligible.
>How is the required difficulty of each block communicated through the
>network and agreed upon?
It's not communicated. The formula is hardcoded in the program and every node does the same calculation to know what difficulty is required for the next block. If someone diverged from the formula, their block would not be accepted by the majority.
>Thanks once again. I have yet more questions but this is enough for
>one email :) I will be happy to summarize these discussions into an
>FAQ-like document at some point. Apologies if the questions seem
>trivial.
No problem, thanks for testing it on Mac Wine.
Satoshi