全 4 件のコメント

[–]dgerard 1ポイント2ポイント  (0子コメント)

Remember that mining has reached equilibrium, where the cost of mining 1 BTC is about 1 BTC. So the Red Queen's race of vicious competition will certainly include attacking each other directly, if there's any way to do that.

[–]jstolfi 1ポイント2ポイント  (2子コメント)

They are not doing "SPV mining", but an even shorter shortcut.

Basically pool X registers as member of pool Y. When someone in pool Y mines a new block B(n), pool Y starts to send it out to the relay nodes, but first it tells all its members to start mining another block B(n+1) on top of B(n). To do that, it has to send the header template of B(n+1) to all those members, which includes the hash of block B(n).

Pool X then takes this hash and starts to mine their own block B'(N+1) on top of B(n). All this often happens before the block B(n) has propagated to the relay nodes and been validated by them.

Usually this is pretty safe (much safer than SPV mining) because it is in the interest of pool Y to build B(n) according to the rules, and to send a valid header template of B(n+1) to its members. It knows that some of the members are spies of other pools, but it does not know which ones, and it cannot afford to build a bad block B(n), or send a bad header template of B(n+1) to all its members, just to fool the competition.

Usually this shortcut saves pool X precious seconds, compared to waiting for block B(n) to come across the relay nodes. So pool X cannot start validating B(n) right away, even if it wanted to, because all it has is its hash. But, as said above, B(n) will be valid 99.99% of the time; so validating or even downloading B(n) would be a waste of precious network bandwidth.

That strategy failed (at least twice) on this case because pool Y (BTCNuggets) was one of the 5% who were still running v2 software, and so it generated a block B(n) that was invalid under v3 rules. Pool X (BTC-China) that "stole" the hash of B(n) from BTCNuggets did not realize that; and neither F2Pool, that "stole" the same hash from BTC-China. F2Pool soon mined their B'(n+1) before receiving block B(n), and even mined B(n+2) on top of it. AntPool then mined B'(n+3) on top of B'(n+2), having stolen its hash from F2Pool. And so on.

For double bad luck, F2Pool had disabled entirely the validation of the parent block, probably to save bandwidth. So it (and the other pools who extended the bad chain) did not realize the mistake, even retroactively. Someone had to warn them.

[–]AussieCryptoCurrency[S] 0ポイント1ポイント  (0子コメント)

Basically pool X registers as member of pool Y. When someone in pool Y mines a new block B(n), pool Y starts to send it out to the relay nodes, but first it tells all its members to start mining another block B(n+1) on top of B(n). To do that, it has to send the header template of B(n+1) to all those members, which includes the hash of block B(n).

Wow, so ~half the network doesn't independently verify Txs? Or even communicate with nodes?

[–]AussieCryptoCurrency[S] 0ポイント1ポイント  (0子コメント)

That strategy failed (at least twice) on this case because pool Y (BTCNuggets) was one of the 5% who were still running v2 software, and so it generated a block B(n) that was invalid under v3 rules. Pool X (BTC-China) that "stole" the hash of B(n) from BTCNuggets did not realize that; and neither F2Pool, that "stole" the same hash from BTC-China. F2Pool soon mined their B'(n+1) before receiving block B(n), and even mined B(n+2) on top of it. AntPool then mined B'(n+3) on top of B'(n+2), having stolen its hash from F2Pool. And so on.

The circle of free markets at work