path: root/31/c2c941c45d5b6d3d74f23a43da8d498f2bbad2

Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D88978DC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 12:13:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
	[209.85.218.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06B7710A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 12:13:18 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id j15so155753905oih.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 04:13:18 -0800 (PST)
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=7DHPeUptYNQaa45lPVPA2Hw3E8qpjmtf5jjzD30vZXc=;
	b=g3YUNc1zIfOTgNhFLHzuvXOIBmNerXXHPW6U8XPlMd1AYy3L6Zk/IaReVw7OelqsAS
	aZvdQLjbFMpRzLLbv8bbiRotfqU6UfS6hDk+p1XYGJ+m7ObxI3IFNnPAiLAThBzYbHGd
	CpOLdG/9g5VKTByNHLZTU4OM/HNUJaTdjZVNgSceLm3FCKDG8W8+ANzy7cHBWxqqXouU
	kULVq9/JW4PSAdziwuH2te/v9WjC/QuYxYXwBpGAxNBm87EsOQwyHOJwV0auGffPnpQJ
	QWx2F8LfKhe664vhMuZjUXnYa7QmuvHQUuvEaGongtlgFMLa8NGnt4RZlClwMvSMS24v
	Osag==
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=7DHPeUptYNQaa45lPVPA2Hw3E8qpjmtf5jjzD30vZXc=;
	b=kH2PXsr4bNye2iO0mf7kG0MICXGBHS7n0yu4Xuo+0fotqonpHaEcaReW+1qyOJUVpZ
	RCrxal8vXzTTCq7i87YRGMbmeszHUvIlGI08v/WYPTrD4lB1Uhx4RUFaUs6LuDSMWwPl
	LAFrQjNMQUudbDS4VyfuJc2Jvj1dfb22EOKY1gUv03dJIUgksVT1Arfgx4Bn9Nk7sD1w
	ri+F/xgXSc7MxmjGtW2q4IL+VKLnHAe0AgnIT7DE3MWml79HrQ58aR3lTQUfJ+YxUU7p
	ejG7v9Iho/Dj5V5R9/jZttlINWAOMrKJjjVcNHIABzPXgugsITt7uPnFHH2MtDiydIOp
	u1Nw==
X-Gm-Message-State: AIkVDXKm/DTuHUaNttl81ZIp7A4ttC938YTyBbPZs7VCuvvJvJWCQMpHbfKAzm56k70QMgvaobtAg6/k54xAWA==
X-Received: by 10.202.63.85 with SMTP id m82mr4764022oia.151.1485519198030;
	Fri, 27 Jan 2017 04:13:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.9.72 with HTTP; Fri, 27 Jan 2017 04:12:57 -0800 (PST)
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Fri, 27 Jan 2017 13:12:57 +0100
Message-ID: <CAEgR2PHnAGUjCyc9unkPnh+dj_zBa7SjHuvFV+VLKk6G-k3x0A@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113dd4921b16b5054712645d
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: Fri, 27 Jan 2017 13:52:24 +0000
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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: Fri, 27 Jan 2017 12:13:20 -0000

--001a113dd4921b16b5054712645d
Content-Type: text/plain; charset=UTF-8

Your BIP implementation should stress the capacity to softfork the rate of
blocksize increase if necessary. You briefly mention that:

*If over time, this growth factor is beyond what the actual technology
offers, the intention should be to soft fork a tighter limit.*

However this can work both ways so that the rate can potentially be
increased also. I think just mentioning this will soothe a lot of future
critiques.

Daniele























































*Message: 5Date: Fri, 27 Jan 2017 01:06:59 +0000From: Luke Dashjr
<luke@dashjr.org
<luke@dashjr.org>>To: bitcoin-dev@lists.linuxfoundation.org
<bitcoin-dev@lists.linuxfoundation.org>Subject: [bitcoin-dev] Three
hardfork-related BIPsMessage-ID: <201701270107.01092.luke@dashjr.org
<201701270107.01092.luke@dashjr.org>>Content-Type: Text/Plain;
charset="utf-8"I've put together three hardfork-related BIPs. This is
parallel to the ongoingresearch into the MMHF/SHF WIP BIP, which might
still be best long-term.1) The first is a block size limit protocol change.
It also addresses threecriticisms of segwit: 1) segwit increases the block
size limit which isalready considered by many to be too large; 2) segwit
treats pre-segwittransactions ?unfairly? by giving the witness discount
only to segwittransactions; and 3) that spam blocks can be larger than
blocks mininglegitimate transactions. This proposal may (depending on
activation date)initially reduce the block size limit to a more sustainable
size in the short-term, and gradually increase it up over the long-term to
31 MB; it will alsoextend the witness discount to non-segwit transactions.
Should the initialblock size limit reduction prove to be too controversial,
miners can simplywait to activate it until closer to the point where it
becomes acceptableand/or increases the limit. However, since the BIP
includes a hardfork, theeventual block size increase needs community
consensus before it can bedeployed. Proponents of block size increases
should note that this BIP doesnot interfere with another more aggressive
block size increase hardfork in themeantime. I believe I can immediately
recommend this for adoption; however,peer and community review are welcome
to suggest
changes.Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
<https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki>Code:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize
<https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize>(consensus
code changes only)2) The second is a *preparatory* change, that should
allow triviallytransforming certain classes of hardforks into softforks in
the future. Itessentially says that full nodes should relax their rule
enforcement, aftersufficient time that would virtually guarantee they have
ceased to beenforcing the full set of rules anyway. This allows these
relaxed rules to bemodified or removed in a softfork, provided the proposal
to do so is acceptedand implemented with enough advance notice. Attempting
to implement this hasproven more complicated than I originally expected,
and it may make more sensefor full nodes to simply stop functioning (with a
user override) after thecut-off date). In light of this, I do not yet
recommend its adoption, but amposting it for review and comments
only.Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
<https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>3)
Third is an anti-replay softfork which can be used to prevent replayattacks
whether induced by a hardfork-related chain split, or even in
ordinaryoperation. It does this by using a new opcode
(OP_CHECKBLOCKATHEIGHT) for theBitcoin scripting system that allows
construction of transactions which arevalid only on specific
blockchains.Text:
https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki
<https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki>Luke*
Daniele Pinna, Ph.D

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

