Topic: Disconnect network service bits 6 and 8 until Aug 1, 2018 - discussion (Read 2100 times)

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

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. 

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.

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:


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

A peer could have your IP as

:8333, bits=

An attacker broadcasts

:8333, bits=

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).

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

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.

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.

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.

We have this-- the invalidateblock RPC.

I agree that user's decide, but there are altcoins that have fewer users than Bitcoin has active developers yet maintain a non-trivial market cap.

I disagree. A large interblock time is safe, if inconvenient, and the same arguments apply to the hysteria about the halving potentially killing hashrate.

The battle to decide which chain has won. 

The fork with the most hashing power will have an overwhelming advantage.  If 95% of miners go with SW2X, then the main chain will have a 3 hour block time.

This would destroy confidence in the main chain.

If they have to use "dirty tricks" to attack the other chain, they don't have the overwhelming majority.


How are they making money doing that?

Lost what?

The reason to buy a mining equipment in the fist place is to make profit.

If they can make better profit from reverting blocks in chain B, then they'd make from appending blocks to chain A - why wouldn't they?

And how is it loosing?

The 5% hashing will maintain ordering of the original chain. 

Applying hashing power to "invalid" blocks is basically a waste of time.  It doesn't matter if you have more POW if nobody will accept your blocks.

If the community picks one fork and the miners pick the other, then the miners' hashing equipment is basically heaters.

The 5% will have a problem with the slow difficulty adjustment though, so miners are certainly not irrelevant.

Having miner support means that your chain isn't subject to reversals as you say.

If the users are mostly neutral, then the miners get to pick which fork.


You don't technically need a patch each time. 

You could have a "checkpoint=" or "banblock=" command line prompt.

You are assuming that the miners supporting the hard fork will not only mine the other chain but also attack the main chain. 

Frankly, if they need to do that, they are admitting that they have already lost.

If things have broken out in war, then new tactics are brought to the table.

An extreme fork of this type is the "firm-fork" where you nuke the other chain at the same time as hard forking.

If it goes ahead, the segwit2X fork is going to split the community.  Look at Ethereum vs Ethereum Classic.

If most of the users follow the fork, then it will win.  If not, it will stall out.

Bitcoin Cash has an (abusable) rule for allowing a fast difficulty drop.  This meant it was able to form a new chain while having a lower price & hashing power than Bitcoin.

When the Segwit2X fork happens, you will have 2 chains with exactly the same difficulty.

The price per hash is the key metric for miner profitability. 

Price per hash = (block mint + fees in coins) * (market price of coin) / difficulty

For the most part, the fees and the difficulty will be the same for both forks.  This means that the market price for each coin determines the price per hash.

If one coin is worth less than 50% of the other, then that coin's chain will be worth less to mine than the other chain.  Miners on the lower priced chain would make more by switching.

If 90% of miners are purely profit driven, then the higher priced coin will take that 90% of the hashing power.

Even if a miner believes in the other fork, it is still in their interests to mine on the higher value fork and then use an exchange to trade.  At least the advantage of doing that is it bumps up the price of the lower priced fork.

There is a "hyper-transfer" problem when there are multiple chains with the same hashing function.

Quote

Or perhaps they will start a comity to monitor "unauthorized" chain reorgs and quickly broadcast the information to their winning software, so it would know which blocks to ignore?

If it is all out war, then that is an option.  Users would decide that they will (temporarily) give up the decentralisation of ordering to prevent the miners forcing a hard fork.

You can also somewhat defend against things like that by having clients monitor if there are re-orgs.

For example, if there was a re-org of more than 10 blocks, then the client would ask the user which fork to use.

Miners on the original chain could implement a no re-org rule, but that is generally open to attack itself.

