diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2015-10-28 10:06:22 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-28 14:06:24 +0000 |
| commit | d3d015ba19df7d33ac3c0865d3a042fa33d3b489 (patch) | |
| tree | 2414b5d9296292048b0e0521c0811625e959d270 /16 | |
| parent | 808355d0d9e183b068d0e8d27604d15383b3ea32 (diff) | |
| download | pi-bitcoindev-d3d015ba19df7d33ac3c0865d3a042fa33d3b489.tar.gz pi-bitcoindev-d3d015ba19df7d33ac3c0865d3a042fa33d3b489.zip | |
[bitcoin-dev] Compatibility requirements for hard or soft forks
Diffstat (limited to '16')
| -rw-r--r-- | 16/8f1c21904eff1816fc06099de02ae1389fcc21 | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/16/8f1c21904eff1816fc06099de02ae1389fcc21 b/16/8f1c21904eff1816fc06099de02ae1389fcc21 new file mode 100644 index 000000000..a51d74fca --- /dev/null +++ b/16/8f1c21904eff1816fc06099de02ae1389fcc21 @@ -0,0 +1,120 @@ +Return-Path: <gavinandresen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E95928A7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 28 Oct 2015 14:06:24 +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 223F679 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 28 Oct 2015 14:06:24 +0000 (UTC) +Received: by lffz202 with SMTP id z202so4223747lff.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 28 Oct 2015 07:06:22 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:date:message-id:subject:from:to:content-type; + bh=l/I54WJXUsnlVfjwwF4vzI73FFhFIyaAZ1kp0pa7NK0=; + b=d4A0M9esKiAGTX1PM6spBNTdoLS4bIBLqUWbk1q810vCDZ3xubkd1EwvgzzynFzVlZ + xUiAHpiiKJ9JUqo7PEmd6voooPOrLX7/IIUwyiUi5DUViZJw9U7UpPoWZjq9md41GQD7 + OorjddU1aVrx4XtpiAflg1CNBf+s6N47UC+BcC5yLLRaqOFKBF8boT0pXIVJnBuI3dW5 + x0J0lHBFFDS+V/gqYaG6Pyyxt+f/Fiw0tIYEQPoRSURMwgIZG+Y0M7DckG6ZpdYeqtpX + RFXh+QdjgicjfEE+ihNc/xL31whwOtegZH/Exfbcj0qlJneshEkxtPD8XA9F8RAE44Xt + 3oPg== +MIME-Version: 1.0 +X-Received: by 10.25.13.74 with SMTP id 71mr7833560lfn.113.1446041182258; Wed, + 28 Oct 2015 07:06:22 -0700 (PDT) +Received: by 10.25.22.146 with HTTP; Wed, 28 Oct 2015 07:06:22 -0700 (PDT) +Date: Wed, 28 Oct 2015 10:06:22 -0400 +Message-ID: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a113eaaa4ffd24505232ab290 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: [bitcoin-dev] Compatibility requirements for hard or soft forks +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Wed, 28 Oct 2015 14:06:25 -0000 + +--001a113eaaa4ffd24505232ab290 +Content-Type: text/plain; charset=UTF-8 + +I'm hoping this fits under the moderation rule of "short-term changes to +the Bitcoin protcol" (I'm not exactly clear on what is meant by +"short-term"; it would be lovely if the moderators would start a thread on +bitcoin-discuss to clarify that): + + +Should it be a requirement that ANY one-megabyte transaction that is valid +under the existing rules also be valid under new rules? + +Pro: There could be expensive-to-validate transactions created and given a +lockTime in the future stored somewhere safe. Their owners may have no +other way of spending the funds (they might have thrown away the private +keys), and changing validation rules to be more strict so that those +transactions are invalid would be an unacceptable confiscation of funds. + +Con: It is extremely unlikely there are any such large, timelocked +transactions, because the Core code has had a clear policy for years that +100,000-byte transactions are "standard" and are relayed and +mined, and +larger transactions are not. The requirement should be relaxed so that only +valid 100,000-byte transaction under old consensus rules must be valid +under new consensus rules (larger transactions may or may not be valid). + + +I had to wrestle with that question when I implemented BIP101/Bitcoin XT +when deciding on a limit for signature hashing (and decided the right +answer was to support any "non-attack"1MB transaction; see +https://bitcoincore.org/~gavin/ValidationSanity.pdf for more details). + +-- +-- +Gavin Andresen + +--001a113eaaa4ffd24505232ab290 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">I'm hoping this fits under the moderation rule of &quo= +t;short-term changes to the Bitcoin protcol" (I'm not exactly clea= +r on what is meant by "short-term"; it would be lovely if the mod= +erators would start a thread on bitcoin-discuss to clarify that):<div><br><= +br>Should it be a requirement that ANY one-megabyte transaction that is val= +id<br>under the existing rules also be valid under new rules?<br><br>Pro: = +=C2=A0There could be expensive-to-validate transactions created and given a= +<br>lockTime in the future stored somewhere safe. Their owners may have no<= +br>other way of spending the funds (they might have thrown away the private= +<br>keys), and changing validation rules to be more strict so that those<br= +>transactions are invalid would be an unacceptable confiscation of funds.<b= +r><br>Con: It is extremely unlikely there are any such large, timelocked<br= +>transactions, because the Core code has had a clear policy for years that<= +br>100,000-byte transactions are &quot;standard&quot; and are relay= +ed and mined, and<br>larger transactions are not. The requirement should be= + relaxed so that only<br>valid 100,000-byte transaction under old consensus= + rules must be valid<br>under new consensus rules (larger transactions may = +or may not be valid).<br><br><br>I had to wrestle with that question when I= + implemented BIP101/Bitcoin XT<br>when deciding on a limit for signature ha= +shing (and decided the right<br>answer was to support any "non-attack&= +quot;1MB transaction; see<br><a href=3D"https://bitcoincore.org/~gavin/Vali= +dationSanity.pdf">https://bitcoincore.org/~gavin/ValidationSanity.pdf</a> f= +or more details).<br><br>-- <br><div class=3D"gmail_signature">--<br>Gavin = +Andresen<br></div> +</div></div> + +--001a113eaaa4ffd24505232ab290-- + |