<div dir=3D"ltr"><div><span style=3D"font-size:12.8px">Your BIP implementat=
ion should stress the capacity to softfork the rate of blocksize increase i=
f necessary. You briefly mention that:=C2=A0</span><br></div><div><span sty=
le=3D"font-size:12.8px"><br></span><span style=3D"color:rgb(51,51,51);font-=
family:-apple-system,blinkmacsystemfont,&quot;segoe ui&quot;,helvetica,aria=
l,sans-serif,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&quot=
;segoe ui symbol&quot;;font-size:16px;line-height:24px"><i>If over time, th=
is growth factor is beyond what the actual technology offers, the intention=
 should be to soft fork a tighter limit.</i></span><span style=3D"font-size=
:12.8px"><i><br></i></span></div><div><span style=3D"color:rgb(51,51,51);fo=
nt-family:-apple-system,blinkmacsystemfont,&quot;segoe ui&quot;,helvetica,a=
rial,sans-serif,&quot;apple color emoji&quot;,&quot;segoe ui emoji&quot;,&q=
uot;segoe ui symbol&quot;;font-size:16px;line-height:24px"><i><br></i></spa=
n></div><div><span style=3D"font-size:12.8px">However this can work both wa=
ys so that the rate can potentially be increased also. I think just mention=
ing this will soothe a lot of future critiques.</span><br></div><div><i sty=
le=3D"font-size:12.8px"><br></i></div><div><span style=3D"font-size:12.8px"=
>Daniele</span></div><div><i style=3D"font-size:12.8px"><br></i></div><div>=
<i style=3D"font-size:12.8px"><br></i></div><div><i style=3D"font-size:12.8=
px"><br></i></div><i><span style=3D"font-size:12.8px">Message: 5</span><br =
style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">Date: Fri, 27 J=
an 2017 01:06:59 +0000</span><br style=3D"font-size:12.8px"><span style=3D"=
font-size:12.8px">From: Luke Dashjr &lt;</span><a href=3D"mailto:luke@dashj=
r.org" style=3D"font-size:12.8px">luke@dashjr.org</a><span style=3D"font-si=
ze:12.8px">&gt;</span><br style=3D"font-size:12.8px"><span style=3D"font-si=
ze:12.8px">To:=C2=A0</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" style=3D"font-size:12.8px">bitcoin-dev@lists.<wbr>linuxfoundation.=
org</a><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">Subj=
ect: [bitcoin-dev] Three hardfork-related BIPs</span><br style=3D"font-size=
:12.8px"><span style=3D"font-size:12.8px">Message-ID: &lt;</span><a href=3D=
"mailto:201701270107.01092.luke@dashjr.org" style=3D"font-size:12.8px">2017=
01270107.01092.luke@<wbr>dashjr.org</a><span style=3D"font-size:12.8px">&gt=
;</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">Con=
tent-Type: Text/Plain;=C2=A0 charset=3D&quot;utf-8&quot;</span><br style=3D=
"font-size:12.8px"><br style=3D"font-size:12.8px"><span style=3D"font-size:=
12.8px">I&#39;ve put together three hardfork-related BIPs. This is parallel=
 to the ongoing</span><br style=3D"font-size:12.8px"><span style=3D"font-si=
