Largest Chain Spilt / Merge to date.

[bytemaster]

What is the largest chain split and merge to date by time?

[1714974905]

1714974905

[1714974905]

1714974905

[1714974905]

1714974905

[1714974905]

1714974905

[starsoccer9]

most likely the march 2013.

http://bitcoin.org/en/alert/2013-03-11-chain-fork

[bytemaster]

most likely the march 2013.

http://bitcoin.org/en/alert/2013-03-11-chain-fork

How many blocks long was it

[kjj]

The signed/unsigned fork may have been longer.  I'm not sure.

I think that the record for typical latency race fork is 2 deep.

[bytemaster]

The signed/unsigned fork may have been longer.  I'm not sure.

I think that the record for typical latency race fork is 2 deep.

Why was 100 blocks chosen for mining delay?

[XertroV]

Very quick BOTE calculation with regards to this:

Approx 25 chainforks (of depth 1) per 3000 blocks. http://blockchain.info/orphaned-blocks

So approx a 1/120 chance (or less) to have a chainfork when a block is produced.

For two chianforks you need at least this chance twice. In reality it's less probable because simply squaring the chance would include a one of two second chainforks that would spring from one block, instead of one from each.

Rough estimate of a two length chainfork < (1/120)^2 = 0.0000694...

We've had ~240000 blocks, so we'd expect about 16 chainforks of length 2 thus far.

If we look at chainforks of length 3, we see the expected amount is less than 0.14, which would line up with reality (excluding March this year)


Bytemaster, if you want I've got a python script I wrote a few days ago to simulate network propagation of blocks.

[XertroV]

The signed/unsigned fork may have been longer.  I'm not sure.

I think that the record for typical latency race fork is 2 deep.

Why was 100 blocks chosen for mining delay?

There is a protocol rule which prohibits generated BTC from being spent until it has 100 confirmations. The Satoshi client has an additional safety margin: it won't let you spend generated BTC until it has 120 confirmations. The purpose of this rule is to prevent long chain splits from invalidating lots of transactions that spend newly-generated BTC. For example, this rule prevented non-coinbase transactions from being invalidated after the overflow incident invalidated 50+ blocks.

http://bitcoin.stackexchange.com/questions/3464/why-do-mining-pools-require-120-confirms-for-a-solved-block-before-payout

[bytemaster]

This addresses the race condition for finding blocks, but not forks due to bugs (like in March).

From what I am seeing miners should be able to spend their proceeds in 6 blocks not 100, so there must be justification for the 100 block wait on mining.

[kjj]

This addresses the race condition for finding blocks, but not forks due to bugs (like in March).

From what I am seeing miners should be able to spend their proceeds in 6 blocks not 100, so there must be justification for the 100 block wait on mining.

In the event of a fork, all of the non-conflicting transactions will eventually get into a block, regardless of which fork.  Except for the generate transactions, and transactions that spend them, etc.  100 appears to have been picked as a large round number that would prevent orphan transactions even in the event of a very major split.

Lowering it would cause a hard fork, but raising it would merely require that miners upgrade.