BTC-1 - Trojan Update!

[AtraxPool]

So my take from this push is clear that it allows anyone to run a segx2 node hidden or in secret, it basically is akin to a trojan horse in the update.

Does this mean core will have to adapt to build something to detect this and ban the nodes?

https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b2c412a157839608fed0

views on this?

[HeRetiK]

So my take from this push is clear that it allows anyone to run a segx2 node hidden or in secret, it basically is akin to a trojan horse in the update.

Does this mean core will have to adapt to build something to detect this and ban the nodes?

https://github.com/btc1/bitcoin/commit/28ebbdb1f4ab632a1500b2c412a157839608fed0

views on this?

The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.

[achow101]

The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.

Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.

[AtraxPool]

The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.

Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.

Now that was the answer I was looking for.  So in effect, they will automatically kill off peers that are signaling the segwit2x bit but I can't understand the need to "hide" nodes unless there is a valid reason for doing such?

I suppose we will just need to hold off and see what the outcome of this will be.

[HeRetiK]

The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.

Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.

Ah yes, that makes sense. And the commit as posted by OP makes even less sense now.

Lack of replay protection, I get. I personally think it's shitty, but I get it. But this right now is just... weird. So yes, they try to keep the network as tight as possible as long as the consensus is the same. Sounds valid. But to defer solving a possible lack of nodes right until the point where the hardfork occurs seems kinda insane to me.

[AtraxPool]

The nodes would split off anyway as soon as the hardfork occurs. Unless core is already pre-emptively rejecting btc-1 nodes for reasons that I'm not aware of, I doubt that there is need to cut these nodes off as long as they follow consensus.

Either way I don't fully get the rationale behind this. Is it to mask their numbers? Even so, what would that accomplish, other than general chaos? I see neither SegWit nor SegWit2x nodes benefiting from being unable to determine whether they follow the same blockchain.

Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.

Ah yes, that makes sense. And the commit as posted by OP makes even less sense now.

Lack of replay protection, I get. I personally think it's shitty, but I get it. But this right now is just... weird. So yes, they try to keep the network as tight as possible as long as the consensus is the same. Sounds valid. But to defer solving a possible lack of nodes right until the point where the hardfork occurs seems kinda insane to me.

You sir,  Have hit the nail on the head that was something that seems insane to me that lack of nodes right up till the fork.

I still can't grasp this commit at all.

My only other thought behind this would be eclipse attack on nodes?

https://www.youtube.com/watch?v=J-lF0zxGpu0

[achow101]

So yes, they try to keep the network as tight as possible as long as the consensus is the same. Sounds valid. But to defer solving a possible lack of nodes right until the point where the hardfork occurs seems kinda insane to me.

They don't want their nodes to be disconnected from the rest of the Bitcoin network. However this commit really just does them more harm than good.

btc1 implements a preferential peering policy like Bitcoin Core does for segwit. However that policy relies on the service bit, so by disabling the service bit means that they a) won't be disconected by Bitcoin Core 0.15 and b) are less likely to be able to find other btc1 peers so when the fork happens, they are even more vulnerable to being isolated from the network.

This change really is an emotional reaction to Bitcoin Core 0.15's disconnection of their nodes.

[AtraxPool]

So yes, they try to keep the network as tight as possible as long as the consensus is the same. Sounds valid. But to defer solving a possible lack of nodes right until the point where the hardfork occurs seems kinda insane to me.

They don't want their nodes to be disconnected from the rest of the Bitcoin network. However this commit really just does them more harm than good.

btc1 implements a preferential peering policy like Bitcoin Core does for segwit. However that policy relies on the service bit, so by disabling the service bit means that they a) won't be disconected by Bitcoin Core 0.15 and b) are less likely to be able to find other btc1 peers so when the fork happens, they are even more vulnerable to being isolated from the network.

This change really is an emotional reaction to Bitcoin Core 0.15's disconnection of their nodes.

So it's basically a mechanism to bypass or to try to hide the service bit so they are not detected and disconnected from the network?

[achow101]

So it's basically a mechanism to bypass or to try to hide the service bit so they are not detected and disconnected from the network?

Yes. But they really wouldn't be disconnected from the network because not all of the network has upgraded to using Bitcoin Core 0.15. They can still connect to earlier Bitcoin Core versions like 0.14.x and 0.13.x.

[nibor]

btc-1 already prefers connecting to other btc-nodes. So they will be fine.

And since there are so few btc-1 nodes seems unlikely and core nodes will be isolated... but no harm in ensuring that by not connecting to btc-1 nodes.

Once fork happens think nodes will ban others that send invalid blocks/txs. And both btc-1 and core will instantly think the fork block from the other chain is invalid - and then some tx's soon after that.

So actually even if you are isolated - once you get a load of invalid tx's you will then ban them and connect to someone else.. (I think...)

[figmentofmyass]

This change really is an emotional reaction to Bitcoin Core 0.15's disconnection of their nodes.

on its face, that's what it looks like. but i suspect it's a bit more complex than that. pre-fork, i think that most of the network disconnecting from your node would be a deterrent for anyone considering running a btc1 node. in other words, it reinforces the perception that the fork is a minority fork. that's what this is about: perception.

to consider another example..... what would people think if core had released an update that disconnected from all bip148 nodes? surely, this would have reinforced the notion that bip148 was a minority fork. of course bip148 supporters would not want that perceptual baggage, in spite of the need for preferential peering. if core had done so, what would luke's next move have been? double down and start preparing for a POW/difficulty adjustment hard fork for the bip148 chain?

[achow101]

btc-1 already prefers connecting to other btc-nodes. So they will be fine.

That only works if the service bit is advertised. This commit gives btc1 node operators the option to hide that service bit, so the preferential peering will not be as effective or may not work.

Once fork happens think nodes will ban others that send invalid blocks/txs. And both btc-1 and core will instantly think the fork block from the other chain is invalid - and then some tx's soon after that.

So actually even if you are isolated - once you get a load of invalid tx's you will then ban them and connect to someone else.. (I think...)

The transaction format does not change so not all transactions will be invalid. Because they do not implement mandatory two way replay protection, the majority of transactions will be valid on both chains, so nodes will not disconnect and ban each other because of transactions.

Nodes will be disconnected and banned because of blocks. The block at the fork height must have a block weight larger than 4 million, in theory (not sure whether this is actually how it is implemented). This means that that block will be invalid to Bitcoin Core nodes. However the way that Bitcoin Core bans and disconnects peers for invalid blocks (and the same way that btc1 does) is a bit weird. It will only ban the first node that relays it an invalid block. So this means that each new btc1 block found will result in Bitcoin Core banning only one btc1 node that it is connected to. For each non-btc1 block found, each btc1 node will ban one Bitcoin Core peer. So at the time of the fork, the network will not split cleanly and there will still be many btc1 nodes connected to Bitcoin Core nodes even though they are following different consensus rules.