ze:12.8px">research into the MMHF/SHF WIP BIP, which might still be best lo=
ng-term.</span><br style=3D"font-size:12.8px"><br style=3D"font-size:12.8px=
"><span style=3D"font-size:12.8px">1) The first is a block size limit proto=
col change. It also addresses three</span><br style=3D"font-size:12.8px"><s=
pan style=3D"font-size:12.8px">criticisms of segwit: 1) segwit increases th=
e block size limit which is</span><br style=3D"font-size:12.8px"><span styl=
e=3D"font-size:12.8px">already considered by many to be too large; 2) segwi=
t treats pre-segwit</span><br style=3D"font-size:12.8px"><span style=3D"fon=
t-size:12.8px">transactions ?unfairly? by giving the witness discount only =
to segwit</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.=
8px">transactions; and 3) that spam blocks can be larger than blocks mining=
</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">legi=
timate transactions. This proposal may (depending on activation date)</span=
><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">initially =
reduce the block size limit to a more sustainable size in the short-</span>=
<br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">term, and g=
radually increase it up over the long-term to 31 MB; it will also</span><br=
 style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">extend the wit=
ness discount to non-segwit transactions. Should the initial</span><br styl=
e=3D"font-size:12.8px"><span style=3D"font-size:12.8px">block size limit re=
duction prove to be too controversial, miners can simply</span><br style=3D=
"font-size:12.8px"><span style=3D"font-size:12.8px">wait to activate it unt=
il closer to the point where it becomes acceptable</span><br style=3D"font-=
size:12.8px"><span style=3D"font-size:12.8px">and/or increases the limit. H=
owever, since the BIP includes a hardfork, the</span><br style=3D"font-size=
:12.8px"><span style=3D"font-size:12.8px">eventual block size increase need=
s community consensus before it can be</span><br style=3D"font-size:12.8px"=
><span style=3D"font-size:12.8px">deployed. Proponents of block size increa=
ses should note that this BIP does</span><br style=3D"font-size:12.8px"><sp=
an style=3D"font-size:12.8px">not interfere with another more aggressive bl=
ock size increase hardfork in the</span><br style=3D"font-size:12.8px"><spa=
n style=3D"font-size:12.8px">meantime. I believe I can immediately recommen=
d this for adoption; however,</span><br style=3D"font-size:12.8px"><span st=
yle=3D"font-size:12.8px">peer and community review are welcome to suggest c=
hanges.</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8p=
x">Text:=C2=A0</span><a href=3D"https://github.com/luke-jr/bips/blob/bip-bl=
ksize/bip-blksize.mediawiki" rel=3D"noreferrer" target=3D"_blank" style=3D"=
font-size:12.8px">https://github.com/luke-jr/<wbr>bips/blob/bip-blksize/bip=
-<wbr>blksize.mediawiki</a><br style=3D"font-size:12.8px"><span style=3D"fo=
nt-size:12.8px">Code:=C2=A0</span><a href=3D"https://github.com/bitcoin/bit=
coin/compare/master...luke-jr:bip-blksize" rel=3D"noreferrer" target=3D"_bl=
ank" style=3D"font-size:12.8px">https://github.com/bitcoin/<wbr>bitcoin/com=
pare/master...luke-<wbr>jr:bip-blksize</a><br style=3D"font-size:12.8px"><s=
pan style=3D"font-size:12.8px">(consensus code changes only)</span><br styl=
e=3D"font-size:12.8px"><br style=3D"font-size:12.8px"><span style=3D"font-s=
ize:12.8px">2) The second is a *preparatory* change, that should allow triv=
ially</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"=
>transforming certain classes of hardforks into softforks in the future. It=
</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">esse=
ntially says that full nodes should relax their rule enforcement, after</sp=
an><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">sufficie=
nt time that would virtually guarantee they have ceased to be</span><br sty=
le=3D"font-size:12.8px"><span style=3D"font-size:12.8px">enforcing the full=
 set of rules anyway. This allows these relaxed rules to be</span><br style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">modified or removed =
