6 ms·

Can you elaborate? What kind of partition are you referring to? Thanks.

rothbardrand 9y ago
Dating back to the days of satoshi, the consensus would reject blocks that did not fit its rules. That way some node can't just make up its own rules. Rather than join a P2P network of nodes with wrong rules Core added code to not connect to nodes that give you blocks that violate consensus. It's not controversial but the anti-core forces have nothing of substance so they make up drama.
- theprotocol 9y ago
  I see. Thanks. Need to read more about this.
kobeya 9y ago
A partition of the connectivity graph. Imagine we have two Bitcoin Core nodes connected by an intermediate Segwit2X [sic] node: 1X(a) ----- 2X ----- 1X(b) When the 2x node starts relaying post-fork blocks, it is seen as misbehaving by the 1x peers and dropped by both of its neighbors. The unattended consequence is that 1x(a) is no longer connected to 1x(b). If the mining network is only connected to one of these partitioned networks, then it is possible that the other will not hear of new blocks. The bitcoin nodes will have a different view of the network simply because they are not connected to each other. Worse there might be a few miners on the less hashrate side that still move the network forward a few blocks. If this situation persists, e.g. because network operators are asleep at the wheel, it could be exploited by selectively connecting and broadcasting double-spends to the two networks. To prevent this from happening the Bitcoin Core team added code to 0.15 and higher that will per-emptively disconnect peers that advertise themselves as Segwit2x. Therefore a 0.15 node will only connect to peers that will relay good blocks from its perspective, and it is much less likely that such a network partition would occur. As long as there exists some nodes that don't auto-disconnect (e.g. old bitcoin nodes) then the Bitcoin Core 0.15+ and the Segwit2x networks will remain connected until the fork occurs.
- theprotocol 9y ago
  Thanks, that was very helpful. This issue did not occur to me.

Dating back to the days of satoshi, the consensus would reject blocks that did not fit its rules. That way some node can't just make up its own rules. Rather than join a P2P network of nodes with wrong rules Core added code to not connect to nodes that give you blocks that violate consensus. It's not controversial but the anti-core forces have nothing of substance so they make up drama.

theprotocol 9y ago
I see. Thanks. Need to read more about this.

kobeya 9y ago

A partition of the connectivity graph. Imagine we have two Bitcoin Core nodes connected by an intermediate Segwit2X [sic] node: 1X(a) ----- 2X ----- 1X(b) When the 2x node starts relaying post-fork blocks, it is seen as misbehaving by the 1x peers and dropped by both of its neighbors. The unattended consequence is that 1x(a) is no longer connected to 1x(b). If the mining network is only connected to one of these partitioned networks, then it is possible that the other will not hear of new blocks. The bitcoin nodes will have a different view of the network simply because they are not connected to each other. Worse there might be a few miners on the less hashrate side that still move the network forward a few blocks. If this situation persists, e.g. because network operators are asleep at the wheel, it could be exploited by selectively connecting and broadcasting double-spends to the two networks. To prevent this from happening the Bitcoin Core team added code to 0.15 and higher that will per-emptively disconnect peers that advertise themselves as Segwit2x. Therefore a 0.15 node will only connect to peers that will relay good blocks from its perspective, and it is much less likely that such a network partition would occur. As long as there exists some nodes that don't auto-disconnect (e.g. old bitcoin nodes) then the Bitcoin Core 0.15+ and the Segwit2x networks will remain connected until the fork occurs.

theprotocol 9y ago
Thanks, that was very helpful. This issue did not occur to me.