[bitcoin-dev] Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork

[bitcoin-dev] Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork

[Oliver Petruzel]

[-- Attachment #1: Type: text/plain, Size: 6515 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 6760 bytes --]