block.version=1 blocks will all be orphaned soon

[Gavin Andresen]

Last July, BIP 34 was accepted. It specifies a "soft fork":

If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks

We are getting close to that threshold: 821 out of the latest 1000 blocks were version 2.

If you are mining in a pool: there is a list of pools and what versions they are producing here. If your pool is producting version=1 blocks, you should urge your pool operator to upgrade or patch.

If you are mining with p2pool or solo and using a very old version of bitcoind: you should upgrade, or you risk your blocks getting orphaned.

[1714171372]

1714171372

[1714171372]

1714171372

[1714171372]

1714171372

[1714171372]

1714171372

[1714171372]

1714171372

[1714171372]

1714171372

[DBG]

So long and thanks for all the bitcoin Deepbit?

[grue]

So long and thanks for all the bitcoin Deepbit?

the only thing holding back this patch is deepbit

[eleuthria]

So long and thanks for all the bitcoin Deepbit?

the only thing holding back this patch is deepbit

Not quite, we'd still be just shy if Deepbit's blocks were all v2.  If BTC Guild getwork could support v2 right now we would just about be there.  Working on that tomorrow to see if there's any way I can add v2 blocks to the coinbasing of PoolServerJ.

[DBG]

I know Graet (ozcoin) doesn't quite want to take down the getwork/merged mining server yet (and strand those users by our hand), but take Deepbit out of the equation completely, and if the top 4 pools were to all make a clean break it would happen.  However I was hoping for a rolling plan like slush proposed back in February, and I rather users update their software compared to just getting shut out.  I know it will happen in time so patience is a virtue here  .

[eleuthria]

I know Graet (ozcoin) doesn't quite want to take down the getwork/merged mining server yet (and strand those users by our hand), but take Deepbit out of the equation completely, and if the top 4 pools were to all make a clean break it would happen.  However I was hoping for a rolling plan like slush proposed back in February, and I rather users update their software compared to just getting shut out.  I know it will happen in time so patience is a virtue here  .

Do note that this isn't a hard-fork.  It just means if you continue trying to mine v1 blocks, they will not be accepted by the rest of the network.  It's highly unlikely this would ever go beyond a single orphaned block, given the amount of hash power that is mining v2 blocks, and the amount of nodes that will refuse to forward your block.

This has been a "rolling plan".  It's been in place for 8 months, and only takes place when a supermajority of 95% is on v2.

[wknight]

I think it just happened to Ozcoin.

http://blockchain.info/block-index/362524/00000000000001b4ee26f0189e4e3d139a3b8c5c8179109f270819eac7284aab
http://blockchain.info/block-index/363019/00000000000001d68223b78f7c012dcdce458cb3b46f2b325bd7bc6d067c396b

[eleuthria]

I think it just happened to Ozcoin.

http://blockchain.info/block-index/362524/00000000000001b4ee26f0189e4e3d139a3b8c5c8179109f270819eac7284aab
http://blockchain.info/block-index/363019/00000000000001d68223b78f7c012dcdce458cb3b46f2b325bd7bc6d067c396b

That looks like your standard orphan.  The EclipseMC block was seen 15 seconds before the OzCoin block.  The time stamps just made it look the opposite due to Eclipse's timestamp being in the future, and Ozcoin's being in the past.

[Graet]

well with the forking blockchain and patches needed to keep ecoinpool running etc, I'm about ready to turn getwork servers off
with the threshold for V2 blocks getting much closer it wont be long until it breaks anyway

[doublec]

I just noticed that my merge mining getwork server was producing version 2 blocks without having a block height in the coinbase in certain circumstances. If you're a miner using a merge mining patch you might want to check that your coinbase is correct otherwise when the supermajority happens your blocks will be orphaned if the coinbase is wrong.

[doublec]

Have we hit this already? I'm seeing in the logs of a v1 node:

Code:

ERROR: AcceptBlock() : block height mismatch in coinbase

[kinlo]

FYI: The blockorigin site keeps track of the last 1000 blocks on http://blockorigin.pfoe.be/top.php

In the text on the bottom you will see the counts in blocks on v1.  95% is required so if the number of blocks on v1 drop below 50 over the last 1000 blocks, all blocks v1 will be rejected!

[doublec]

FYI: The blockorigin site keeps track of the last 1000 blocks on http://blockorigin.pfoe.be/top.php

In the text on the bottom you will see the counts in blocks on v1.  95% is required so if the number of blocks on v1 drop below 50 over the last 1000 blocks, all blocks v1 will be rejected!

Note their current block number showing in their list. It's over 1,000 blocks out of date.

[kinlo]

Note their current block number showing in their list. It's over 1,000 blocks out of date.

Iek, fixing that problem, thanks for noticing

[doublec]

Iek, fixing that problem, thanks for noticing

No worries. I'd been using it to track the supermajority and working today on getting my merge mining server compatible with version 2 blocks. Then I noticed the error in my logs and which makes me think we've hit it and I've run out of time.

[kinlo]

According to my site it's now down to 80 blocks on v1, 50 and we're there...

Scratch that, site is still building and out of sync... I'll update when I know for sure

[doublec]

Scratch that, site is still building and out of sync... I'll update when I know for sure

It looks like we aren't - I ran a quick shell script on bitcoind. But due to a merge mining issue my coinbase has an invalid height and the check for that gets activated at 75% which we've hit. Lost three blocks, argh!

[Gavin Andresen]

There are three stages to the rollout:

1. Before 75% are producing block.version=2 blocks: no special checking
2. Between 75 and 95% : block.version=2 blocks MUST have height in coinbase.  We are here.
3. 95% or more:  all blocks MUST be block.version=2 and MUST have height in coinbase.  Should happen soon.

Shell script to count block versions:

Code:

gavin$ for i in {225925..226925}; do ./bitcoind getblock $(./bitcoind getblockhash $i); done | grep version | sort | uniq -c
 173     "version" : 1,
 828     "version" : 2,

[kinlo]

Blockorigin has been fixed too.  So we're now still at 16.90% v1 blocks...

[mot7]

Has anything interesting happend on TestNet as a result of this change?