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

[piotr_n]

As the comments in this PR have been locked, I'd like to move the discussion here.

Apparently I present a "misunderstanding of the Bitcoin system"

Well, please help me to understand it, then.

I would like the supporters of this change to answer my question:

Who, how and why defines (and guards) the consensus rules?

Can you try to give me a "technical" answer?
(as opposed to a "political" answer)

[piotr_n]

In case nobody answers and my topic gest buried, I just want to elaborate on the matter.

I am not a big fan of jgarzik, ever since he banned a guy from the IRC channel, just for suggesting that disallowing citizens of Iran accessing bitcoin's github repo isn't right. I've also not been very excited by the changes he's been trying to introduce into the blockchain protocol, along with his shady friends like Andresen or Hearn.

But what bitcoin core team has done by merging the PR into 0.15 - this isn't much better.
This is totally against the very principles of bitcoin.

Some people obviously lost their minds, if they think that "Bitcoin system" is going to allow them to control the consensus rules.

Moreover, I cannot understand why you'd even want to control the consensus rules.
Do you realize how dangerous it would be, being the only people who can change the bitcoin consensus rules?
And everybody knows their names...  Why would you even wish to put yourself in such a position?
Either someone has already forced you to do so, or you are just mad - I seriously cannot see a third option.

Either way, it's not going to work - mark my words.
This system has been designed to resist any kind of centralized control.
I am pretty sure that it is going to resist your tries as well. And when it does, you're all going to loose.

And again: mark my words - you're not going to believe me now, you're going to patronize further, because you obviously think that you have a better understanding of the bitcoin ecosystem... but I don't believe you do. And one day I will come here and say "I told you so". Just like I can tell it now to Andresen, Hearn and a few other arogant idiots from the history of Bitcoin.

[DannyHamilton]

As the comments in this PR have been locked, I'd like to move the discussion here.

Apparently I present a "misunderstanding of the Bitcoin system"

Well, please help me to understand it, then.

I would like the supporters of this change to answer my question:

Who, how and why defines (and guards) the consensus rules?

Can you try to give me a "technical" answer?
(as opposed to a "political" answer)

Who:

Every participant in the Bitcoin system is responsible for either defining and guarding the consensus rules for themselves, or for delegating that responsibility for someone else to handle for them.

How:

Participants can write their own software, or they can choose to use software written by someone else. If they choose to use software written by someone else, then they either verify what consensus rules that software implements, or they trust someone else to verify those rules on their behalf.

Why:

If a user runs software with incompatible consensus rules, they could potentially reject blocks and transactions that the overwhelming majority of users agree are valid, or they could potentially accept blocks and transactions that the overwhelming majority of users agree are invalid.  Either would result in the user's blockchain splitting off from the blockchain that the overwhelming majority of users are using.  As such, they would be vulnerable to various attacks that result in the user receiving worthless transactions.

Note:

If a user can get enough other users to all agree to use their fork of a split chain, the transactions could establish an agreed value that could be more, less, or the same as equivalent transactions on the other side of the fork.

[piotr_n]

Who:

Every participant in the Bitcoin system is responsible for either defining and guarding the consensus rules for themselves, or for delegating that responsibility for someone else to handle for them.

How:

Participants can write their own software, or they can choose to use software written by someone else. If they choose to use software written by someone else, then they either verify what consensus rules that software implements, or they trust someone else to verify those rules on their behalf.

Why:

If a user runs software with incompatible consensus rules, they could potentially reject blocks and transactions that the overwhelming majority of users agree are valid, or they could potentially accept blocks and transactions that the overwhelming majority of users agree are invalid.  Either would result in the user's blockchain splitting off from the blockchain that the overwhelming majority of users are using.  As such, they would be vulnerable to various attacks that result in the user receiving worthless transactions.

Note:

If a user can get enough other users to all agree to use their fork of a split chain, the transactions could establish an agreed value that could be more, less, or the same as equivalent transactions on the other side of the fork.

Sure - this all make sense. Doesn't it?

Just makes you wonder why stupid Satoshi bothered with introducing the concept of mining into the system.

I mean, according to the rules above, the participant in the Bitcoin system might just as well do their job without any mining involved.

And all this energy that gest wasted on something that bitcoin has never really needed - that's just outrageous ;P

[DannyHamilton]

Sure - this all make sense. Doesn't it?

Just makes you wonder why stupid Satoshi bothered with introducing the concept of mining into the system.


I mean, according to the rules above, the participant in the Bitcoin system might just as well do their job without any mining involved.

Miners are participants in the Bitcoin system.

And all this energy that gets wasted on something that bitcoin has never really needed - that's just outrageous ;P

Acording to Satoshi, mining (proof-of-work) is a method of establishing a distributed timestamp server.  The purpose of mining is to determine the order in which the majority of participants agree transactions were received.  The miner (as a participant in the system) defines, guards, and adheres to the same consensus rules for himself that all the rest of the participants (both miners, and non-miners) also define, guard, and adhere to.

Satoshi Whitepaper:

. . . The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

3. Timestamp Server
The solution we propose begins with a timestamp server . . .

4. Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's  Hashcash . . .

[piotr_n]

OK..

The miner (as a participant in the system) defines, guards, and adheres to the same consensus rules for himself

And:

all the rest of the participants (both miners, and non-miners) also define, guard, and adhere to.

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.

[DannyHamilton]

So what this system is supposed to do when there is a disagreement between miners, and non-miners?

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?

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.

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?

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.

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.

[piotr_n]

So what this system is supposed to do when there is a disagreement between miners, and non-miners?

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?

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

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?

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

[DannyHamilton]

So what this system is supposed to do when there is a disagreement between miners, and non-miners?

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?

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

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.

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?

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

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.

[piotr_n]

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.

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

[achow101]

• 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

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.

[piotr_n]

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.

[gmaxwell]

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

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

It has zero chance to work in a long term, while creating a very bad precedence.

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

[TierNolan]

Who, how and why defines (and guards) the consensus rules?

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

So what this system is supposed to do when there is a disagreement between miners, and non-miners?

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.

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

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.

[piotr_n]

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

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.

[piotr_n]

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

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

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

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.

[TierNolan]

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?

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.

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?

You don't technically need a patch each time. 

You could have a "checkpoint=<some hash>" or "banblock=<somehash>" 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.

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.

[piotr_n]

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.

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?

[TierNolan]

Lost what?

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.

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?

How are they making money doing that?

[gmaxwell]

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.

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.

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.

you should not be adding them to then peers database in the first place.

No, then that introduces a simple attack where I advertise your addresses with other bits to prevent people from connecting to you.  Moreover, the bits change: someone can start S2X up to check it out and switch back.  Disconnecting is harmless and gets you the latest information.

that this can only be beneficial after the fork has already happened.

The PR discussion contains a step by step description of why that isn't the case. Please, do all of us a favor by actually reading it.

or "banblock=<somehash>" command line prompt.

We have this-- the invalidateblock RPC.

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

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.

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.

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