path: root/36/b66f6aa7b97666f7ceac486c14a74fa4cfb9e1

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C099C59
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 May 2017 20:10:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com
	[209.85.215.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE37213B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 May 2017 20:10:06 +0000 (UTC)
Received: by mail-lf0-f42.google.com with SMTP id m18so55066785lfj.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 30 May 2017 13:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=4/IBBex3kr6mncY09RIwBXPwA3VuSxmY1Fd+Xs0Qpb0=;
	b=S9KEustOljuZUoxqrtWh41N9zRJ4BhKizTDo9sf5tH24O5QIJXWJHmhyZHLXaWisaL
	iXY96gv66//Yv9/MdYwZ8WIDC0uVMJQcJbVLfHUcvpdSO+7JXWdaRlC5TZF6eFny6vgV
	oh3F/X1aEfKwakrcN9YOgs5fFX1mPALl3kehN56zml5UHN+GHImxb/We7DkOwIJNS8VV
	IB+ITpeeScINTXR76S67VkvJ0IHq2CwCQBWZw42msjO1IBy+WNXz7Ae7mJINGyHmHmRP
	o1TBjKkW1rUv/bzYkVGxEbRE1xBPf4Ae1fKcHZU/qMEstDps+25OVhkj9qbvJjEyIRNL
	KLuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=4/IBBex3kr6mncY09RIwBXPwA3VuSxmY1Fd+Xs0Qpb0=;
	b=trfIpGsnZaavic1F0artMY4U4dtw4kcymLPXNUvnIpwG7rpE+VNBXfy71NnGvbMHDU
	fme9WHbKqqNO51Xkihvm0rsDHCe0tcCAYyRsLUMZzI3TAoNkwN4HJMgBqXBl7ilK4vmb
	ipPPicg4E3yJU4g1IiOaItjtYIFUggClwLObkc+RDsz2CrMWm3f1hLUiW97DVJddSbp3
	1MASzwSDKo52yX9wOBQpiebjP3aGUUplRrzTtSAstIYvk7OIsjNHkwOChIue8tdNw7ez
	9ZCraqet6a5sf0Ffu3qcche7JbrLfriamJ3MT672nLM8dwIDvcPU9Kp+v9cjJuq+eYRw
	kmkw==
X-Gm-Message-State: AODbwcDx40so8Pvla/cdNGKUM5C820Q1seoZF2ti685gi4ysoW+oP3DZ
	x5Hs2haOyyIMe3mZnoRyMG9wlkrwbg==
X-Received: by 10.46.8.18 with SMTP id 18mr6686619lji.90.1496175005350; Tue,
	30 May 2017 13:10:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.80.4 with HTTP; Tue, 30 May 2017 13:10:04 -0700 (PDT)
Received: by 10.25.80.4 with HTTP; Tue, 30 May 2017 13:10:04 -0700 (PDT)
In-Reply-To: <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
References: <201705232023.40588.luke@dashjr.org>
	<CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
	<CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 30 May 2017 16:10:04 -0400
Message-ID: <CAAUaCyj2Syv-YHiAQGWoeOqvP7_wG_FFQg0630X9Ut0Y_qE3dw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary="f403045ec282b741fa0550c36352"
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: Tue, 30 May 2017 20:23:05 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Tue, 30 May 2017 20:10:08 -0000

--f403045ec282b741fa0550c36352
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd like to know this too.  Is it just that a 4MB blockmaxweight would
theoretically allow ~4MB blocks (if ~all witness data), which is too big?
Or is there a more subtle reason we still need blockmaxsize after a HF?


On May 30, 2017 9:28 AM, "Jorge Tim=C3=B3n via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Why not simply remove the (redundant after sw activation) 1 mb size
limit check and increasing the weight limit without changing the
discount or having 2 limits?


On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 an=
y
>> 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 u=
p
>> 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 a=
t
>> 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.)
>>
>> <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
>> size
>> 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
>> 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.
>>
>> =3D=3D=3DDeployment=3D=3D=3D
>>
>> This BIP is deployed by flag day, in the block where the median-past tim=
e
>> 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.
>> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--f403045ec282b741fa0550c36352
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>I&#39;d like to know this too.=C2=A0 Is it just that=
 a 4MB blockmaxweight would theoretically allow ~4MB blocks (if ~all witnes=
s data), which is too big?=C2=A0 Or is there a more subtle reason we still =
need blockmaxsize after a HF?</div><div dir=3D"auto"><br><div class=3D"gmai=
l_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On May 30, 2017 9:28 A=
M, &quot;Jorge Tim=C3=B3n via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why not simply=
 remove the (redundant after sw activation) 1 mb size<br>
limit check and increasing the weight limit without changing the<br>
discount or having 2 limits?<br>
<br>
<br>
On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Personally, I would prefer if a 2MB lock-in that uses BIP103 for the t=
iming.<br>
&gt;<br>
&gt; I think up to 20% per year can be absorbed by averages in bandwidth/CP=
U/RAM<br>
&gt; growth, of which bandwidth seems the most constraining.<br>
&gt;<br>
&gt; - Erik<br>
&gt;<br>
&gt;<br>
&gt; On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; In light of some recent discussions, I wrote up this BIP for a rea=
l 2 MB<br>
&gt;&gt; block<br>
&gt;&gt; size hardfork following Segwit BIP148 activation. This is not part=
 of any<br>
