Topic: BIP 66 status (Read 8250 times)

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.

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, 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.

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.

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.

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.

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

Enforcement?

Yes....?

SPV nodes made it up to 6 bogus confirmations.

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

P2pool at over 90%

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?

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.

That's why I never use bc.i wallet

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

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 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

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

It completes at block 363275, an empty block by AntPool 

363721 now. 4 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%.

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.

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