BUIP040: Emergent Consensus Parameters and Defaults for Large (>1MB) Blocks
Proposer: Andrew Stone
Submitted: 2016-12-05
Status: passed

Bitcoin Unlimited currently does not constrain SIGOPs (signature
operations) or transaction size when accepting blocks (block generation
is constrained to network norms). The Parallel Validation (PV) BUIP
(passed) helps resolve this issue (and has many other usability
advantages), but for PV to succeed, it requires that another miner first
successfully mine a sibling block, and that the original block be
orphaned, losing money for that miner.

So it makes sense to create some “excessive” style limits that will
cause nodes and miners to reject extremely-long-validation-time blocks
and transactions unless the mining majority is allowing them. Please
read the following post for details of the analysis:
https://medium.com/@g.andrew.stone/…-for-block-validation-326417f944fa#.gmjyiqbjv

Based on this work, I propose that BU:

1. Mark blocks <= 1MB that exceed the current network limits as
   excessive, to stop “attackers” from attempting to push BU miner nodes
   temporarily onto another chain, causing them to orphan some blocks (at
   low BU hash rates, this “attack” costs the attacker much more to execute
   than it costs the target BU miners, so is not critical. At high hash
   rates, it simply causes the fork to large blocks). This means that these
   blocks must contain 20000 or fewer “legacy” sigops (following the
   algorithm in the code today, a discussion of which is beyond the scope
   of this document).

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.

3. Create a configurable “excessive sigops per MB” parameter, and set it
   to 20000 by default. The algorithm will first round the block size UP to
   the nearest MB, and then apply this rule. For example a 1.5 MB and a 2
   MB block will each allow 40000 sigops.

If passed, this BUIP will be extended with the exact implemention of the
“excessive sigops” metric so that other implementations can copy the
exact logic (preserving rounding behavior, for example). However, this
is not a “consensus-critical” issue. Due to the emergent consensus
algorithm there will be no blockchain fork if other implementations
calculate this parameter differently. In the worst case miners may
orphan a block or two while the problem is discovered and is fixed.

To pre-answer some of the inevitable discussion:

I originally considered limiting transaction size in a > 1MB block to
100KB since that is the limit of a transaction in the Satoshi client’s
P2P protocol. However, some mining pools need large 1-to-many
transactions to pay their hashers. This style of transaction is very
quick to validate, since it only typically contains 1 actual sigop, even
though the “legacy” sigops calcuation may return 20000.