The Relaxed Synchronicity Requirements of Soft- and Hard-forking Changes for Non-mining Nodes

[Peter R]

The Relaxed Synchronicity Requirements of Soft- and Hard-forking Changes for Non-mining Nodes

We begin with three definitions to make our language precise.

Def. 1. CONSENSUS RULE SET.

The set, C, of all rules used by a given node to determine which transactions or blocks are invalid. If C = ∅ (the empty set), then all transactions and blocks are valid.

Def. 2. SOFT-FORKING CHANGE.

A pure increase in a node's consensus rule set. If C is the rule set prior to the soft-forking change and C' is the rule set after the change, then C' is a strict superset of C (i.e., C' ⊃ C). The new rule set is more restrictive.

Def. 3. HARD-FORKING CHANGE.

A pure decrease in a node's consensus rule set. If C is the rule set prior to the hard-forking change and C'' is the rule set after the change, then C'' is a strict subset of C (i.e., C'' ⊂ C) . The new rule set is more permissive.

Next we propose a simple theorem and corollary.

Theorem: REVERTING A SOFT-FORKING CHANGE IS A HARD-FORKING CHANGE.

Proof: If C_f is the rule set after the soft-forking change and if C_i is the rule set before, then by Def. 2, C_f must be a strict superset of C_i (C_f ⊃ C_i). By Def. 3, moving back from C_f to C_i is thus a hard-forking change (because C_i ⊂ C_f)

Corollary: REVERTING A HARD-FORKING CHANGE IS A SOFT-FORKING CHANGE.

Proof: see above (in reverse).

With that out of the way, we now get to the meat of this post. Since we have a lot of experience with successful soft-forking changes, let's ask what a soft-forking change to reduce the block size limit from 2MB to 1MB would look like. Since we know that a hard-forking change is a soft-forking change in reverse (cf. the theorem's corollary), perhaps there's something we can learn. (I use the example of the block size limit because it's a topic of current interest, but the logic applies to other changes as well.)

WHAT WOULD A SOFT-FORKING CHANGE FROM 2MB BACK TO 1MB LOOK LIKE?

Ans. Miners would coordinate some time in the future, t0, where they agree to no longer build on top of blocks greater than 1MB; that is, at time t = t0 they would enforce the more-restrictive rule set C_1mb rather than C_2mb (C_1mb ⊃ C_2mb).

The synchronicity requirements on non-mining nodes are relaxed. Non-mining nodes may elect to enforce the restricted rule set (i.e., begin rejecting blocks greater than 1MB) at any time t >= t0. However, they CANNOT enforce the restricted rule set for t < t0, without the risk of forking themselves off the network.

WHAT SHOULD A HARD-FORKING CHANGE FROM 1MB TO 2MB LOOK LIKE?

Ans. Miners would coordinate some point in the future, t0, where they agree to build on top of blocks greater than 1MB; that is, at time t = t0 they would enforce the less-restrictive rule set C_2mb rather than C_1mb (C_2mb ⊂ C_1mb).

Once again, the synchronicity requirements on non-mining nodes are relaxed. Non-mining nodes may elect to stop enforcing the old rule set (i.e., begin accepting blocks greater than 1MB) at any time t <= t0. However, they CANNOT continue to enforce the old rule set for t > t0, without the risk of forking themselves off the network.

TL/DR: The main point is that from the non-mining nodes' perspective, synchronous coordination is not required for either soft- or hard-forking changes. For a soft-forking change, nodes can upgrade asynchronously after the miners start enforcing a new rule. For a hard-forking change, nodes can upgrade asynchronously before the miners stop enforcing an old rule.

HOW CAN WE USE THESE RELAXED SYNCHRONICITY REQUIREMENTS TO MAKE HARD-FORKING CHANGES EASIER?

The answer is that we should give non-mining nodes the ability to easily reduce their consensus rule sets before the hard-forking event, along with a way for them to signal those changes to the network. This parallels what we’ve done successfully for soft-forking changes (i.e., allowing nodes to continue enforcing the old rule set after the change was activated).

For example, there is no reason Coinbase, Xapo and BitPay's non-mining nodes need to enforce a 1MB block size limit today. These companies could declare "from this day forward, our nodes will accept any block composed of valid transactions that is less than X MB in size" where X is > 1MB. If other economically-important nodes follow their lead, it would alleviate the false coordination problem that is presently adding friction to the block size limit increase.

 

[Peter R]

.

 

[sickpig]

@Peter R you should e-mail even Jeff Garzik, if memory serves he has the final word on btc-dev moderation.

At least this what they said on the original announcement about moderation policy.

Rusty recently remind me of this on a email where he communicated that a post of mine had been dissed... obviously because it was political.

 

[Peter R]

@sickpig

Interestingly, I just checked my email and noticed a (late) response from Rusty that must have come earlier this morning. He said he's on paternity leave from the dev list, and CC'd all of the other moderators (two of which I already tried to contact). Indeed, Jeff is one of them (for some reason, I thought Jeff had stepped down otherwise I would have tried him too). We'll see what happens...

 

[Peter R]

My email was finally rejected and the reason given was the single word "dupe." I had to look this up. It means a "trick" or a "deception."

