Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count) 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:


  
  Attacker privately starts mining their own chain, which diverges from the main chain at some block N.
  Attacker deposits coins to your business, sending them from address A. Call this transaction X.
  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.
  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.
  Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.
  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) &gt; CUTOFF_TIME:
        return false

    if child_chain_length(old_block) &gt; CUTOFF_CONFIRMATIONS:
        return false

    return child_chain_length(new_block) &gt; 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?
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.