path: root/cd/1f2b26c607dc6a00bde04f42eda88b53a3e174

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 739CE90
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  1 Nov 2015 23:46:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com
	[209.85.192.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 965E2FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  1 Nov 2015 23:46:40 +0000 (UTC)
Received: by qgad10 with SMTP id d10so104354794qga.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 01 Nov 2015 15:46:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=pPO9Cg5Ys7LFgqXzfSjzf8zbW+/Ws8t5V5/YmLc4TgY=;
	b=jRO9zjwtpdj8lJ/2uMvWmLXGqswA8xaQ++kXhWZMZ1nR3JwinFM1MjK4htJaK/L2Zn
	5kMgxt4fmb0BMB6ZabSDKxvWMjpURUnPCqtyF7fN9a4v1/xxURCKqaDmVZ1orLB+5rTC
	Nme10p5+l+bvwek38Pufi2E4uUtwsfr5BoPTj87r7nYdfvo0zv++Cx8NZK6UAe1P05om
	73JbnmvbOklx050VgpBonfPxkta/7mD2oq16jo2UYoWurSZdTIeZZqlEgKCKigIIFX5t
	G15W66pfLHOUGcFudsJN1z+h4kY3GxEGQLamuKmwkZchYuQCSk0SgH8SB2Sj/ZL0Z1ay
	o3nw==
MIME-Version: 1.0
X-Received: by 10.140.106.99 with SMTP id d90mr25870639qgf.6.1446421599748;
	Sun, 01 Nov 2015 15:46:39 -0800 (PST)
Received: by 10.140.30.201 with HTTP; Sun, 1 Nov 2015 15:46:39 -0800 (PST)
In-Reply-To: <df48a2c44441f39c71579aa5e474ec38@xbt.hk>
References: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
	<df48a2c44441f39c71579aa5e474ec38@xbt.hk>
Date: Sun, 1 Nov 2015 23:46:39 +0000
Message-ID: <CAE-z3OWJ8YvXU5aGqgs9VJnW99va=0=FoObmpHS3irg4Kh6wrQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113b54d0a609c205238345f9
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MALFORMED_FREEMAIL, 
	MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 02 Nov 2015 00:10:16 +0000
Subject: Re: [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: Sun, 01 Nov 2015 23:46:41 -0000

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

On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think it is very important to make it clear that non-standard txs and
> non-standard scripts may become invalid in the future
>

There can be unavoidable situations which cause locked coins become
unspendable.

In an ideal world, soft forks that make UTXOs unspendable should increase
the tx version number.  BIP-13 should have done that.  That would make the
change opt-in.

The disabled opcodes like OP_CAT were a DOS/network security change.

Invalidating locked coins is another reason that they shouldn't have been
disabled permanently.

It would have been better to disable them for six months, so at least
people can get their coins back after that.  Inherently, protecting the
network required some limitations being added so that nodes couldn't be
crashed.

For guidelines

* Transaction version numbers will be increased, if possible
* Transactions with unknown/large version numbers are unsafe to use with
locktime
* Reasonable notice is given that the change is being contemplated
* Non-opt-in changes will only be to protect the integrity of the network

Locked transaction that can be validated without excessive load on the
network should be safe to use, even if non-standard.

An OP_CAT script that requires TBs of RAM to validate crosses the threshold
of reasonableness.



>
> Gavin Andresen via bitcoin-dev =E6=96=BC 2015-10-28 10:06 =E5=AF=AB=E5=88=
=B0:
>
>> 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 &quot;standard&quot; 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 [1] for more
>> details).
>>
>> --
>>
>> --
>> Gavin Andresen
>>
>>
>> Links:
>> ------
>> [1] https://bitcoincore.org/~gavin/ValidationSanity.pdf
>>
>> _______________________________________________
>> 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
>

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

<div dir=3D"ltr"><div></div><div><div><div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoi=
n-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
I think it is very important to make it clear that non-standard txs and non=
-standard scripts may become invalid in the future<br></blockquote><div><br=
></div><div>There can be unavoidable situations which cause locked coins be=
come unspendable.=C2=A0 <br><br></div><div>In an ideal world, soft forks th=
at make UTXOs unspendable should increase the tx version number.=C2=A0 BIP-=
13 should have done that.=C2=A0 That would make the change opt-in.<br><br><=
/div><div>The disabled opcodes like OP_CAT were a DOS/network security chan=
ge.=C2=A0 <br><br>Invalidating locked coins is another reason that they sho=
uldn&#39;t have been disabled permanently.=C2=A0 <br><br>It would have been=
 better to disable them for six months, so at least people can get their co=
ins back after that.=C2=A0 Inherently, protecting the network required some=
 limitations being added so that nodes couldn&#39;t be crashed.<br><br></di=
v><div>For guidelines<br><br></div><div>* Transaction version numbers will =
be increased, if possible<br></div><div>* Transactions with unknown/large v=
ersion numbers are unsafe to use with locktime<br></div><div>* Reasonable n=
otice is given that the change is being contemplated<br></div><div>* Non-op=
t-in changes will only be to protect the integrity of the network<br><br>Lo=
cked transaction that can be validated without excessive load on the networ=
k should be safe to use, even if non-standard.<br></div><div><br></div><div=
>An OP_CAT script that requires TBs of RAM to validate crosses the threshol=
d of reasonableness.=C2=A0 <br></div><div><br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
Gavin Andresen via bitcoin-dev =E6=96=BC 2015-10-28 10:06 =E5=AF=AB=E5=88=
=B0:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div class=3D"h5">
I&#39;m hoping this fits under the moderation rule of &quot;short-term chan=
ges<br>
to the Bitcoin protcol&quot; (I&#39;m not exactly clear on what is meant by=
<br>
&quot;short-term&quot;; it would be lovely if the moderators would start a<=
br>
thread on bitcoin-discuss to clarify that):<br>
<br>
Should it be a requirement that ANY one-megabyte transaction that is<br>
valid<br>
under the existing rules also be valid under new rules?<br>
<br>
Pro:=C2=A0 There could be expensive-to-validate transactions created and<br=
>
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<br>
private<br>
keys), and changing validation rules to be more strict so that those<br>
transactions are invalid would be an unacceptable confiscation of<br>
funds.<br>
<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<br>
that<br>
100,000-byte transactions are &amp;quot;standard&amp;quot; and are relayed =
and<br>
mined, and<br>
larger transactions are not. The requirement should be relaxed so that<br>
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<br>
valid).<br>
<br>
I had to wrestle with that question when I implemented BIP101/Bitcoin<br>
XT<br>
when deciding on a limit for signature hashing (and decided the right<br>
answer was to support any &quot;non-attack&quot;1MB transaction; see<br>
</div></div><a href=3D"https://bitcoincore.org/~gavin/ValidationSanity.pdf"=
 rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/~gavin/Valida=
tionSanity.pdf</a> [1] for more<span class=3D""><br>
details).<br>
<br>
--<br>
<br>
--<br>
Gavin Andresen<br>
<br>
<br></span>
Links:<br>
------<br>
[1] <a href=3D"https://bitcoincore.org/~gavin/ValidationSanity.pdf" rel=3D"=
noreferrer" target=3D"_blank">https://bitcoincore.org/~gavin/ValidationSani=
ty.pdf</a><span class=3D""><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</span></blockquote><div class=3D"HOEnZb"><div class=3D"h5">
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>

--001a113b54d0a609c205238345f9--