6

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?

3 Answers 3

9

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.

3
  • Your first point is a good one. A node would only be able to verify the constraints I suggested if it received block announcements in real time. However, It's not immediately apparent to me that "you're now expanding the circle of people you trust to the people relaying the chain". And by that I mean: aren't you already (in the bitcoin network as it exists today) extending trust to relaying nodes anyway? I thought that this trust issue already existed, but that it poses no problem given the incentives of nodes to keep the network as a whole in a healthy state.
    – Will
    Jan 18, 2015 at 1:16
  • Also, I'm not sure what your 2nd paragraph is supposed to refute about the sentence of mine you quoted. Either way your answer as it stands is much appreciated though. :)
    – Will
    Jan 18, 2015 at 1:18
  • 1
    @Will aren't you already extending trust to relaying nodes Very little. They can avoid telling you about blocks, but as soon as you connect to one node that isn't cooperating in the embargo, you'll download the best chain.
    – Nick ODell
    Jan 18, 2015 at 2:40
8

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?"

5
  • Is your first statement really true? Not how I understood it ... I understood that if there are two equal length blocks that two miners solve at the same time, then it forks, until the next block is solved, and the longest is the winner, so temporary forks are something that can happen and is expected, but the odds of the fork happening is very low, and exponentially lower chance them both co-existing for every block added. Jan 18, 2015 at 1:00
  • 3
    Proof of work is calculated based on the target difficulty, not the header hash. (Of course, the hash must be <= the target for the block to be valid.) That means two blocks with the same parent will have the same proof of work, unless they're at a difficulty change boundary. If we didn't have difficulty changes, it would be correct to say the longest fork wins. As you say, accidental forks are fairly common but long accidental forks (>2 blocks) are extremely rare. Jan 18, 2015 at 1:16
  • Good point about nodes only being able to verify the constraints I suggested if it received block announcements in real time (in contrast to when downloading the chain afterward). Also, good point about difficulty changes, so +1 to this answer too.
    – Will
    Jan 18, 2015 at 1:22
  • 1
    @DavidA.Harding: Wouldn't even at a difficulty change boundary two blocks of the same height with a common parent have the same target? I think you would need to have a fork of at least two blocks length to have blocks at the same height with different targets.
    – Murch
    Jan 18, 2015 at 12:23
  • 1
    @Murch er, you are correct. I guess I didn't think that one through well enough. Thanks! Jan 18, 2015 at 13:25
1

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? :-)

2
  • 2
    While what you said is true, Bitcoin Core's checkpoints are mainly an artifact of the blocks-first download method employed in the 0.9.x series and before. With blocks-first, it's easy to feed a new node a valid-but-not-strongest chain with hundreds of gigabytes of useless transactions. With the new Bitcoin Core 0.10.0 headers-first method, that's no longer an issue and checkpoints aren't so important. It might even be possible to replace them with a chain-agnostic total-proof-of-work (chainwork) check. Jan 18, 2015 at 4:23
  • @DavidA.Harding, The checkpoints also serve to speed up signature verification (as scripts before the last checkpoint are not checked). Even with headers-first synchronization, the checkpoints are still useful to determine when to skip signature checking.
    – morsecoder
    Feb 10, 2015 at 4:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.