Evening all,
The following BIP submission summarizes an idea that I've been tossing around for the last year. I understand that there may be nuances to SegWit and current consensus layer mechanisms that I may not fully understand, so please do not hesitate to shred the following text to pieces (I can handle it, I promise!).
Please note that this BIP assumes failure of the current softfork version of SegWit to activate in November -- something that I personally do not wish to see(!). However, given the real possibility of that happening, or perhaps just some newfound willingness (by "the community") to support a hardfork in lieu of a stalemate, I figure now is as good a time as any to share the idea in black and white.
I would really appreciate any/all feedback from the dev community on the technical merits (read: feasibility) of the idea. I would especially appreciate feedback from the SegWit developers who designed the current implementation in 0.14, as they likely have the most intimate knowledge of SegWit's nuances, and the entire BIP below would likely rely on their willingness to develop a hardfork version.
Nothing in this BIP is set in stone -- including all values and timelines -- but, I do hope the following text effectively captures the gist of the idea, and I do thank you ahead of time for your consideration of the proposal.
Respectfully,
Oliver Petruzel
-------------------------------------------------------------------------------
BIP: TBD
Layer: Consensus (hard fork)
Title: Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork
Author: Oliver Petruzel <opetruzel@gmail.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-04-05
License: PD
Abstract
This BIP proposes a method of combining an immediate base size increase to 2MB and a hardfork version of Segregated Witness (SegWit). The SegWit portion of the hardfork will leverage Discount Governors to control (or “govern”) the pace of the increase over a period of 145,152 blocks (approximately three (3) years).
Motivation
Given the possibility of the current softfork version of SegWit failing to activate in November 2017, this BIP aims to provide a hardfork alternative that would provide every user in the ecosystem with the fixes and changes they need to move forward with other great projects, while also tightly controlling the rate at which the total weight of blocks increases during the next three years. The predictable nature of the increases will provide miners, full node operators, and other users of the system with the ability to plan their development, resources, and operations accordingly. The fixed nature of the increases will also allow all full nodes to maintain a fixed set of rules for block validity (consensus).
Specification
The following changes will be made to the client:
* An immediate increase of base size to 2,000,000 bytes (perhaps leveraging code changes similar to those described in BIP 109).
· A hardfork version of SegWit that maintains all of the fixes present in the softfork version, including (but not limited to):
- Fix for the Malleability issue
- Linear scaling of sighash operations
- Signing of input values
- Increased security for multisig via pay-to-script-hash (P2SH)
- Script versioning
- Reducing UTXO growth
- Moving towards a single combined block limit
* In addition to those fixes listed above, the hardfork version of SegWit will include the following:
- Rather than using the fixed (75%) Discount found in the softfork version of SegWit, the hardfork version will leverage Discount Governing to control the pace of total block weight increases over a three (3) year period of time. The use of Discount Governors will allow a steady increase over that period from an immediate 2MB to 8MB total. There are several ways these increases can be handled – either by hardcoding the scheduled increases in the initial hardfork, or perhaps using subsequent softforks (additional input/discussion needed on the best way to handle the increases.
- Example increase schedule: +12.5% every 24,192 blocks (roughly every six (6) months). The increases would cap at the same 75% Discount rate found in the current softfork version of SegWit.
- Each time the Discount increases – every 24,192 blocks -- the Total Block Weight value would also increase to appropriately compensate for the added Discount.
Rationale
This hardfork employs a simple flag day deployment based on the median timestamp of previous blocks. Beyond this point, supporting nodes will not accept blocks with original rules. This ensures a deterministic and permanent departure with the original rules.
The use of Discount Governors to control the pace of the increase will result in a predictable and stable increase over the period of three (3) years.
If, at any time, the increases present problems for the network -- such as centralization concerns, negative impacts on the fee market(s), or other unforeseen problems -- a softfork could be leveraged to halt the increases.
The pace of the increases is described using the following table:
Time -- Base Size (bytes) -- Total Discount -- Total Block Weight (bytes)
Flag Day (FD) -- 2,000,000 -- 0.00% -- 2,000,000
FD+24,192 Blocks -- 2,000,000 -- 12.5% -- 2,285,715
FD+48,384 Blocks -- 2,000,000 -- 25.0% -- 2,666,667
FD+72,576 Blocks -- 2,000,000 -- 37.5% -- 3,200,000
FD+96,768 Blocks -- 2,000,000 -- 50.0% -- 4,000,000
FD+120,960 Blocks -- 2,000,000 -- 62.5% -- 5,333,334
FD+145,152 Blocks -- 2,000,000 -- 75.0% -- 8,000,000
Based on the above, the "effective blocksize increase," or the number of transactions per block, will also scale with each Discount increase.
Compatibility
This proposal requires a hardfork that does not maintain compatibility with previous clients and rules for consensus. It should not be deployed without widespread consensus.
Wallet software and other applications will also need to be upgraded to maintain compatibility.
The hardfork Flag Day will need to be coordinated/determined during the development and testing stages for the hardfork – estimated at 9-12 months to ensure a safe rollout of the hardfork to all network participants.
Reference implementation
TBD
Copyright
This document is placed in the public domain.