Author

Topic: Largest Chain Spilt / Merge to date. (Read 806 times)

kjj
legendary
Activity: 1302
Merit: 1024
June 21, 2013, 10:54:18 AM
#9
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.
hero member
Activity: 770
Merit: 566
fractally
June 21, 2013, 10:14:25 AM
#8
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.
member
Activity: 88
Merit: 12
Max Kaye
June 21, 2013, 03:57:29 AM
#7
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?

Quote
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
member
Activity: 88
Merit: 12
Max Kaye
June 21, 2013, 03:55:30 AM
#6
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.
hero member
Activity: 770
Merit: 566
fractally
June 20, 2013, 09:10:09 PM
#5
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?
kjj
legendary
Activity: 1302
Merit: 1024
June 20, 2013, 07:41:18 PM
#4
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.
hero member
Activity: 770
Merit: 566
fractally
legendary
Activity: 1630
Merit: 1000
hero member
Activity: 770
Merit: 566
fractally
June 20, 2013, 04:11:16 PM
#1
What is the largest chain split and merge to date by time?
Jump to: