Quote from: bdonlan on July 19, 2010, 06:53:04 AM

Quote from: Hepatizon on July 19, 2010, 05:56:44 AM

Quote from: Hepatizon on July 19, 2010, 05:56:44 AM

There's also the possibility that the entire transaction chain could fork if the latency between any two approximately equal computing groups becomes larger than the average block-creation time. Suppose that there is roughly the same about of computing power dedicated to hashing Bitcoin blocks in two groups, say the US and Russia. If - and I can only see this happening if the time between new blocks is very short - it takes more time for a US node to ask a Russian node what the longest block chain is (and vice versa) than it takes for the Russian (or US) Bitcoin network to generate a new block, then chains could develop local to Russia and the US. Suppose a node in the US and Russia successfully hash the next block at about the same time, call them blocks 1001us and 1001ru. The network resolves the discrepancy by seeing whether 1002us or 1002ru gets hashed first. But since there's a delay in getting information from one country to the other, every node in the US that checks a Russian node for their longest chain length gets out-of-date information, so it will see an older, shorter chain than the chain it gets from local, lower latency nodes. And the same thing happens to the Russians, with the end effect that American nodes keep working on the branch containing 1001us because they can only see an older, shorter version of the 10001ru branch, while the Russians work on theirs for the same reason. As long as the chain grows faster than the speed of information, neither chain will ever dominate the other.

Since the block production difficulty is automatically calibrated so that blocks come approximately 10 minutes apart from each other, it's unlikely that latency will ever get that high. In any case, though, all it takes is one or two blocks found in quick succession on one chain to throw things out of balance enough for the network to converge on one chain. This also won't affect normal transactions very much - they'll still go through, and generated coins are unusable until 120 blocks go by (by which point a winner should have emerged). The only risk is that someone might spend the same coin once on each of the two chains, to a different recipient - this could result in some confusion, but if you wait for 10-20 blocks to go by before accepting the transaction as 'confirmed', the risk of a fork should be acceptably low.

I don't think this scenario is particularly likely, especially not with the ~10 minutes between block creation. It could only happen if the block creation speed was raised considerably, and even then it would require two very equal computing groups. If it was 52-48 split I think the 52% group would eventually win out - I need to run some simulations. I'd also need to check how stable the two forks would be, and about how long it would take for one to trump the other. So file this under "bizarre doomsday scenario that's nearly impossible and might not even be that bad if it happens." As far as block creation time - I could see it having to be reduced substantially. Each block has a maximum size; if there is a constant time between blocks, then the maximum number of transactions that can be processed per unit time is (max block size) / (avg transaction size) / (block creation time). If BC takes off and we approach that number, then either max block size needs to go up or block creation time needs to go down. We'd have to choose option B a lot of times in a row for this scenario to become possible.

Hepatizon

Posts

Merits