Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)

Question

In Bitcoin's proof-of-work system, consensus on which chain of blocks should be considered the "true" block chain is based only(?) on which chain is longer.

Accordingly, to quote a nicely written answer by Nate Eldredge, a typical 51% attack would look like this:

1. Attacker privately starts mining their own chain, which diverges from the main chain at some block N.

2. Attacker deposits coins to your business, sending them from address A. Call this transaction X.

3. Attacker inserts in his own chain a transaction X' which conflicts with X; typically X' sends the coins from address A to another address belonging to the attacker.

4. Attacker waits for several confirmations of transaction X, in blocks N+1, ..., N+6 (replace 6 with however many confirmations your business wants) of the main chain.

5. Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.

6. Attacker releases his own chain, which now has blocks up to, say, N+50. Being longer, this chain is accepted by the network. This chain doesn't contain the transaction X but instead X', so you don't have the coins you thought you did.

Notice that up until Step 6, everything on the network looks completely normal; only the attacker knows what is going on.

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

To summarize this idea in pseudocode:

CUTOFF_TIME = 1200 # seconds
CUTOFF_CONFIRMATIONS = 3

is_acceptable_block(new_block, parent_block):
    if not is_valid_block(new_block):
        return false

    if is_first_child(new_block, parent_block):
        return true

    old_block = get_first_child(parent_block)

    if age_difference(new_block, old_block) > CUTOFF_TIME:
        return false

    if child_chain_length(old_block) > CUTOFF_CONFIRMATIONS:
        return false

    return child_chain_length(new_block) > child_chain_length(old_block)

If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

Answer 1

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

Because you can't prove that to nodes that weren't on the network at the time of the attack. Which means that either:

• It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it will lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.

• If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.

If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

A 51% attack can double-spend outputs with any number of confirmations. The oft-quoted 6 confirmations figure comes from the Bitcoin paper, where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.

Answer 2

First, a quick clarification: assuming two chains both have valid blocks, it's the chain with the most proof of work that wins, not necessarily the chain with the most blocks.

Second, thanks for the psuedocode. It's always nice answering a question written in clear code.

The answer is that we want nodes to be able to agree on the best block chain based entirely on the data in the block chain. That is, there should be no external state.

Why? Because different nodes might have different external state. Let's say an attacker manages to partition the network so that everyone in Europe is working on one chain and everyone in North America is working on a different chain:

        /--> C  -> D  -> E  -> F  -> G  Europe Chain
A -> B -
        \--> C` -> D` -> E` -> F`       North America Chain

Because these two forks are more than 3 blocks different, even when full networking is restored, your code prevents nodes and miners in North America from switching over to the stronger European chain---meaning the network will remained forked forever.

I find it useful to always ask myself, "how will new nodes that are downloading the block chain for the first time come to consensus with currently active nodes in a trustless manner?"

Answer 3

This sort of exists with checkpoints. The Bitcoin Core source contains a list of hashes of blocks at particular heights, and the standard client will refuse any chain that doesn't contain those blocks at those heights, so it won't accept a fork that diverges before the latest checkpoint. Periodically the Bitcoin Core maintainers will add to this list, to include some more relatively recent (but not too recent) blocks.

To get a sense for how recent, the latest checkpoint in the git repository for Bitcoin Core is at height 295000 (mined in April 2014), and the current height is 339431. So it won't accept any fork that tries to reverse more than 44431 blocks, or about 9 months of work. Feel better now? :-)