4
5

DISCUSSION: Wouldn't non-SPV mining pools have strong incentive to make SPV pools mine "bad" blocks? (self.Buttcoin)

AussieCryptoCurrency が 投稿

I'm not sure whether this applies to any other situation other than this BIP66 fork, but since the fork is obviously common knowledge now, one would assume mining pools would exploit any weaknesses.

This weakness is clear: SPV mining pools are building chains which we know are bad. There's no chance of that fork being accepted, like the 2013 fork, so the SPV pools are at a clear disadvantage if they mine blocks with bad headers at the base.

So what is stopping compliant/canonical mining pools exploiting this weakness, thereby diverting (~50%? of the) network hashrate to chains which cannot compete? Wouldn't this explain why the forks keep happening?

全 6 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

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

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] 1ポイント2ポイント  (2子コメント)

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?

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

I suppose that all the big miners try to steal hashes this way from all open pools. They still need to talk to the nodes to get the transactions to fill their own blocks (which they had better validate, siince they cannot trust the nodes) and to get blocks mined by closed miners, whose hashes they cannot steal. And they must send any block that they mine to the nodes.

I suppose that all miners run their own relay nodes, for extra safety. They just don't waste precious time validating the parent node before mining on top of it.

[–]xXxDeAThANgEL99xXx -1ポイント0ポイント  (0子コメント)

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

Witness the beauty of the Free Market: as long as catastrophic failures like that are infrequent (or, even better, socialized), it tends to optimize for efficiency at the cost of reliability, happily shedding off any built-in precautions even.

In a sense, this is exactly the same kind of stuff as various payment processors moving to off-chain transactions.

[–]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

[–]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.