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.