Considering how quickly they pushed through BIP91, only to avoid a chain split caused by UASF (which, apart from affecting the price, wasn't any serious danger to bitcoin), I'd say they are much more responsible than a large part of "the community".

I disagree.
I think the main reason for this change is a political statement, saying: we won't be talking to any s2x nodes, effectively cutting them off from our part of the network (our txs and blocks).

Recently you've had two invalid blocks routed by bitcoin core clients and you hadn't even realized it before I told you.
Now you are trying to convince me that one large block which the core nodes are going to reject right away, without routing and trying to verify it, is an issue?
It would be only one block! You would not download any of its children, as the further headers will not link anymore.

With this, solely political change, you are not only going to ignore a valid blocks that originate from the s2x nodes, but also the transactions.
Before the fork can even happen!

Not to mention that the patch itself is also very lame.
Instead of disconnecting from the nodes with service bits 6 and 8, you should not be adding them to then peers database in the first place.
If it is true what you say, that not connecting to the other nodes is beneficial for both sides, then s2x can start not adding peers that do not indicate the bits to their db and voila - problem solved.

But I think you understand very well that this can only be beneficial after the fork has already happened.
Before - it's simply excluding the other party's blocks and txs from your part of the network.
If the nodes were people, I'm pretty sure it'd fall under discrimination

Before the split, if there ever will be a split, there is absolutely nothing wrong with these blocks and transactions.
And by discriminating them, you are essentially discouraging people (also miners) from using S2X software.
These are dirty tricks to fight the competition and they have nothing to do with any improvements.

Don't be ridiculous.

How are the "winning" users going to guard the immutability of their new chain, while loosing the hash power war 5 to 95?

Are they going to make a new patch, each time the "loosing" miners decide to revert the last five, ten or twenty of their blocks?
Or perhaps they will start a comity to monitor "unauthorized" chain reorgs and quickly broadcast the information in form of a signed messages to their winning software, so they could know which blocks to ignore?

Sometimes I'm really amused seeing how some people responsible for developing the system don't really understand it's very nature.

It is the community built around the currency, on the assumption that the community is mostly united.

The best solution to irreconcilable differences is to hard-fork and then have 2 currencies.  The problem is that everyone wants their side to be "Bitcoin".

Bitcoin core (clearly) feels that hard forking does not represent the community consensus and they are acting accordingly.

On a purely technical basis, the change is reasonable.  Given that the hard fork counts as a creating a different chain, they need to protect their userbase.

If they didn't make the change, then until the forking date, the 2 networks would be mixed.

Segwit2X clients and Core clients would connect to each and be completely compatible with each other.  

When the fork happens, they are suddenly incompatible.

Assuming 50% for each chain, then a Core node which has 8 connections has a 1 in 256 chance of only connecting to SW2X nodes.  Even if it does have a connection to a non-SW2X node, they might be an isolated "island" of nodes and have no connection to miners.

If that happens, it will suddenly be isolated and won't be able to get updates from the non-hard fork chain.

It won't even know that its peers have a problem instantly.  It has to wait until they start sending SW2X transactions ... but those are actually compatible with core.

So, it actually has to wait until it gets forwarded a big block.  When that happens, it will ban that one peer and then go searching for a new connection.  That has a 50% chance of connecting to a SW2X node, and so it is still disconnected from the non-forking chain.

By having 0.15.0 refuse to connect to SW2 nodes, it creates a core of nodes that follow the non-hard fork rules.  This gives at least a "backbone" of connectivity that keeps the network together.

It also gives slots for people who lose all their 8 connections to connect to.

The recommendation will probably be that non-forking miners all run 0.15.0 (or at least update their nodes to reject SW2X nodes).


The miners ONLY decide transaction ordering.  If 95% of the miners go on one chain but 95% of users go on the other, then the users "win".

The normal term for this is "economic majority", but getting users to coordinate is hard.  You might be able to get all the exchanges and payment processors to coordinate if the miners went crazy.


Well that is the $50 billion question.  A bigger block means more transactions.  If the transactions double but the fees drop by 25%, then you are still better off.  If the fees drop by 90% when the transactions double, then you end up with less.

I agree, but I think not everyone understand Bitcoin as well as you.

I still think you just don't understand what this is trying to do. It's intended to be both in the interest of S2X nodes and non-S2X alike. We need to adapt the topology before the fork happens, thankfully they helpfully identify themselves. (in part because they already influence their own peering decisions, selfishly: they don't want non-s2x nodes to have the same benefit it seems!)

IMHO miners would be crazy to go into 2MB big blocks hard fork.

In June the average block was mining even 16 BTC - now it's more like 13 BTC - that's like 20% less profit.

All the extra block rewards come from the fees. And the bigger the block is, the lower the fees will be.
And soon segwit gets activated, to make the fees even lower.

Miners would have to be stupid to go into a hard fork, just to change the block size, only to earn less money at the end.
Plus: very likely depressing the price of bitcoin by hard forking...

Still, I think that merging the PR in question was a very bad decision.
This is not how you should be working out and guarding the consensus rules.
It has zero chance to work in a long term, while creating a very bad precedence.

These.

The PR operates under the assumption that miners are not actually supportive of Segwit2x and not actually using the btc1 software. From some discussions with various miners and other trustworthy sources related to miners, this appears to be the case. From what I have heard, most miners are not using btc1 and will not be supporting the 2x part of segwit2x. When BIP 91 activated, they were actually running James Hilliard's Segsignal patch instead of btc1, with the exception of a few miners controlled primarily by Bitmain.

Even if this assumption is false and that miners are actually supporting the 2x part of segwit2x, the Bitcoin Core developers do not support segwit2x and will not be implementing it in their software. Either way, there will be a fork in the blockchain, with some miners supporting one fork, and others supporting the other one. It doesn't matter which chain has the majority hash rate since nodes on both chains will reject the other chain's blocks.

The whole purpose of this PR is to ensure that when the fork happens, it happens cleanly. The goal is to make nodes not ban each other, not have cross talk between chains, and avoid partitioning the network. By disconnecting (not banning) peers with these service bits, we are making it easier and more likely for those peers to be able to connect to other peers that will be using the same consensus rules, i.e. btc1 peers are more likely to make connections to other btc1 peers. This minimizes the risk of network partitioning following the fork as the btc1 nodes will be connected to each other.

In the PR thread, people mentioned that this will encourage nodes to lie about what their version is and the service they support. This behavior would actually be detrimental to btc1 peers. The service bit is used for preferential peering. By removing their service bit, they will be less likely to connect to other btc1 peers and more likely to end up partitioned from the rest of the btc1 network following the fork. In order to avoid that, it would be best for them to use the service bit for preferential peering and maintain connections to other btc1 nodes before the fork so as to have the same connections after the fork.

Lastly, the PR ensures that the network topology changes gradually. At the time of the fork, what will happen is that the network topology will change suddenly and possibly fracture the network into multiple partitions. By disconnecting the peers that we know will be following different consensus rules than us, we are ensuring that the network topology will gradually shift from a mixed pool of nodes, to two pools of nodes mostly separated, but still connected to each other. At the time of the fork, this will split in two instead of into multiple pieces.

Yes it does.
It's very simple: either a new block is valid, or not.

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

I also think that the only reliable method to handle the disagreements, is by the hashing majority voting.
If anyone has a better method, I'd be happy to learn it, but so far I've only seen some pathetic tries using social engineering, non-existing entities like "economic majority" and basically all kind of propaganda for a stupid man - all that has zero chance to work in a long term...

The only thing we know can work for sure for handling the disagreements is the mining majority.
ATM I see no other reliable technical way to handle them.
But I'm open for suggestions

My point is:
What the system does depends on the specifics of what the disagreement is about. A generic and general "consensus rules disagreement" doesn't provide enough detail to be able to describe what would happen.


A few possibilities:

• The developers of Bitcoin Core believe you are wrong, and believe that their software will not disconnect from the majority of existing hash power
• The developers of Bitcoin Core believe you are wrong, and believe that the majority of hash power will stop behaving in a way that would get them disconnected
• The developers of Bitcoin Core have decided that they are willing to have their software operate on a fork with less hash power

Regardless, the important thing that more people need to understand is that Bitcoin Core is not "Bitcoin" any more than MultiBit, or Armory, or Electrum, or Coinbase.com, or blockchain.info, or ViaBTC, or Bitmain is "Bitcoin".  Like all those others, Bitcoin Core is just one group of computer programmers that have given themselves a fancy name and maintain software that implements a protocol to the best of their ability to understand that protocol.

Like all those others, if they are wrong about their understanding of the protocol and the desires of the users, then people will stop using their software and it will fade into obscurity as it forks onto a blockchain with very little economic support.  If they are right about their understanding of the protocol and the desires of the users, then there should be sufficient economic activity and the financial incentives built into the system will encourage increased hash power and participation as they remain on the blockchain with the most economic support. Neither of these results would necessarily destroy bitcoin, though over time it could modify the general agreement of what bitcoin is.

We've been talking about the consensus rules - the blockchain protocol.
It pretty much falls under any of the three you've mentioned.

Why otherwise would they merge in a code change that potentially (and likely) disconnects them from the majority of the existing hashing power?

That depends on the disagreement.

Disagreement about a new feature, or new rule?
Disagreement about existing rules?
Disagreement about validity of a block or transaction?


Perhaps I overlooked it.  Where did the team that calls themselves "Core" announce that they are building a system in which miners won't matter?


There are some answers that nobody knows yet. Bitcoin is largely still an experiment to see if the concept can work. It's an experiment that has caught on with a lot of people, and that has established significant value, but there are many things yet to be learned.

OK..


And:

So what this system is supposed to do when there is a disagreement between miners, and non-miners?
Or between miners, and miners... or between non-miners and non-miners...
Who, how and why is going to "define, guard, and adhere to" the consensus rules then?

I'm just trying to imagine the system that the bitcoin core team is building for us.
The one in which miners won't matter.

And I am asking these question not only because I don't know the answers.
But because I am pretty sure they don't know these answers as well.