BUIP040: (passed) Emergent Consensus Parameters and Defaults for Large (>1MB) Blocks

[freetrader]

Is this merged PR into 0.12.1bu the code for this BUIP?

https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/164

Update: Thanks @sickpig for confirming :

https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/164#issuecomment-269486322

 

[dgenr8]

As @Peter R says, the merged code implements

max_block_sigops = 20,000 * (block size in megabytes rounded up)

This is a minimal change and has been well investigated. So far, so good.

What I don't understand, and recommend against, is introducing any more "emergent consensus variables", in anticipation of nodes choosing values for these. maxTxSize and blockSigopsPerMb should not be treated or described as emergent consensus variables.

There are MANY MORE numeric technical consensus values that are not exposed as "emergent consensus variables" and never should be. The examples are too many to enumerate but include coinbase maturity (100), number of coinbases (1), median time past set size (11), max script element size (520) ...

Also, no EC variable rollout is really usable without including communication of the settings to peers / users, or even including a way to report on which of the various limits was exceeded when a block is treated as excessive.

maxTxSize and blockSigopsPerMb should not be treated or described as emergent consensus variables.

EDIT: I wrote, incorrectly, that the merged change allows arbitrarily large txes, forgetting that for that, the sigop counting has to be fixed. With the current counting, tx size should continue to be capped at 1MB.

 

[freetrader]

I voted against this BUIP as I strongly believe the discussion has not reached a sufficient endpoint.
I'm not against a formulaic extension of tx max sizes / sigops, but I also don't believe there is a strong need to put these under EC, and even if it were done, this BUIP in its current form inadequately addresses the reporting / signalling needs around that. So my principal reasons for voting against it is that it I consider it "unfinished", and actually I would prefer something simpler that does not require EC.

I share Tom's view that the discussion around these consensus rules should be conducted with the wider community, even though I also agree with @solex view that the consensus rules defined for >1MB are novel and BU would technically be free to specify these as its members wished. Still, I don't think it's wise to forge ahead without consulting extensively with bigger community around this.