&gt;&gt; agreement I am party to, nor anything of that sort. Just something=
 to<br>
&gt;&gt; throw<br>
&gt;&gt; out there as a possible (and realistic) option.<br>
&gt;&gt;<br>
&gt;&gt; Note that I cannot recommend this to be adopted, since frankly 1 M=
B blocks<br>
&gt;&gt; really are still too large, and this blunt-style hardfork quite ri=
sky even<br>
&gt;&gt; with consensus. But if the community wishes to adopt (by unanimous=
<br>
&gt;&gt; consensus)<br>
&gt;&gt; a 2 MB block size hardfork, this is probably the best way to do it=
 right<br>
&gt;&gt; now.<br>
&gt;&gt; The only possible way to improve on this IMO would be to integrate=
 it into<br>
&gt;&gt; MMHF/&quot;spoonnet&quot; style hardfork (and/or add other unrelat=
ed-to-block-size<br>
&gt;&gt; HF<br>
&gt;&gt; improvements).<br>
&gt;&gt;<br>
&gt;&gt; I have left Author blank, as I do not intend to personally champio=
n this.<br>
&gt;&gt; Before it may be assigned a BIP number, someone else will need to =
step up<br>
&gt;&gt; to<br>
&gt;&gt; take on that role. Motivation and Rationale are blank because I do=
 not<br>
&gt;&gt; personally think there is any legitimate rationale for such a hard=
fork at<br>
&gt;&gt; this<br>
&gt;&gt; time; if someone adopts this BIP, they should complete these secti=
ons. (I<br>
&gt;&gt; can<br>
&gt;&gt; push a git branch with the BIP text if someone wants to fork it.)<=
br>
&gt;&gt;<br>
&gt;&gt; &lt;pre&gt;<br>
&gt;&gt; BIP: ?<br>
&gt;&gt; Layer: Consensus (hard fork)<br>
&gt;&gt; Title: Post-segwit 2 MB block size hardfork<br>
&gt;&gt; Author: FIXME<br>
&gt;&gt; Comments-Summary: No comments yet.<br>
&gt;&gt; Comments-URI: ?<br>
&gt;&gt; Status: Draft<br>
&gt;&gt; Type: Standards Track<br>
&gt;&gt; Created: 2017-05-22<br>
&gt;&gt; License: BSD-2-Clause<br>
&gt;&gt; &lt;/pre&gt;<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DAbstract=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; Legacy Bitcoin transactions are given the witness discount, and a =
block<br>
&gt;&gt; size<br>
&gt;&gt; limit of 2 MB is imposed.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DCopyright=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This BIP is licensed under the BSD 2-clause license.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DSpecification=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; Upon activation, a block size limit of 2000000 bytes is enforced.<=
br>
&gt;&gt; The block weight limit remains at 4000000 WU.<br>
&gt;&gt;<br>
&gt;&gt; The calculation of block weight is modified:<br>
&gt;&gt; all witness data, including both scriptSig (used by pre-segwit inp=
uts) and<br>
&gt;&gt; segwit witness data, is measured as 1 weight-unit (WU), while all =
other<br>
&gt;&gt; data<br>
&gt;&gt; in the block is measured as 4 WU.<br>
&gt;&gt;<br>
&gt;&gt; The witness commitment in the generation transaction is no longer<=
br>
&gt;&gt; required,<br>
&gt;&gt; and instead the txid merkle root in the block header is replaced w=
ith a<br>
&gt;&gt; hash<br>
&gt;&gt; of:<br>
&gt;&gt;<br>
&gt;&gt; 1. The witness reserved value.<br>
&gt;&gt; 2. The witness merkle root hash.<br>
&gt;&gt; 3. The transaction ID merkle root hash.<br>
&gt;&gt;<br>
&gt;&gt; The maximum size of a transaction stripped of witness data is limi=
ted to 1<br>
&gt;&gt; MB.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3D=3DDeployment=3D=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This BIP is deployed by flag day, in the block where the median-pa=
st time<br>
&gt;&gt; surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).<br>
&gt;&gt;<br>
&gt;&gt; It is assumed that when this flag day has been reached, Segwit has=
 been<br>
&gt;&gt; activated via BIP141 and/or BIP148.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DMotivation=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; FIXME<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DRationale=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; FIXME<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DBackwards compatibility=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This is a hardfork, and as such not backward compatible.<br>
&gt;&gt; It should not be deployed without consent of the entire Bitcoin co=
mmunity.<br>
&gt;&gt; Activation is scheduled for 18 months from the creation date of th=
is BIP,<br>
&gt;&gt; intended to give 6 months to establish consensus, and 12 months fo=
r<br>
&gt;&gt; deployment.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DReference implementation=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; FIXME<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div></div></div>

--f403045ec282b741fa0550c36352--