in a softfork, provided the proposal to do so is accepted</span><br style=
=3D"font-size:12.8px"><span style=3D"font-size:12.8px">and implemented with=
 enough advance notice. Attempting to implement this has</span><br style=3D=
"font-size:12.8px"><span style=3D"font-size:12.8px">proven more complicated=
 than I originally expected, and it may make more sense</span><br style=3D"=
font-size:12.8px"><span style=3D"font-size:12.8px">for full nodes to simply=
 stop functioning (with a user override) after the</span><br style=3D"font-=
size:12.8px"><span style=3D"font-size:12.8px">cut-off date). In light of th=
is, I do not yet recommend its adoption, but am</span><br style=3D"font-siz=
e:12.8px"><span style=3D"font-size:12.8px">posting it for review and commen=
ts only.</span><br style=3D"font-size:12.8px"><span style=3D"font-size:12.8=
px">Text:=C2=A0</span><a href=3D"https://github.com/luke-jr/bips/blob/bip-h=
fprep/bip-hfprep.mediawiki" rel=3D"noreferrer" target=3D"_blank" style=3D"f=
ont-size:12.8px">https://github.com/luke-jr/<wbr>bips/blob/bip-hfprep/bip-<=
wbr>hfprep.mediawiki</a><br style=3D"font-size:12.8px"><br style=3D"font-si=
ze:12.8px"><span style=3D"font-size:12.8px">3) Third is an anti-replay soft=
fork which can be used to prevent replay</span><br style=3D"font-size:12.8p=
x"><span style=3D"font-size:12.8px">attacks whether induced by a hardfork-r=
elated chain split, or even in ordinary</span><br style=3D"font-size:12.8px=
"><span style=3D"font-size:12.8px">operation. It does this by using a new o=
pcode (OP_CHECKBLOCKATHEIGHT) for the</span><br style=3D"font-size:12.8px">=
<span style=3D"font-size:12.8px">Bitcoin scripting system that allows const=
ruction of transactions which are</span><br style=3D"font-size:12.8px"><spa=
n style=3D"font-size:12.8px">valid only on specific blockchains.</span><br =
style=3D"font-size:12.8px"><span style=3D"font-size:12.8px">Text:=C2=A0</sp=
an><a href=3D"https://github.com/luke-jr/bips/blob/bip-noreplay/bip-norepla=
y.mediawiki" rel=3D"noreferrer" target=3D"_blank" style=3D"font-size:12.8px=
">https://github.com/luke-jr/<wbr>bips/blob/bip-noreplay/bip-<wbr>noreplay.=
mediawiki</a><br style=3D"font-size:12.8px"><br style=3D"font-size:12.8px">=
<span style=3D"font-size:12.8px">Luke</span></i><br clear=3D"all"><div><div=
 class=3D"gmail_signature"><div dir=3D"ltr"><div>Daniele Pinna, Ph.D</div><=
/div></div></div>
</div>

--001a113dd4921b16b5054712645d--