Disconnect network service bits 6 and 8 until Aug 1, 2018 - discussion

[piotr_n]

Recently you've had two invalid blocks routed by bitcoin core clients and you hadn't even realized it before I told you.

lol. You were weeks behind the discussions on this, I knew about them in minutes.  You discredit yourself with your efforts to brag.  Not everyone needs to make a big deal about it.

How typical
Last time you ran out of technical argument, you've also gone to question my credibility.

Go read the actual discussion in the PR rather than being uninformed. Downloading some block is not a concern in the slightest.  You are handicapping your intellect by being arrogant and presumptive.

I believe I did read it and haven't found anything else than "downloading some blocks".
You just dress it up with fancy words, like "incompatible consensus rules", "wasting of network resources", "helping both sides", "etc." - all propaganda bullshit, which at the end of the day comes out to the same thing: you don't want to download (and verify) their blocks and txs and you don't want to send them your blocks and txs.

Seriously, unless you have something constructive to add, please spare me your patronising bullshit.

No, then that introduces a simple attack where I advertise your addresses with other bits to prevent people from connecting to you.

Just how would it be different (worse?) from an attack where you simply don't advertise my address?

Eventually I will find someone who will advertise it, and with the correct bits.

[TierNolan]

No, then that introduces a simple attack where I advertise your addresses with other bits to prevent people from connecting to you.

Just how would it be different (worse?) from an attack where you simply don't advertise my address?

A peer could have your IP as

<your ip>:8333, bits=<non-SW2X>

An attacker broadcasts

<your ip>:8333, bits=<SW2X>

This causes other nodes to update your entry and then 0.15 nodes won't connect to you.

If they didn't broadcast, then your entry would remain with non-SW bits.

The attack works if you overwrite (they broadcast 2nd) or you don't overwrite (they try to broadcast before you).

[gmaxwell]

How typical
Last time you ran out of technical argument, you've also gone to question my credibility.

I'm not questioning your credibility, just pointing out that you're making yourself look stupid when you insult me for not noticing things that were discussed long before you noticed them.

I believe I did read it and haven't found anything else than "downloading some blocks".
You just dress it up with fancy words, like "incompatible consensus rules", "wasting of network resources", "helping both sides", "etc." - all propaganda bullshit, which at the end of the day comes out to the same thing: you don't want to download (and verify) their blocks and txs and you don't want to send them your blocks and txs.

WTF dude, please actually read, AFAICT no one ever talks about downloading blocks in that thread. Bitcoin already typically won't download and will never attempt to verify their blocks.

Instead, the PR points out things like this:

Consider a node with 8 peers, all s2x nodes. At some height the s2x issuance activates, and s2x stops sending valid blocks to our node. Yet the s2x network then takes hours (like Bcash, or over a day like the btc1 testnet) to mine the even a single additional block, and because s2x has no replay protection invalid tx signatures will also not cause banning. When s2x does get a block it will only disconnect a single peer and may find connection slots exhausted all over the net (due to attacks or increased demand from other links cutting). If it has a single connection up to the Bitcoin network, if it has more blocks it may not even notice s2x blocks are invalid if they're part of a less-work chain, since s2x doesn't use the HF bit. All of this disruption, potentially quite severe and damaging (e.g. esp if our node in question is a Bitcoin miner) is avoided by not making a hard cut change to the network topology, but instead adopting a topology from the moment the node starts that will continue to be good for it in the future, with the change happening over time rather than as a network wide system-shock.

It's pretty sad that posters on rbuttcoin are reading and understanding better than some people here.

[DooMAD]

I think that handling "the disagreements" should be the prime and well defined feature of the system - it should actually be its main purpose.

Well hooray, then, because that's precisely what the entire reason is for creating a divide between two sets of incompatible nodes.  If you know in advance that two sides are scheduled to cross paths and have a mass-brawl at a specific time, is it better to allow that mess to happen?  Or to try and separate the two sides beforehand and limit the potential for making a mess?  Just let each side walk their own path.  There's no need to force a head-on collision when that can be avoided.  Each user can still follow their preferred chain, so there is no detriment to consensus at all.  Nothing malicious, it's simply cleaner this way. 

[piotr_n]

WTF dude, please actually read, AFAICT no one ever talks about downloading blocks in that thread. Bitcoin already typically won't download and will never attempt to verify their blocks.

Instead, the PR points out things like this:

Consider a node with 8 peers, all s2x nodes. At some height the s2x issuance activates, and s2x stops sending valid blocks to our node. Yet the s2x network then takes hours (like Bcash, or over a day like the btc1 testnet) to mine the even a single additional block, and because s2x has no replay protection invalid tx signatures will also not cause banning. When s2x does get a block it will only disconnect a single peer and may find connection slots exhausted all over the net (due to attacks or increased demand from other links cutting). If it has a single connection up to the Bitcoin network, if it has more blocks it may not even notice s2x blocks are invalid if they're part of a less-work chain, since s2x doesn't use the HF bit. All of this disruption, potentially quite severe and damaging (e.g. esp if our node in question is a Bitcoin miner) is avoided by not making a hard cut change to the network topology, but instead adopting a topology from the moment the node starts that will continue to be good for it in the future, with the change happening over time rather than as a network wide system-shock.

Well, I don't want to be mean, but that's exactly what I meant.
You just brought some totally unrealistic scenario and blew it up into some crazy and unrealistic proportions - all to justify why 0.15 should be disconnecting jgarzik.

I guess I'd be mad if it wasn't so funny