I wrote to Jeff Garzick (as he's a moderator) to point out that this kind of behaviour is childish and cc'd bitcoin-discuss for the paper trail:

https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-February/000069.html

 

[theZerg]

Hmm... thats the classical def. But doesn't it mean duplicate in this context?

This is a very nice theoretical description of why its ok (and why its good) to run BU with a higher excessive block size than is currently accepted by the majority. I think it should be turned into a short white paper and put in front of ppl who are more theoretically focused. Unfortunately I think other ppls eyes will glaze over.

 

[Peter R]

That's what Patrick and Bryan are claiming, but it is a very slimy thing to do.

I have been emailing moderators in private since Monday and was completely ignored. Finally Rusty responded, CC'd all the other mods, and then I followed up by resending the email and notifying the moderators so that they could approve or reject it. I even checked my email in the queue before resending and the link said "expired" so what was I supposed to do?

So then to reject the email because I sent it again (and notified them that I did) (if that is indeed what they meant by "dupe") with still no answer why the original was neither rejected nor approved, and in a completely ambiguous way, is plain deceitful.

The bottom line is that this shows just how broken the Blockstream/Core communication channels are. I tried my best for 6 days to resolve this is private--was ignored--and now they are trying to spin this around as though they did nothing wrong.

 

[theZerg]

LOL right, you sent it, it didn't get posted so you sent it again so both get rejected as a dup... with an extra e in there just to piss you off. If you're going to be an ass, do it to the MAX! Pretty funny actually.

 

[solex]

@Peter R

Wouldn't you imagine that having just committed to a hard-fork, starting July and active after a year, that Core Dev would be keen to learn all they can about the process? Especially as they have said so often how difficult the process is, even much more difficult than splitting transactions into two parts and handling the massive cascade of changes which result.

So your article is highly informative for them, and timely. Of course, they might not need it if they are bluffing the Chinese miners into giving PoW to their soft-fork changes, and have no intention of doing a hard-fork block limit change in return for that miner support...

edit: or maybe the miners are completely mistaken thinking that they have consensus with Core Dev and have only come to consensus with Adam Back acting as an individual.

 

[sickpig]

@Peter R

go public. tweet to Garzik.

 

[Zangelbert Bingledack]

Pretty atrocious if this happened like it seems. Political my ass, though using a non-blocksize-related example would have helped.

Dupe = duplicate ("e" needed otherwise could be pronounced "dup"), but if the first was rejected the second can't be rejected as a dupe, obviously since the first never made it to the list. Rusty being on leave explains almost everything. The fort is being held down by kanzure and drak, who I think would sooner die than have any post by Peter R make it through, at least if it challenges any point of BS doctrine.

Twitter is a decent idea for a non-censorable platform. This one even /r/Bitcoin might sympathize with, mods allowing. Putting it all in a single image would make it easier.

 

[awemany]

@Peter R. : First of all, awesome simple picture of what is happening and how indeed there is a symmetry in changing rules (widening/narrowing) them and how that is equal to calling a change soft or hard fork.

I think I had a similar idea (but more diffuse until now) in my mind all along on how the stuff should work, however even though it is just a couple of relatively simple observations about the change of Bitcoin's rule set, it does help to put it all in clear and simple terms.

(Digressing a bit: @seweso had the interesting idea (though I am not sure whether it will indeed be a good idea in the end, but still something worthwhile to discuss) of letting nodes do a rule reduction change, e.g. to prevent SegWit. As miners could mine a spend-all transaction now, it does appear directly contrary to Satoshi's idea of using mining as the rule-consensus mechanism in the whitepaper and it also appears hard/impossible to pull off)

Your picture certainly does help to cut through the bullshit - and I think this is again something that's hard to attack from you.

Keep up the good work!

 

[HelloGuy]

I think this email is very important. We should try to promote it on conferences and magazines. I also believe that the mining nodes should have a more strict rule set than the common nodes.

 

[HelloGuy]

There are at least 2 kinds of rule sets:

1) When bitcoind is doing GetBlockTemplate, what kind of block it will generate? (Usually, we may call it kind of "policy")

2) When bitcoind get a new block from other peers, what kind of block it will accept? What kind of block it will accept immediately? or after some delay (as a punishment)?
[doublepost=1473444925][/doublepost]According to my understanding, there are at least 2 kinds of rule sets:

1) When bitcoind is doing GetBlockTemplate, what kind of block it will generate? (Usually, we may call it kind of "policy")

2) When bitcoind get a new block from other peers, what kind of block it will accept? What kind of block it will accept immediately? or after some delay (as a punishment)?

We may need to define it clearly in the consensus, so when developers are doing development, they will check everything that is a part of consensus, and make sure it has the right implementation. The rule sets will include lots of things but not only block size.

If we have a clear thinking according to the analysis of Peter R., we should know that in BIP109, the limitation of sigop is part of the consensus of BIP109. The BIP109 defines that:

1) It will generate blocks that have less sigop than the limit;

2) It will ONLY accept blocks that have less sigop than the limit;

But BU failed to implement this in the consensus as BIP109 defined.


(Disclaimer: I am not talking about whether BIP109 is good or not. Actually, I don't like BIP109. However, if BU does not support the sigop limitation, which is obvious according to the ideology of BU, we should just not vote for BIP109. We may chose some other ways to signal our support of increase the blocksize to 2MB, but we should not signal support for BIP109 without implement it.)