diff options
| author | Andrew Johnson <andrew.johnson83@gmail.com> | 2017-01-26 21:04:50 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-01-27 03:04:52 +0000 |
| commit | d1cf64cd8d5ba546c69cd4c45443a740c1a198c0 (patch) | |
| tree | 191fd0cfcae6f1b6d90ce6c87ce5edf529cd5405 | |
| parent | bcce093e7400ad3fbf25df18c53c8aefdf3f582f (diff) | |
| download | pi-bitcoindev-d1cf64cd8d5ba546c69cd4c45443a740c1a198c0.tar.gz pi-bitcoindev-d1cf64cd8d5ba546c69cd4c45443a740c1a198c0.zip | |
Re: [bitcoin-dev] Three hardfork-related BIPs
| -rw-r--r-- | 6e/32b00e4ce306685495d47774a94fcb4c29b46c | 257 |
1 files changed, 257 insertions, 0 deletions
diff --git a/6e/32b00e4ce306685495d47774a94fcb4c29b46c b/6e/32b00e4ce306685495d47774a94fcb4c29b46c new file mode 100644 index 000000000..41e33c3a2 --- /dev/null +++ b/6e/32b00e4ce306685495d47774a94fcb4c29b46c @@ -0,0 +1,257 @@ +Return-Path: <andrew.johnson83@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 2E6B992B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 27 Jan 2017 03:04:52 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com + [209.85.217.180]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BFDB1D7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 27 Jan 2017 03:04:51 +0000 (UTC) +Received: by mail-ua0-f180.google.com with SMTP id i68so196085772uad.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 26 Jan 2017 19:04:51 -0800 (PST) +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; + bh=7heD2OcMnjvhcMAVr6LQQ7FXpA/YH73uhjWps3PxVKA=; + b=la3Bpg5T8HOwnqL2Xtlo6PoWPYcA5jlWousALkrWv5048RLZf5nwz+LRrpKaUZcWby + W8gs1p20+z5ZbOORxq/HZFWxAtC1YZ43MQQPbkYhGYQIDqkuPGyJrbW2JJLvrhHFPLyw + O+8EyvQhJwHhjeKB2g53PqebBKrc5zii5O5SpyoGP+XEWCDezYoZn/Ory5kkyNq5CgzF + gUpFZQMT9EmAJY0ZdaGQzYvdsUhAJN9LeOFKpLSx1blUoAFql6RKuQ/mqj1vxyBFFznA + lQNRHkzjkgczilHPzUiejZFPrAqGRgaeBIv5uCRWpE38nHjGnU95EG3V0epgTd2ly8Es + pthg== +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; + bh=7heD2OcMnjvhcMAVr6LQQ7FXpA/YH73uhjWps3PxVKA=; + b=RNBT909oGSYmc6mSFqlU7ZQ9EbKEMBGTk6VqFUE9oN8VoSUYSi7xL2lK8FIUrqfCUx + cwfwDsKBuawcJSCHcG8FdHR2M1kwJO4oDT4IQ/2pF7v/swhHtUxB2FvvHaaPIz2aMzOA + Yq+PZhTQx18YLGJj2/UfQlu9NetlWdVpn5lnsz65H4VezMYoFOJWTIAWO4VhDJzg7LX7 + GhIGy4yFKCN9y7WR+upXOa7hRPCw4ajEIUfg/3N9y43fLC8KrLoug3Zl5sgzTm9KTbTJ + U+MqUqTAlNuPiXCvhTt9pzBk9eWKlIcktCBbPBwuAzgLorcneEKv8PaGxds3ERZI+FPO + irdA== +X-Gm-Message-State: AIkVDXKpuj/j1Mg5/uHlDp0pf87ztTOh3ogSAS2yqiLyu46i1kUGHGOEwdvpM2Rza3LhPpftKg5TM0MebXpNoQ== +X-Received: by 10.159.37.71 with SMTP id 65mr2757797uaz.134.1485486290579; + Thu, 26 Jan 2017 19:04:50 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 19:04:50 -0800 (PST) +Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 19:04:50 -0800 (PST) +In-Reply-To: <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com> +References: <201701270107.01092.luke@dashjr.org> + <CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com> + <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com> +From: Andrew Johnson <andrew.johnson83@gmail.com> +Date: Thu, 26 Jan 2017 21:04:50 -0600 +Message-ID: <CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com> +To: Luke Dashjr <luke@dashjr.org>, + Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=94eb2c12308aab373205470abaae +X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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 04:35:41 +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 03:04:52 -0000 + +--94eb2c12308aab373205470abaae +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +Comment on #1. You're dropping the blocksize limit to 300KB and only +reaching the limit that we have in place today 7 years later? We're +already at capacity today, surely you're not serious with this proposal? +When you promised code for a hard forking block size increase in the HK +agreement I don't believe that a decrease first was made apparent. While +not technically in violation of the letter of the agreement, I think this +is a pretty obviously not in the spirit of it. + +On Jan 26, 2017 7:07 PM, "Luke Dashjr via bitcoin-dev" < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +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 long-term. + +1) The first is a block size limit protocol change. It also addresses three +criticisms of segwit: 1) segwit increases the block size limit which is +already considered by many to be too large; 2) segwit treats pre-segwit +transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only= + to segwit +transactions; and 3) that spam blocks can be larger than blocks mining +legitimate 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 als= +o +extend the witness discount to non-segwit transactions. Should the initial +block size limit reduction prove to be too controversial, miners can simply +wait to activate it until closer to the point where it becomes acceptable +and/or increases the limit. However, since the BIP includes a hardfork, the +eventual block size increase needs community consensus before it can be +deployed. Proponents of block size increases should note that this BIP does +not interfere with another more aggressive block size increase hardfork in +the +meantime. 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.mediawik= +i +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 trivially +transforming certain classes of hardforks into softforks in the future. It +essentially says that full nodes should relax their rule enforcement, after +sufficient 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 ha= +s +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 this, I do not yet recommend its adoption, but a= +m +posting 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 replay +attacks whether induced by a hardfork-related chain split, or even in +ordinary +operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for +the +Bitcoin scripting system that allows construction of transactions which are +valid only on specific blockchains. +Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip- +noreplay.mediawiki + +Luke +_______________________________________________ +bitcoin-dev mailing list +bitcoin-dev@lists.linuxfoundation.org +https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + +--94eb2c12308aab373205470abaae +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto"><div>Comment on #1.=C2=A0 You're dropping the blocksi= +ze limit to 300KB and only reaching the limit that we have in place today 7= + years later?=C2=A0 We're already at capacity today, surely you're = +not serious with this proposal?=C2=A0 When you promised code for a hard for= +king block size increase in the HK agreement I don't believe that a dec= +rease first was made apparent.=C2=A0 While not technically in violation of = +the letter of the agreement, I think this is a pretty obviously not in the = +spirit of it.</div><div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto= +"><br><div class=3D"gmail_quote">On Jan 26, 2017 7:07 PM, "Luke Dashjr= + via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat= +ion.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"at= +tribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-le= +ft:1px #ccc solid;padding-left:1ex">I've put together three hardfork-re= +lated BIPs. This is parallel to the ongoing<br> +research into the MMHF/SHF WIP BIP, which might still be best long-term.<br= +> +<br> +1) The first is a block size limit protocol change. It also addresses three= +<br> +criticisms of segwit: 1) segwit increases the block size limit which is<br> +already considered by many to be too large; 2) segwit treats pre-segwit<br> +transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only= + to segwit<br> +transactions; and 3) that spam blocks can be larger than blocks mining<br> +legitimate transactions. This proposal may (depending on activation date)<b= +r> +initially reduce the block size limit to a more sustainable size in the sho= +rt-<br> +term, and gradually increase it up over the long-term to 31 MB; it will als= +o<br> +extend the witness discount to non-segwit transactions. Should the initial<= +br> +block size limit reduction prove to be too controversial, miners can simply= +<br> +wait to activate it until closer to the point where it becomes acceptable<b= +r> +and/or increases the limit. However, since the BIP includes a hardfork, the= +<br> +eventual block size increase needs community consensus before it can be<br> +deployed. Proponents of block size increases should note that this BIP does= +<br> +not interfere with another more aggressive block size increase hardfork in = +the<br> +meantime. I believe I can immediately recommend this for adoption; however,= +<br> +peer and community review are welcome to suggest changes.<br> +Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksi= +ze.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-= +jr/<wbr>bips/blob/bip-blksize/bip-<wbr>blksize.mediawiki</a><br> +Code: <a href=3D"https://github.com/bitcoin/bitcoin/compare/master...luke-j= +r:bip-blksize" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc= +oin/<wbr>bitcoin/compare/master...luke-<wbr>jr:bip-blksize</a><br> +(consensus code changes only)<br> +<br> +2) The second is a *preparatory* change, that should allow trivially<br> +transforming certain classes of hardforks into softforks in the future. It<= +br> +essentially says that full nodes should relax their rule enforcement, after= +<br> +sufficient time that would virtually guarantee they have ceased to be<br> +enforcing the full set of rules anyway. This allows these relaxed rules to = +be<br> +modified or removed in a softfork, provided the proposal to do so is accept= +ed<br> +and implemented with enough advance notice. Attempting to implement this ha= +s<br> +proven more complicated than I originally expected, and it may make more se= +nse<br> +for full nodes to simply stop functioning (with a user override) after the<= +br> +cut-off date). In light of this, I do not yet recommend its adoption, but a= +m<br> +posting it for review and comments only.<br> +Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep= +.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-jr= +/<wbr>bips/blob/bip-hfprep/bip-<wbr>hfprep.mediawiki</a><br> +<br> +3) Third is an anti-replay softfork which can be used to prevent replay<br> +attacks whether induced by a hardfork-related chain split, or even in ordin= +ary<br> +operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for t= +he<br> +Bitcoin scripting system that allows construction of transactions which are= +<br> +valid only on specific blockchains.<br> +Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-noreplay/bip-nore= +play.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luk= +e-jr/<wbr>bips/blob/bip-noreplay/bip-<wbr>noreplay.mediawiki</a><br> +<br> +Luke<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> + +--94eb2c12308aab373205470abaae-- + |