From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 162B2279 for ; Wed, 5 Apr 2017 05:18:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1DDB8151 for ; Wed, 5 Apr 2017 05:18:24 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id d2so3090488oig.1 for ; Tue, 04 Apr 2017 22:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=N+ShAqlgfAu4PDGVaoHtxx7UdH0/tMEpQ5voIbyIYRE=; b=KVJgWPKXKzdtPTwupDBM1e8XeAveVT9Pxm0UJ/dQGMRjQrFaI/ckm8QfEAko6XIxt3 1PiU8/WURZW9++3PSuXRa3H6YDTlQBOqAsGZ8rRbYtXw++8E/DlMkhmC3qO1cuJoymZ6 BqE60rX8WmAPT7GPRFrS9DGo5lGRkhUeUIDCHNGDerSavtYs875DAo0idPQZnBbmzXj3 0koSI57/QyFz2tbNvw18bwuqW2O2PJlEaUK8p6RFxSDJVfHx9lhv7ctSUQuD+DfaUYgS 0lqzT+EjGpvLcAud4kk38HZI7RB7q8n9arCul4nHxp2++5UT7fpS1B9O4spawnpLOI/u FEUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N+ShAqlgfAu4PDGVaoHtxx7UdH0/tMEpQ5voIbyIYRE=; b=bMU2h++uzmnkcCdGS6d0C4/bsjsF7eL1R3cTopMb6TvDWTaZfG145ZtiSrpn8MKgwO KVSYP0v52N2KVOKbYU9CP+vkthc93ODRNAy+2NzxayfdZuT8H5RgVQ1hKt8ObVCJpf0D Y7PwjP34HG9Ufvrvt0dtRAbPwzXwahwx71TFJV73DsXb7xnRGpgETh8Ak+pFWQy35ULp /J3mNMxv9mmBglPZsFaDnJrQDU86geW2Efnbq/RyFKgwJsW+mptShltELyDh0/3aPVFL 0td50K7hrz3IToEVpL/q/Jvl0dIyF8bfw0gUczpfZ7+LjZvMDw9ZMqxhbsLmE4N4UeQv W29w== X-Gm-Message-State: AFeK/H2yo24zbma/ERwXGxT4q7vFNm70i3tXw35C+tKJMQSVdCFvZS9r/Zng0R96b0PRRVWWfXXf8QXtXgxdxA== X-Received: by 10.157.15.38 with SMTP id 35mr13056115ott.201.1491369502832; Tue, 04 Apr 2017 22:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.19.74 with HTTP; Tue, 4 Apr 2017 22:18:22 -0700 (PDT) From: Oliver Petruzel Date: Wed, 5 Apr 2017 01:18:22 -0400 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c045e2671fd98054c648581 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 05 Apr 2017 07:46:08 +0000 Subject: [bitcoin-dev] Base Size Increase and Segregated Witness with Discount Governors (SW-DGov) Hardfork X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 05:18:25 -0000 --94eb2c045e2671fd98054c648581 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 =E2=80=9Cgovern=E2=80=9D) 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). =C2=B7 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 =E2=80=93 either by hardcoding the scheduled incre= ases 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 =E2=80=93 every 24,192 blocks -- the Tot= al 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 =E2=80=93 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. --94eb2c045e2671fd98054c648581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Evening all,

The following BIP submission summarize= s an idea that I've been tossing around for the last year.=C2=A0 I unde= rstand that there may be nuances to SegWit and current consensus layer mech= anisms 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 n= ote 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 hardf= ork 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 feedb= ack from the dev community on the technical merits (read: feasibility) of t= he idea. I would especially appreciate feedback from the SegWit developers = who designed the current implementation in 0.14, as they likely have the mo= st intimate knowledge of SegWit's nuances, and the entire BIP below wou= ld likely rely on their willingness to develop a hardfork version. =C2=A0
Nothing in this BIP is set in stone -- including all values and timel= ines -- 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 pr= oposal.


Respectfully,
Oliver Petruzel

----------------= ---------------------------------------------------------------

BIP:= =C2=A0TBD
Layer: Consensus (hard fork)
Title: Base Size Increase and= Segregated Witness with Discount Governors (SW-DGov) Hardfork
Author: O= liver Petruzel <opetruzel@gmail.c= om>
Comments-Summary: No comments yet.
Comments-URI:
Status= : Draft
Type: Standards Track
Created: 2017-04-05
License: PD
<= br>Abstract

This BIP proposes a method of combining an immediate bas= e size increase to 2MB and a hardfork version of Segregated Witness (SegWit= ).=C2=A0 The SegWit portion of the hardfork will leverage Discount Governor= s to control (or =E2=80=9Cgovern=E2=80=9D) the pace of the increase over a = period of 145,152 blocks (approximately three (3) years).


Motiva= tion

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 a= nd 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.=C2=A0 The predictable nature of the increases = will provide miners, full node operators, and other users of the system wit= h the ability to plan their development, resources, and operations accordin= gly.=C2=A0 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 lever= aging code changes similar to those described in BIP 109).

=C2=B7 A = hardfork version of SegWit that maintains all of the fixes present in the s= oftfork version, including (but not limited to):
- Fix for the Malleabil= ity issue
- Linear scaling of sighash operations
- Signing of input v= alues
- 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 tha= n using the fixed (75%) Discount found in the softfork version of SegWit, t= he hardfork version will leverage Discount Governing to control the pace of= total block weight increases over a three (3) year period of time.=C2=A0 T= he use of Discount Governors will allow a steady increase over that period = from an immediate 2MB to 8MB total.=C2=A0 There are several ways these incr= eases can be handled =E2=80=93 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.
- Exam= ple increase schedule: +12.5% every 24,192 blocks (roughly every six (6) mo= nths).=C2=A0 The increases would cap at the same 75% Discount rate found in= the current softfork version of SegWit.
- Each time the Discount increa= ses =E2=80=93 every 24,192 blocks -- the Total Block Weight value would als= o increase to appropriately compensate for the added Discount.


R= ationale

This hardfork employs a simple flag day deployment based on= the median timestamp of previous blocks. Beyond this point, supporting nod= es will not accept blocks with original rules.=C2=A0 This ensures a determi= nistic and permanent departure with the original rules.

The use of D= iscount Governors to control the pace of the increase will result in a pred= ictable and stable increase over the period of three (3) years.

If, = at any time, the increases present problems for the network -- such as cent= ralization concerns, negative impacts on the fee market(s), or other unfore= seen 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,&= quot; or the number of transactions per block, will also scale with each Di= scount increase.


Compatibility

This proposal requires a h= ardfork that does not maintain compatibility with previous clients and rule= s for consensus.=C2=A0 It should not be deployed without widespread consens= us.

Wallet software and other applications will also need to be upgr= aded to maintain compatibility.

The hardfork Flag Day will need to b= e coordinated/determined during the development and testing stages for the = hardfork =E2=80=93 estimated at 9-12 months to ensure a safe rollout of the= hardfork to all network participants.


Reference implementation<= br>
TBD


Copyright

This document is placed in the publi= c domain.
--94eb2c045e2671fd98054c648581--