path: root/15/0f76e90f6bfa4cf6beaa2b4bb6b0467e1be92c

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 065474A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Mar 2019 01:34:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f193.google.com (mail-it1-f193.google.com
	[209.85.166.193])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE367826
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 13 Mar 2019 01:34:33 +0000 (UTC)
Received: by mail-it1-f193.google.com with SMTP id z124so372555itc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 18:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=2Ro2Ys/60DeTeXYDEo3B41MNtHuc+1P7wa0aWppl3ow=;
	b=T0exIrZUr0fiD/Z5gMxU8TA4sEpuaZ/9FLJ01y4cQg0W+ZXU5NM2qKQ1yBw3su0mUw
	QTJpe9BNluxUHlGHUBC63kEL2I57XaS1neV4efQYuIKwxl1Lr9JFMayGvqDYtXe1Ci0s
	TJediGOOdiKRWEu9cAtWL26kTMSu6Un0N/tyE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=2Ro2Ys/60DeTeXYDEo3B41MNtHuc+1P7wa0aWppl3ow=;
	b=cwTYA+R6ytTI5/1QGBjg6llzbNASsKrIlNqBlK9NN7C6yHpZFyX80bpRXzuH2J6VQ0
	n1CnmWkI7NmkgjmjKixfWAcCxNZOZv5T7uCQlfHX6l1exZ5nDat7Gox7OUtAzH050UG0
	YIXVbot62Cn9cy92Y9aaSqQDTwwCN02peGICa6Jd6y7rpbfYhAEq2V6zaL+cDtSmPjtl
	20cKfne6dowpl7J711tYbxzqZ6crq+fW/rZKVVIlGJ+54yDmmwrOlYjKlZOsD50OF3xl
	gnWItD5CgLUZFvUFBAz5tQ+Q5ezLQMpjxOt+Q/3119U4d+/bOLTpF0QQWiEwDHwDSb+h
	qx0A==
X-Gm-Message-State: APjAAAVNpXKOlyBFa56CKUFC3kt0vj5hjFviGFxRa31oRsmaj6hmocl1
	VDINuUheQARYv7v8r/PjJuucd3MfQT4DpKGRpcYe+Jzz
X-Google-Smtp-Source: APXvYqyE3fE36bXpJn5Eik/qOrUzbxCEWYo/HIAvAWMCujQ2r3Zsrr3cj3WAi/eRrzzlDf+okcsABc4E5r/qEmn68YQ=
X-Received: by 2002:a24:3a8b:: with SMTP id m133mr397062itm.26.1552440873087; 
	Tue, 12 Mar 2019 18:34:33 -0700 (PDT)
MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
	<eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
	<CAMZUoKnrUENVwSLJd6HEprqrjmU_Em5LFL4o+UW1-nOBKADVUw@mail.gmail.com>
In-Reply-To: <CAMZUoKnrUENVwSLJd6HEprqrjmU_Em5LFL4o+UW1-nOBKADVUw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 12 Mar 2019 21:34:21 -0400
Message-ID: <CAMZUoKkd_mApqcYqaQA3ChR2UCbVieH=4D=LvfbZ+tLAZ63B3A@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="000000000000c690370583efce6f"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 13 Mar 2019 06:46:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sighash Type Byte;
	Re: BIP Proposal: The Great Consensus Cleanup
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: Wed, 13 Mar 2019 01:34:35 -0000

--000000000000c690370583efce6f
Content-Type: text/plain; charset="UTF-8"

Hi Matt,

(I moved your comment to this thread, where I think it is more relevant).

This is a fair point.  I concede that as far as Sighash Type Byte is
concerned, the type of change is fairly similar to BIP 68 (though I don't
think the argument applies to OP_CODESEPARATOR).
I might rephrase what you say as "invalidating otherwise-unusable bits of
the protocol".  I don't quite know the right phrasing that captures both
the insecure and redundant aspects of the protocol.  I'm willing to accept
that nSequence numbers (as they originally were), NOP1-NOP10 and these
extra sighash types can all be classified as redundant aspects of the
Bitcoin protocol.