I don't see a need to rush these changes either. As such, I would consider voting for this BUIP in future when the discussion has been resolved and there is
a) wider consensus around the business requirement to raise these limits
b) clarity that what this BUIP proposes is the best option (I don't have that at the moment, I think the options have not been explored sufficiently)

 

[theZerg]

For others who are considering a "no" vote due to not enough discussion, let me remind you that discussion is not going to get us to > 1MB blocks. By voting "no" here you are essentially voting "yes" for what is currently in the code base for the upcoming release.

The perfect is sometimes the enemy of getting it done... especially when that discussion is with a group (Core) who doesn't even want > 1MB blocks. Core's obvious move at that point would be to delay and obfuscate discussion.

Representatives of the other clients have been part of the discussion and have stated their opinions...

 

[deadalnix]

By voting "no" here you are essentially voting "yes" for what is currently in the code base for the upcoming release.

To be blunt, this is reckless.

Consensus code is not something to be messed up with lightly. And it was. Now you are essentially asking us to chose between the mess that currently is or a rushed solution that is unclear if it actually is any good.

Many very important question have not been answered. The most important one being, is 20k sigops doable in 1MB. If not, then the sigops limit DOESN'T exist to boot and can be removed.

Second is, do we really need an emergent consensus variable for TX sizes ? We could very well limit them to 1MB, and have the limit lifted with the introduction of the next tx format, which we know is going to happen.

 

[deadalnix]

So we discussed this in slack and it turns out that 20k sigops is very much reachable.

 

[theZerg]

Consensus is Nakamoto Consensus in this network, not developer consensus.

And yes, I deliberately removed these limits before the BU organization was created so that these values had to be explicitly voted as YES, rather than remain as defacto-block-size-limits due to voter apathy or indifference.

"Big blockers" have been fighting "voter apathy" for years with many key industry participants verbally telling us they support large blocks but continuing to run core. This change leveled the playing field internally in BU. It removed certain restrictions in what BU ACCEPTS by default, making BU follow Nakamoto Consensus for these values, not Developer Consensus. And so the onus is on members to make a positive effort if they are really necessary.

You may still have questions, but that does not mean that this solution is rushed. It has been percolating for months, and is a simple extension of the current network limits.

To be blunt right back, your concerns seem like bikeshedding. Does it really matter much if the 1MB tx limit is configurable or static, especially since such a change is a simple recompile away? Are miners really going to change it in the foreseeable future? The reason I made it a configurable EC parameter is so that unforseeable issues or blockchain applications can be handled with just a configuration change.

And because making it an EC parameter follows the BU philosophy of following the longest most-difficulty chain, unless that chain breaks a rule that protects Bitcoin's function as money.

 

[deadalnix]

"Big blockers" have been fighting "voter apathy" for years with many key industry participants

I don't think that line of thinking is valid here because voters are BU member.

To be blunt right back, your concerns seem like bikeshedding.

For any other piece of code/part of the protocol I would agree. For the consensus related code, nothing is small or unimportant, as any change, no matter how trivial, can result in a chain split. As a result, what would be bikescheding for pretty much anything else becomes critical.

Does it really matter much if the 1MB tx limit is configurable or static, especially since such a change is a simple recompile away? Are miners really going to change it in the foreseeable future? The reason I made it a configurable EC parameter is so that unforseeable issues or blockchain applications can be handled with just a configuration change.

It is a problem for the following reason:
- The limit works around a problem with the current tx format.
- The limit is irrelevant with any new tx format - as long as it is properly made.
- A new tx format will be introduced anyway.

As a result, we already have a plan to phase out that limit. So, seen through that lense, the question is not should the limit be lifted or not, but should the limit be lifted before the new format is introduced.

I argue it should not. The benefit are short term and the cost are high. Any number added as EC require a common way to broadcast acceptance to peers, and require major actor to monitor it. In addition, any change to the consensus rule is there to stay pretty much forever, even if gated by a timestamp/block number. This is not the kind of costs one wants to impose on the network to achieve a short term goal.

And because making it an EC parameter follows the BU philosophy of following the longest most-difficulty chain, unless that chain breaks a rule that protects Bitcoin's function as money.

I fully agree with that philosophy, and that's why I'm here. However, one needs to understand that this kind of statement do refers to universal truth, more like guideline that will provide the right answer most of the time. In this case, the limit is going away either way, so adding it as EC doesn't seems to strike the right cost/benefit ratio.

 

[Roy Badami]

I've raised a point of order in the vote thread regarding the vote tally. See https://bitco.in/forum/threads/voting-is-closed-for-buips-6-38-40-41-42.1696/page-3#post-32750

 

[solex]

@Roy Badami
You point of order is noted, but I consider @deadalnix's vote as valid. it states "yes" first and twice for BUIP040.

2. Create a configurable "excessive transaction size" parameter, and set it to 1MB by default. Blocks with a transaction exceeding this size will be marked as excessive.

I do ask that the Developer @theZerg gives due consideration for omitting this change regarding transaction size, as per @deadalnix and @digitsu qualification as an exception.

 

[Roy Badami]

As per the other thread, I have withdrawn my point of order, and am happy for the officers to act as they see fit in the best interests of the project.

 

[deadalnix]

@Roy Badami
You point of order is noted, but I consider @deadalnix's vote as valid. it states "yes" first and twice for BUIP040.


I do ask that the Developer @theZerg gives due consideration for omitting this change regarding transaction size, as per @deadalnix and @digitsu qualification as an exception.

I think that's a reasonable way forward. I'd like to introduce an habit here, if people are willing to stick to it.

When something doesn't go as planned, it is good to come up with actionable items in order to either avoid the problem to reproduce, or mitigate the cost of the problem. This needs to be done carefully as items needs to have low ongoing costs (making reducing cost often preferable).

In this specific case, an obvious actionable item is that BUIP should stay focused. The way BUIP040 was made bundled together letting no other choice than to accept the whole bundle or reject it. By keeping BUIP focused, I'm sure both the discussion around the BUIPs and the vote would have gone smoother.

The second item is that change to the consensus rules (not the code itself, but the rules it enforces) should go through BUIP. BUIP040 ended being somewhat critical because changes where made in the first place that turned out to not be ideal.

 

[freetrader]

I verified according to the source code of v1.0.2.0 release that max block sigops and maximum transaction size are now under Emergent Consensus rules (i.e. block is marked as excessive if these limits are exceeded).

I would conclude that this BUIP is implemented as specified.