path: root/1c/7c2fd1c328bb43b3895ef4550f481b7a24e9b2

Return-Path: <opetruzel@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 162B2279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 05:18:24 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id d2so3090488oig.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <opetruzel@gmail.com>
Date: Wed, 5 Apr 2017 01:18:22 -0400
Message-ID: <CALhpmH0hRs924rSVKGjXMXW0+HPQOQhLJtOd5NKJdz=z7d=YQA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
=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

<div dir=3D"ltr">Evening all,<br><br>The following BIP submission summarize=
s an idea that I&#39;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!).<br><br>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 &quot;the community&quot;) 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.<br><br>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&#39;s nuances, and the entire BIP below wou=
ld likely rely on their willingness to develop a hardfork version. =C2=A0<b=
r><br>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.<br><br><br>Respectfully,<br>Oliver Petruzel<br><br>----------------=
---------------------------------------------------------------<br><br>BIP:=
 =C2=A0TBD<br>Layer: Consensus (hard fork)<br>Title: Base Size Increase and=
 Segregated Witness with Discount Governors (SW-DGov) Hardfork<br>Author: O=
liver Petruzel &lt;<a href=3D"mailto:opetruzel@gmail.com">opetruzel@gmail.c=
om</a>&gt;<br>Comments-Summary: No comments yet.<br>Comments-URI:<br>Status=
: Draft<br>Type: Standards Track<br>Created: 2017-04-05<br>License: PD<br><=
br>Abstract<br><br>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).<br><br><br>Motiva=
tion<br><br>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).<br><br><b=
r>Specification<br><br>The following changes will be made to the client:<br=
><br>* An immediate increase of base size to 2,000,000 bytes (perhaps lever=
aging code changes similar to those described in BIP 109).<br><br>=C2=B7 A =
hardfork version of SegWit that maintains all of the fixes present in the s=
oftfork version, including (but not limited to):<br>- Fix for the Malleabil=
ity issue<br>- Linear scaling of sighash operations<br>- Signing of input v=
alues<br>- Increased security for multisig via pay-to-script-hash (P2SH)<br=
>- Script versioning<br>- Reducing UTXO growth<br>- Moving towards a single=
 combined block limit<br><br>* In addition to those fixes listed above, the=
 hardfork version of SegWit will include the following:<br><br>- 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.<br>- 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.<br>- 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.<br><br><br>R=
ationale<br><br>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.<br><br>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.<br><br>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.<br><b=
r>The pace of the increases is described using the following table:<br><br>=
Time -- Base Size (bytes) -- Total Discount -- Total Block Weight (bytes)<b=
r>Flag Day (FD) -- 2,000,000 -- 0.00% -- 2,000,000<br>FD+24,192 Blocks -- 2=
,000,000 -- 12.5% -- 2,285,715<br>FD+48,384 Blocks -- 2,000,000 -- 25.0% --=
 2,666,667<br>FD+72,576 Blocks -- 2,000,000 -- 37.5% -- 3,200,000<br>FD+96,=
768 Blocks -- 2,000,000 -- 50.0% -- 4,000,000<br>FD+120,960 Blocks -- 2,000=
,000 -- 62.5% -- 5,333,334<br>FD+145,152 Blocks -- 2,000,000 -- 75.0% -- 8,=
000,000<br><br>Based on the above, the &quot;effective blocksize increase,&=
quot; or the number of transactions per block, will also scale with each Di=
scount increase.<br><br><br>Compatibility<br><br>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.<br><br>Wallet software and other applications will also need to be upgr=
aded to maintain compatibility.<br><br>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.<br><br><br>Reference implementation<=
br><br>TBD<br><br><br>Copyright<br><br>This document is placed in the publi=
c domain.</div>

--94eb2c045e2671fd98054c648581--