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 C7F7ABC4 for ; Tue, 23 May 2017 23:07:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC3361B4 for ; Tue, 23 May 2017 23:07:42 +0000 (UTC) Received: by mail-qk0-f171.google.com with SMTP id y201so142212943qka.0 for ; Tue, 23 May 2017 16:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sQCuWmLY7AE2H9AgjiyWT3fhL8T3bYfU9lT8KqjT7u4=; b=uHDg0ryXj3ekE03cWSVMx6CvceX5SqDS0ydhdKyAFI8YFcjXS5O6lp61khUKPMy6jz h/YnfIwp4qrj68benh763smxDE/vKkrP+ba079yQh9GeKMPnVtHjGDe8tWYfCzSet9/p 0ChjT/hd/4wn8yfWTo8ACrjmxzQEC0eGp4I5/JyPj9gjGSz3jfEIV74fuFnOdy7i/ahz OA8ylCSpWB1WVF7OmSbm7+LT7Pd3xPVOz1yCY7K4U9he3wKXPx1Y0zDqjVdCJcFkdzIm 8VHhhR/bUCzbOlTZUyYdR0Af73jsPkC+210PKkqnSBhxzTu2hgeLtGlkKcIqXSUIzmtl KazQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sQCuWmLY7AE2H9AgjiyWT3fhL8T3bYfU9lT8KqjT7u4=; b=ZjGE797LwPTGQJdpG5ROmlFSGHuQv/9HBPeCphY89lI6b4l2djcyu4I0HG0cCUQ5GJ LsPIthnw674iju95/lE0WFtRFThio6SvAcEjjrWH6p0YcpSBiuEnP4OWX73UkrHlFKrz p2JJgKbBMlRdPp2rmXFw6hzT8hKW4NfV8E5UcQfWQ4DmS2vUdGfPGt2lEHh7cSCZ1nNh MKFdWYW2VjenTlD1hfZGv4vpTK/OU1WtXRX+4LrqiGv1X5f0NXlCW2SQ3Iu3sEb3XGQ5 QpKyv2RO+YMI+pPD4BWxsTOWRk+SdeCldPypNR4XdVePZb/ickOk+eAIm84Tj7cJySm+ Rz9Q== X-Gm-Message-State: AODbwcBqoIU46c5UgU31P98OgazVu2PU6m87IdT05TinFuqe1mKtt5+u 6EO9kEOjM6FShTX9tiVy7/PfIkQB3w== X-Received: by 10.55.141.67 with SMTP id p64mr29315677qkd.164.1495580861891; Tue, 23 May 2017 16:07:41 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.237.48.102 with HTTP; Tue, 23 May 2017 16:07:41 -0700 (PDT) In-Reply-To: <201705232023.40588.luke@dashjr.org> References: <201705232023.40588.luke@dashjr.org> From: Erik Aronesty Date: Tue, 23 May 2017 19:07:41 -0400 X-Google-Sender-Auth: rONvT9kwLOYlW3LO_TYd3jqZKHM Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="94eb2c084666018a1e0550390e09" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham 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, 24 May 2017 01:58:07 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 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: Tue, 23 May 2017 23:07:43 -0000 --94eb2c084666018a1e0550390e09 Content-Type: text/plain; charset="UTF-8" Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing. I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems the most constraining. - Erik On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > In light of some recent discussions, I wrote up this BIP for a real 2 MB > block > size hardfork following Segwit BIP148 activation. This is not part of any > agreement I am party to, nor anything of that sort. Just something to throw > out there as a possible (and realistic) option. > > Note that I cannot recommend this to be adopted, since frankly 1 MB blocks > really are still too large, and this blunt-style hardfork quite risky even > with consensus. But if the community wishes to adopt (by unanimous > consensus) > a 2 MB block size hardfork, this is probably the best way to do it right > now. > The only possible way to improve on this IMO would be to integrate it into > MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF > improvements). > > I have left Author blank, as I do not intend to personally champion this. > Before it may be assigned a BIP number, someone else will need to step up > to > take on that role. Motivation and Rationale are blank because I do not > personally think there is any legitimate rationale for such a hardfork at > this > time; if someone adopts this BIP, they should complete these sections. (I > can > push a git branch with the BIP text if someone wants to fork it.) > > 
> BIP: ?
> Layer: Consensus (hard fork)
> Title: Post-segwit 2 MB block size hardfork
> Author: FIXME
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-2-Clause
>
> > ==Abstract== > > Legacy Bitcoin transactions are given the witness discount, and a block > size > limit of 2 MB is imposed. > > ==Copyright== > > This BIP is licensed under the BSD 2-clause license. > > ==Specification== > > Upon activation, a block size limit of 2000000 bytes is enforced. > The block weight limit remains at 4000000 WU. > > The calculation of block weight is modified: > all witness data, including both scriptSig (used by pre-segwit inputs) and > segwit witness data, is measured as 1 weight-unit (WU), while all other > data > in the block is measured as 4 WU. > > The witness commitment in the generation transaction is no longer required, > and instead the txid merkle root in the block header is replaced with a > hash > of: > > 1. The witness reserved value. > 2. The witness merkle root hash. > 3. The transaction ID merkle root hash. > > The maximum size of a transaction stripped of witness data is limited to 1 > MB. > > ===Deployment=== > > This BIP is deployed by flag day, in the block where the median-past time > surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). > > It is assumed that when this flag day has been reached, Segwit has been > activated via BIP141 and/or BIP148. > > ==Motivation== > > FIXME > > ==Rationale== > > FIXME > > ==Backwards compatibility== > > This is a hardfork, and as such not backward compatible. > It should not be deployed without consent of the entire Bitcoin community. > Activation is scheduled for 18 months from the creation date of this BIP, > intended to give 6 months to establish consensus, and 12 months for > deployment. > > ==Reference implementation== > > FIXME > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c084666018a1e0550390e09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Personally, I would prefer if a 2MB lock-in that uses BIP1= 03 for the timing. =C2=A0=C2=A0

