Bitcoin Forum

is there already a tool to monitor BIP 66 acceptance status? (the number of bloks that say they are v3.0)

as per https://bitcoin.org/en/release/v0.10.0

just checked some blocks and all are v2. no idea on tools yet. should be trivial though, +1 subscribing to this thread.

i wonder if there will be a 0.9.4 release which includes bip66.

Following.

Is there a page which lists what % of the network has upgraded to 0.10.0?

https://getaddr.bitnodes.io/dashboard/?days=90#user-agents

Thats fine for monitoring nodes, but for the soft fork what matters is hash power. https://blockchain.info/pools shows that if the right 6 pools upgrade, then that will trigger the soft fork.

Not exactly "a tool to monitor BIP 66 acceptance status", but closest thing that I have seen. bitcoin.sipa.be/ver-ever.png (http://bitcoin.sipa.be/ver-ever.png)

want is interesting to monitor is how many of the latest 1001 blocks have v3 mark.

here's the voting  scheme:

I am not sure of an online tool but it is reported in the debug.log for bitcoind

Current status: 11 out of 1000 blocks with version 3.

My script is at https://github.com/domob1812/namecore/blob/master/contrib/bip34-monitor/scanBip34.py.  (Is this interesting as a pull request to Bitcoin, or not?)

EDIT: Note that this script is initially for Namecoin.  So you have to change also the RPC port to use it.

See any of these graphs (different time ranges):
http://bitcoin.sipa.be/ver-2k.png (1 week)
http://bitcoin.sipa.be/ver-10k.png (5 weeks)
http://bitcoin.sipa.be/ver-50k.png (half a year)
http://bitcoin.sipa.be/ver-ever.png (since genesis)

Nice, I didn't know about them!

nice tools, thanks!
notable pools/farms that upgraded so far: BTCChina Pool (currently 7% of the network hashrate), KNCMiner (6%)  Bitcoin Affiliate Network (2%), BitMinter (1%)

Looks like there was a spike (http://bitcoin.sipa.be/ver-2k.png) in the last few days.  If that is maintained, it means the vote is around 57% - 43%.  I guess a pool must have upgraded.  The 1 year graph (http://bitcoin.sipa.be/ver-50k.png) shows a slope due to initial release then level then a step and level again and now another step. 

yep, it's AntPool

It's my buddies at FinalHash.

Doing my boy Petey A solid of course!

I talked to f2pool last night. Asked him to switch over as well. He will be hopefully switching over soon. That should get us alot closer.

There was a version of 0.9 released which can handle version 3 blocks.

This allows nodes running older versions of the software to vote/accept version 3 blocks.

http://sourceforge.net/p/bitcoin/mailman/message/34124466/

https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md

Once 75% of the network starts enforcing the rules, legacy nodes could end up accepting invalid version 3 blocks.  That is an expensive DOS attack though, since it requires spending POW on invalid blocks.

And the attack like this would not be very effective because 75% of the network is mining a more restrictive chain.

I think the more common theorized attack vector with this situation is double spending.

--edit--: It has happened prior : https://bitcointalk.org/index.php?topic=152348.0

The one you quote was a purposive 51% attack. Not comparable with a planned softfork

BIP66 has been activated. Enforcement still pending.

anybody have requests for pools that are not using it? i know mostly everyone

Looks (http://bitcoin.sipa.be/ver-2k.png) like the last few miners are updating.  It exceeded 94% for a moment.  Hopefully, noise will be enough to push it over 95%.

the 1001 block window is there precisely not to give the noise much chance.
But it'll get there eventually.

P2Pool is dangerously lagging behind. As usual, for them it's more  difficult to upgrade.

I don't think p2pool has a version number.  It is whatever version of bitcoind that the p2pool miner is using, so different blocks found can be for different versions.

I think there was a "hard fork" of the p2pool chain recently though to allow for a higher block version.

Orthogonal, there was an update which included a non-consensus change to pass through the higher version number that bitcoin core was already providing, as well as a non-consensus change to require Bitcoin core 0.10+, plus a non-consensus change to emit p2pool share v14, plus a p2pool-consensus change to enable requiring share v14, so that it's possible to fork off the participants who haven't upgraded once BIP66 has taken effect.  The latest p2pool block was v3.

Unfortunately, people thought that upgrading bitcoin was sufficient for p2pool to emit version 3 blocks, but unfortunately there was a min(template.version, 2) in the codebase; I didn't get around to checking until a couple days ago. Forrestv fixed it nearly instantly after I emailed him about it. Sadly, P2pool is hardly even a thing anymore... but the remaining users upgraded quickly and about 63% of P2Pool's hashrate updated in about two days, which I think is pretty good.

Minimum of 212 blocks until BIP66 enforcement right now (as of height 363020).

Based on the last 288 graph, it looks like miner support is at 94.5% and holding.

I think once it hit around 75%, CHECKLOCKTIMEVERIFY deployment could have started.

P2Pool is currently around 74% upgraded, and slowly climbing...

We are obviously hoping not to dump 26% of our hashrate when enforcement happens and are working to reach out to nodes that have not yet upgraded.

From the looks of things I'd guess by Monday at the latest we will have BIP 66 enforcement, and possibly even today?

If I count it correctly, there is at least 119 blocks to go at block 363484

If the miner support is 95.5%, then it could take a while.

If the last 1000 blocks are 94%, then you need 2/3 of the window to be the higher rate to get over 95%.  It could be a week yet.  The last 288 window is only barely exceeding 95% consistently.

Pieter has updated the 2k graph to show the first possible time of 95% at v3.

Someone just found 2 version 2 blocks after a long run of version 3.

At block 363628, there are only 53 version 2 blocks in the last 1001 blocks. The first possible 95% time is 363703, with 75 blocks left.

That assumes 100% v3 blocks from now on.  It inherently underestimates the time.

He could add an estimated time which uses his 288 average.  It looks like the average is now 95.5 - 96.0%.

363721 now. 4 blocks left

It completes at block 363275, an empty block by AntPool  :D

And now those laggard miners who still create version 2 blocks is going to lose their blocks. :P
First victim: Block #363726 and #363731 by BTC Nuggets
https://blockchain.info/block/0000000000000000032527aa796d3672e32e5f85a452d3a584a28fc7efbcd5d0
https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99

That's really poor luck. They just need to find the 363725 and that will defer the switch.

Now they have lost $12500 but I think they deserve the loss

F2Pool is creating version 3 block but it looks like the pool has not rejected the #363731 version 2 block and is working on top of it.
https://blockchain.info/block/0000000000000000155f2519d35cd5d2869900bcc5093594b27763a0315390b4

Also, it seems blockchain.info doesn't reject version 2 blocks as well, which could create problems to those using its wallet or APIs.

That's why I never use bc.i wallet

But why F2Pool acts like this? They shouldn't use customized code

So SPV and old full nodes will see 2 fake confirmations now.

363732 is an empty block. I think F2Pool's code just blindly builds on the v2 363731 without looking at its version.

Oh damn, AntPool is doing the same as F2Pool.

If you are on the correct side (rejecting v2 block), the latest block you have should be #363732 00000000000000001242e0216eb113f1c50e4c18ecfbc8b9c0224ec82ec391d6
If you are on the wrong side (not rejecting v2 block), the latest block you have would be #363735.

Any idea how many % of network hashrate do Antpool, F2pool, and all those laggard miners have in total?

P2pool at over 90% :)

SPV nodes made it up to 6 bogus confirmations.

There was basically half of the network hashrate extending an invalid chain. :(

Enforcement?

Yes....?

Yes it's enforced now; at least by the potentially-minority parts of the miners that are actually enforcing any rules at all. :(

This didn't go very smoothly.
Probably some incentives need to be rethought.

Major pools doing "SPV mining" and trust any block on the longest chain. Really?
That enables pretty obvious attacks  have  a really big disruptive impact.

It is safe if they implement safe guards.

The assumption for SPV mining is that nobody would create invalid blocks.  They still cost the same POW to make, so nobody would bother.

This is a reasonable assumption if it is weakened slightly to "It is very rare for other miners to create invalid blocks".  Even with SPV mining, you need to eventually check that the full block is valid.

By building empty blocks on the longest header chain, the pool doesn't waste hashing power during the window when a new block is being verified.

A <- B <- C <- D <- e

In this case, A, B, C and D are fully validated but the full block for e hasn't been received yet.  The miner only checks POW.

If the pool mines block E', then it is wasting its hashing power.  Even if E' is found, it will be older than e, so will be rejected by the network.

By building an empty block as block F, the hashing power is not wasted.  This is a good thing.

The problem starts if block E (full block for e) was actually invalid.  In that case, we don't want miners building on top of it.

An easy way to accomplish it is to have a timeout.  If you are building empty blocks on block e for more than a minute, assume E was invalid after all and switch back to building on D.

Ties should be broken in favor of the block that is fully validated.

The irony in this case is that the invalid fork could have been detected by only checking the headers, so the full block wasn't even needed anyway.

Thanks for the explanation.

As far as I understand, this is how SPV mining should be done, but not how it was
in this case.  If the miners trusted the new block only during that short window
while it was being propagated, they wouldn't have built a whole new chain on top of it.
At most one block - which would be disbanded once they verified that the block E
they were building on was wrong.

But they didn't check it at all. They just kept on building.

About the cost of the attack: it costs about 25BTC to mine a block.
If it spends 25 000 BTC of other people's money to the attacker's wallet, then
just >0.1% of success makes it worth it.  If major miners are not checking
blocks at all, that probability of success seems to be much higher.

Yes, it looks like they just kept building empty blocks on top of empty blocks.  The 5% which haven't upgraded would be creating blocks with transactions on the invalid chain though.


Right.


The pools which mined the empty blocks lost money.  In the alert (https://bitcoin.org/en/alert/2015-07-04-spv-mining), they say around $50,000 was lost by the pools which were setup correctly.

This is a pretty large incentive to update their code so that it works properly.  If you produce a block that is invalid, then you lose around $6,000 per invalid block.

That's the narrow view.  In the aggregate, Ant/F2's risky/lossy 'unchecked headers-only' hack may be a rational/profitable strategy (back luck with BIP66 collision notwithstanding).


From the protocol's POV, the problem wasn't that the fork chain was built on empty blocks, just that those blocks were invalid.