Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D88978DC for ; 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 ; Fri, 27 Jan 2017 12:13:18 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id j15so155753905oih.2 for ; 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 Date: Fri, 27 Jan 2017 13:12:57 +0100 Message-ID: To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >To: 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 Code: 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 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 Luke* Daniele Pinna, Ph.D --001a113dd4921b16b5054712645d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Your BIP implementat= ion should stress the capacity to softfork the rate of blocksize increase i= f necessary. You briefly mention that:=C2=A0

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

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.

Daniele

=

Message: 5
Date: Fri, 27 J= an 2017 01:06:59 +0000
From: Luke Dashjr <luke@dashjr.org>
To:=C2=A0bitcoin-dev@lists.linuxfoundation.= org
Subj= ect: [bitcoin-dev] Three hardfork-related BIPs
Message-ID: <2017= 01270107.01092.luke@dashjr.org>= ;
Con= tent-Type: Text/Plain;=C2=A0 charset=3D"utf-8"

I've put together three hardfork-related BIPs. This is parallel= to the ongoing
research into the MMHF/SHF WIP BIP, which might still be best lo= ng-term.

1) The first is a block size limit proto= col change. It also addresses three
criticisms of segwit: 1) segwit increases th= e block size limit which is
already considered by many to be too large; 2) segwi= t treats pre-segwit
transactions ?unfairly? by giving the witness discount only = to segwit
transactions; and 3) that spam blocks can be larger than blocks mining=
legi= timate transactions. This proposal may (depending on activation date)
initially = reduce the block size limit to a more sustainable size in the short-=
term, and g= radually increase it up over the long-term to 31 MB; it will alsoextend the wit= ness discount to non-segwit transactions. Should the initial
block size limit re= duction prove to be too controversial, miners can simply
wait to activate it unt= il closer to the point where it becomes acceptable
and/or increases the limit. H= owever, since the BIP includes a hardfork, the
eventual block size increase need= s community consensus before it can be
deployed. Proponents of block size increa= ses should note that this BIP does
not interfere with another more aggressive bl= ock size increase hardfork in the
meantime. I believe I can immediately recommen= d this for adoption; however,
peer and community review are welcome to suggest c= hanges.
Text:=C2=A0https://github.com/luke-jr/bips/blob/bip-blksize/bip= -blksize.mediawiki
Code:=C2=A0https://github.com/bitcoin/bitcoin/com= pare/master...luke-jr:bip-blksize
(consensus code changes only)

2) The second is a *preparatory* change, that should allow triv= ially
transforming certain classes of hardforks into softforks in the future. It=
esse= ntially says that full nodes should relax their rule enforcement, after
sufficie= nt time that would virtually guarantee they have ceased to be
enforcing the full= set of rules anyway. This allows these relaxed rules to be
modified or removed = in a softfork, provided the proposal to do so is accepted
and implemented with= enough advance notice. Attempting to implement this has
proven more complicated= than I originally expected, and it may make more sense
for full nodes to simply= stop functioning (with a user override) after the
cut-off date). In light of th= is, I do not yet recommend its adoption, but am
posting it for review and commen= ts only.
Text:=C2=A0https://github.com/luke-jr/bips/blob/bip-hfprep/bip-<= wbr>hfprep.mediawiki

3) Third is an anti-replay soft= fork which can be used to prevent replay
attacks whether induced by a hardfork-r= elated chain split, or even in ordinary
operation. It does this by using a new o= pcode (OP_CHECKBLOCKATHEIGHT) for the
= Bitcoin scripting system that allows const= ruction of transactions which are
valid only on specific blockchains.
Text:=C2=A0https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.= mediawiki

= Luke
Daniele Pinna, Ph.D
<= /div>
--001a113dd4921b16b5054712645d--