I think up to 20% per year can be ab= sorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems th= e most constraining.

- Erik

=
On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
In light of some = recent discussions, I wrote up this BIP for a real 2 MB block
size hardfork following Segwit BIP148 activation. This is not part of any agreement I am party to, nor anything of that sort. Just something to throw=
out there as a possible (and realistic) option.

Note that I cannot recommend this to be adopted, since frankly 1 MB blocks<= br> really are still too large, and this blunt-style hardfork quite risky even<= br> with consensus. But if the community wishes to adopt (by unanimous consensu= s)
a 2 MB block size hardfork, this is probably the best way to do it right no= w.
The only possible way to improve on this IMO would be to integrate it into<= br> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-blo= ck-size HF
improvements).

I have left Author blank, as I do not intend to personally champion this. Before it may be assigned a BIP number, someone else will need to step up t= o
take on that role. Motivation and Rationale are blank because I do not
personally think there is any legitimate rationale for such a hardfork at t= his
time; if someone adopts this BIP, they should complete these sections. (I c= an
push a git branch with the BIP text if someone wants to fork it.)

<pre>
BIP: ?
Layer: Consensus (hard fork)
Title: Post-segwit 2 MB block size hardfork
Author: FIXME
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-2-Clause
</pre>

=3D=3DAbstract=3D=3D

Legacy Bitcoin transactions are given the witness discount, and a block siz= e
limit of 2 MB is imposed.

=3D=3DCopyright=3D=3D

This BIP is licensed under the BSD 2-clause license.

=3D=3DSpecification=3D=3D

Upon activation, a block size limit of 2000000 bytes is enforced.
The block weight limit remains at 4000000 WU.

The calculation of block weight is modified:
all witness data, including both scriptSig (used by pre-segwit inputs) and<= br> segwit witness data, is measured as 1 weight-unit (WU), while all other dat= a
in the block is measured as 4 WU.

The witness commitment in the generation transaction is no longer required,=
and instead the txid merkle root in the block header is replaced with a has= h
of:

1. The witness reserved value.
2. The witness merkle root hash.
3. The transaction ID merkle root hash.

The maximum size of a transaction stripped of witness data is limited to 1 = MB.

=3D=3D=3DDeployment=3D=3D=3D

This BIP is deployed by flag day, in the block where the median-past time surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).

It is assumed that when this flag day has been reached, Segwit has been
activated via BIP141 and/or BIP148.

=3D=3DMotivation=3D=3D

FIXME

=3D=3DRationale=3D=3D

FIXME

=3D=3DBackwards compatibility=3D=3D

This is a hardfork, and as such not backward compatible.
It should not be deployed without consent of the entire Bitcoin community.<= br> Activation is scheduled for 18 months from the creation date of this BIP, intended to give 6 months to establish consensus, and 12 months for
deployment.

=3D=3DReference implementation=3D=3D

FIXME



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--94eb2c084666018a1e0550390e09--