"Implementation Proofs" possible solution to false signaling problem

[priestc]

A big problem with hard fork activation is the "false signaling" problem. This is a miner signaling, but actually doing something contrary to what they are signaling. For instance, a BU node writing EB8 in their blocks, but still rejecting blocks that are 2MB.

A possible solution to this problem is something that I'm calling "Implementation proofs".

Nodes will signal "IP" similar to how they signal EB and AD settings. For instance, a node can signal:

EB8/AD6/IP5f4ef6

The value "5f4ef6" is the "implementation proof". If this proof evaluates as true (in other words, is valid) then this proves that the node has implemented code to read EB values from blocks.

The procedure for generating an "IP" is as follows:

1. Sum the values of all EB values going back 100 blocks. For instance, if in the past 100 blocks, there are 20 blocks that signal EB8, and another 10 blocks that signal EB4, and the rest signaling no EB, then you add all those up and you get a value of 20*8+10*4, which is 560.

2. Validate all signaled IP values. Count each success as 1 and failures as 0. For example, if the last 100 blocks, there are 45 blocks that include an IP value, and only 30 of them are valid, the value 30 is used.

3. Catenate these two values together, and then append the block height. For example: if the block number is 434332, and sum of EB values is 560, and sum of valid IPs is 30, then the resulting string is "56030434332". This string is then ran through the sha256 algorithm, then the first 6 bytes are used.

If a node includes a valid implementation proof, then you can deduce that this node has the ability to parse and read EB values. If 95% of blocks include an IP, and 95% of them are correct, then from this information you can deduce that false signaling is unlikely.

 

[AdrianX]

A big problem with hard fork activation is the "false signaling" problem.

This is not a problem its a feature. Changes are unwanted.

False signaling is sybil attack, bitcoin over comes this problem by using cryptographic proofs that require PoW.

The most important rules are the consensus rules that protect the integrity of the features that give bitcoin value; the inflation rate, the 21M limit, no double spending, and appropriate PoW time stamping.

Nodes that secure the consensus mechanism need to be ultra conservative as they control the consensus rules, any changes that affect the behavior of bitcoin should be resisted - Soft forks are no exception - they are more dangerous as they can't be resisted by the network.

Soft forks give miners the ultimate centralized control over the network as they just need to agree among themselves to change the rules. (or serve a centralized authority who dictates the rules)

false signaling discourages miners from making changes, - there is only one way to confirm if a signal is corect, that is to mine a >1MB block. mining that block today costs $15,000 in lost income.

The goal is not to make miners rich it's to grow the network by making it more secure. Miners have to take a risk to confirm if the signal is correct, if it is not they know - it costs them $15,000. if it is accepted they know. But not knowing if you can grow discourages unnecessary use of block space, and because there is a cost to testing testing is avoided until it is absolutely necessary.

False signaling encourages behavior that is more like a feature not a bug.

 

[priestc]

I agree with you in general that bitcoin should resist change, but I don't think that should be taken to logical extremes.

The Taj Mahal and Notre Dame also have the same property in that they should not be changed. That doesn't mean you don't perform maintenance. When tiles break, they should be replaced. When cracks appear, you fill them in.

The 1MB blocksize limit is in need of being raised, as a matter of maintenance. In order for this maintenance to be done, signaling has to be reliable. I do not agree that false signaling is "a feature not a bug".

I also agree that the point of bitcoin is not to make miners rich, but raising the blocksize limit is not to make miners rich, it is to allow more people to use bitcoin.

Once the blocksize limit has been removed as a consensus rule, I'll jump right in line with you in saying bitcoin should never be changed. As long as 1MB is still in effect, complete ossification should be resisted.

 

[AdrianX]

The 1MB blocksize limit is in need of being raised, as a matter of maintenance. In order for this maintenance to be done, signaling has to be reliable. I do not agree that false signaling is "a feature not a bug".

In a decentralized network there is no authority - my opinion and your opinions may be correct, it is what is that is important not what we think is important. there is only one trust less consensus mechanism in bitcoin and that is the result of PoW.

I agree we can call bitcoin 1.0 when we remove the limit (BU is there already)

Bad signaling, propaganda and FUD is not going to stop bitcoin form removing the transaction limit, I hope it's going to make those who test it more assertive when the time comes, and more sure as they commit $15,000 to each try to see schrodinger's cat.

If there was a way to remove the sybil attack signaling - we should do it, for now we are being immunized for when the time for change comes. - so I'll focus on the positive ramifications of this problem, as there is nothing we can do about the negative, lets use it and the positive things we can get from it. That's why I framed it as a feature.

If you chose to see it as a problem you will realize it is an insurmountable problem, and fighting it can't help.
[doublepost=1491433785][/doublepost]Once the blocksize limit has been removed as a consensus rule, I'll go all in.