I still think the alternative proposal of caching the sha256 midstate is
the better choice.  We should strive to avoid changing the consensus rules
when we have reasonable alternatives to achieve our goals. However, I now
see that this proposal isn't entirely unprecedented.

On Tue, Mar 12, 2019 at 5:08 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io>
> wrote:
> > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>

On Fri, Mar 8, 2019 at 10:57 AM Russell O'Connor <roconnor@blockstream.io>
wrote:

> On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>> I can't say I'm particularly married to this idea (hence the alternate
>> proposal in the original email), but at the same time the lack of
>> existing transactions using these bits (and the redundancy thereof -
>> they don't *do* anything special) seems to be pretty strong indication
>> that they are not in use. One could argue a similarity between these
>> bits and OP_NOPs - no one is going to create transactions that require
>> OP_NOP execution to be valid as they are precisely the kind of thing
>> that may get soft-forked to have a new meaning. While the sighash bits
>> are somewhat less candidates for soft-forking,
>
>
> I don't think "somewhat less candidates for soft-forking" is a fair
> description.  These bits essentially unsuitable for soft-forking within
> legacy Script.
>
> I don't think "someone
>> may have shoved random bits into parts of their
>> locked-for-more-than-a-year transactions" is sufficient reason to not
>> soft-fork something out.
>
>
> I disagree. It is sufficient.
>
> When was the last time Bitcoin soft-forked out working transactions that
> sent funds from securely held UTXOs to securely held UTXOs (aside from
> those secured by Scripts using the reserved OP_NOP1-OP_NOP10)?  AFAIK it
> has never occurred since the time of Satoshi, even for the most
> hypothetical of transactions.  It is my understanding is that Bitcoin Core
> would never do such a thing unless the security of Bitcoin protocol itself
> was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
> Core would only soft-fork out the minimal amount necessary to safely
> diffuse such a threat.
>
> Since the above soft-fork isn't addressing addressing any such threat
> (that I'm aware of), and could hypothetically destroy other people money,
> it crosses a line I thought we were never supposed to cross.
>
>>
>> Obviously, actually *seeing* it used in
>> practice or trying to fork them out in a fast manner would be
>> unacceptable, but neither is being proposed here.
>>
>
> Perhaps you don't see them in used in the blockchain because the users
> trying to use them are caught up by the fact they they are not being
> relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
> difficulty redeeming them.
> You cannot first make transactions non-standard and then use the fact that
> you don't see them being used to justify a soft-fork.
>
> I know of users who have their funds tied up due to other changes in
> Bitcoin Core's default relay policy.  I believe they waiting for their
> funds to become valuable enough to go through the trouble of having them
> directly mined.  Shall we now permanently destroy their funds too, before
> they have a chance to get their transactions mined?
>
>

--000000000000c690370583efce6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Matt,</div><div><br></div><div>(I moved your comme=
nt to this thread, where I think it is more relevant).</div><div dir=3D"ltr=
"><div><br></div><div>This is a fair point.=C2=A0 I concede that as far as =
Sighash Type Byte is concerned, the type of change is fairly similar to BIP=
 68 (though I don&#39;t think the argument applies to OP_CODESEPARATOR).</d=
iv><div>I might rephrase what you say as &quot;invalidating otherwise-unusa=
ble bits of the protocol&quot;.=C2=A0 I don&#39;t quite know the right phra=
sing that captures both the insecure and redundant aspects of the protocol.=
=C2=A0 I&#39;m willing to accept that nSequence numbers (as they originally=
 were), NOP1-NOP10 and these extra sighash types can all be classified as r=
edundant aspects of the Bitcoin protocol.<br></div><div><br></div><div>I st=
ill think the alternative proposal of caching the sha256 midstate is the be=
tter choice.=C2=A0 We should strive to avoid changing the consensus rules w=
hen we have reasonable alternatives to achieve our goals. However, I now se=
e that this proposal isn&#39;t entirely unprecedented.<br></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 12, 2=
019 at 5:08 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com"=
 target=3D"_blank">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Note
 that even your carve-outs for OP_NOP is not sufficient here - if you=20
were using nSequence to tag different pre-signed transactions into=20
categories (roughly as you suggest people may want to do with extra=20
sighash bits) then their transactions could very easily have become=20
un-realistically-spendable. The whole point of soft forks is that we=20
invalidate otherwise-unused bits of the protocol. This does not seem=20
inconsistent with the proposal here.<br>
<br>
&gt; On Mar 9, 2019, at 13:29, Russell O&#39;Connor &lt;<a href=3D"mailto:r=
oconnor@blockstream.io" target=3D"_blank">roconnor@blockstream.io</a>&gt; w=
rote:<br>
&gt; Bitcoin has *never* made a soft-fork, since the time of Satoishi,=20
that invalidated transactions that send secured inputs to secured=20
outputs (excluding uses of OP_NOP1-OP_NOP10).<br>
</blockquote></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, Mar 8, 2019 at 10:57 AM Russell O&#39;Conn=
or &lt;<a href=3D"mailto:roconnor@blockstream.io" target=3D"_blank">roconno=
r@blockstream.io</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 7, 201=
9 at 2:57 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com" t=
arget=3D"_blank">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">I can&#39;t say I&#39;m particular=
ly married to this idea (hence the alternate <br>
proposal in the original email), but at the same time the lack of <br>
existing transactions using these bits (and the redundancy thereof - <br>
they don&#39;t *do* anything special) seems to be pretty strong indication =
<br>
that they are not in use. One could argue a similarity between these <br>
bits and OP_NOPs - no one is going to create transactions that require <br>
OP_NOP execution to be valid as they are precisely the kind of thing <br>
that may get soft-forked to have a new meaning. While the sighash bits <br>
are somewhat less candidates for soft-forking, </blockquote><div><br></div>=
<div>I don&#39;t think &quot;somewhat less candidates for soft-forking&quot=
; is a fair=20
description.=C2=A0 These bits essentially unsuitable for soft-forking withi=
n legacy Script.<br></div><div> <br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">I don&#39;t think &quot;someone <br>
may have shoved random bits into parts of their <br>
locked-for-more-than-a-year transactions&quot; is sufficient reason to not =
<br>
soft-fork something out.</blockquote><div><br></div><div>I disagree. It is =
sufficient.</div><div><br></div><div>When was the last time Bitcoin soft-fo=
rked out working transactions that sent funds from securely held UTXOs to s=
ecurely held UTXOs (aside from those secured by Scripts using the reserved =
OP_NOP1-OP_NOP10)?=C2=A0 AFAIK it has never occurred since the time of Sato=
shi, even for the most hypothetical of transactions.=C2=A0 It is my underst=
anding is that Bitcoin Core would never do such a thing unless the security=
 of Bitcoin protocol itself was under existential threat (see OP_CODESEPARA=
TOR) and even then Bitcoin Core would only soft-fork out the minimal amount=
 necessary to safely diffuse such a threat.</div><div><br></div><div>Since =
the above soft-fork isn&#39;t addressing addressing any such threat (that I=
&#39;m aware of), and could hypothetically destroy other people money, it c=
rosses a line I thought we were never supposed to cross.</div>=C2=A0<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"> Obviously, actually *seeing* it=
 used in <br>
practice or trying to fork them out in a fast manner would be <br>
unacceptable, but neither is being proposed here.<br>
</blockquote><div><br></div><div>Perhaps you don&#39;t see them in used in =
the blockchain=20
because the users trying to use them are caught up by the fact they they
 are not being relayed by default (violating SCRIPT_VERIFY_STRICTENC) and a=
re having difficulty redeeming them.</div><div>You cannot first make transa=
ctions non-standard and then use the fact that you don&#39;t see them being=
 used to justify a soft-fork.</div><div><br></div><div>I know of users who =
have their funds tied up due to other changes in Bitcoin Core&#39;s default=
 relay policy.=C2=A0 I believe they waiting for their funds to become valua=
ble enough to go through the trouble of having them directly mined.=C2=A0 S=
hall we now permanently destroy their funds too, before they have a chance =
to get their transactions mined?<br></div><div><br></div></div></div></div>=
</div>
</blockquote></div>

--000000000000c690370583efce6f--