MIME-Version: 1.0
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
	<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
	<CAMZUoKk3CgatSexAHRuxn3ibCYwgHpTkc0gF0yDi6hLAVcCiNA@mail.gmail.com>
	<db3405ef-7e06-9538-0700-df37abaa602d@mattcorallo.com>
	<CAMZUoKnK2YhucaJ-1HxH3MXeBtQZebV+h_rcS5Oq=yCMDC5u7A@mail.gmail.com>
	<88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com>
In-Reply-To: <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 12 Mar 2019 18:39:28 -0400
Message-ID: <CAAUaCyixU14z-ym6s62b_BDn2c4TL9jEk-Fa7VwPeNWPm9SPbg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006339fe0583ed5d14"
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list

--0000000000006339fe0583ed5d14
Content-Type: text/plain; charset="UTF-8"

Also, if future disabling isn't the point of making a tx type like
OP_CODESEPARATOR non-standard - what is?  If we're committed to indefinite
support of these oddball features, what do we gain by making them hard to
use/mine?

I see questions like "Is it possible someone's existing tx relies on this?"
as overly black-and-white.  We all agree it's possible: the question is how
likely, vs the harms of continued support - including not just security
risks but friction on other useful changes, safety/correctness analyses,
etc.

It is so easy to say stuff like this when one's own money isn't what is at
risk.


Stepping back for a second here:  I dispute this framing.  My money *is* at
risk, because the value of my bitcoins depends on adoption and feature
growth.  And I've long viewed an absolutist, actual-known-user-indifferent
approach to backwards compatibility as the #1 impediment to Bitcoin's
adoption and growth.

Again, the point being not to throw caution to the wind, but that a case
like this where extensive research unearthed zero users, is taking caution
too far.


On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"auto">Also, if future disabling isn&#39;t the point of making a=
 tx type like OP_CODESEPARATOR non-standard - what is?=C2=A0 If we&#39;re c=
ommitted to indefinite support of these oddball features, what do we gain b=
y making them hard to use/mine?<div dir=3D"auto"><br></div><div dir=3D"auto=
">I see questions like &quot;Is it possible someone&#39;s existing tx relie=
s on this?&quot; as overly black-and-white.=C2=A0 We all agree it&#39;s pos=
sible: the question is how likely, vs the harms of continued support - incl=
uding not just security risks but friction on other useful changes, safety/=
correctness analyses, etc.</div><div dir=3D"auto"><div style=3D"font-family=
:sans-serif" class=3D"elided-text" dir=3D"auto"><div dir=3D"ltr"><br><div c=
lass=3D"elided-text" dir=3D"auto"><blockquote style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"elided=
-text"><div>It is so easy to say stuff like this when one&#39;s own money i=
sn&#39;t what is at risk.</div></div></div></div></div></div></blockquote><=
/div></div></div></div><div dir=3D"auto"><br></div>Stepping back for a seco=
nd here:=C2=A0 I dispute this framing.=C2=A0 My money <i>is</i> at risk, be=
cause the value of my bitcoins depends on adoption and feature growth.=C2=
=A0 And I&#39;ve long viewed an absolutist, actual-known-user-indifferent a=
pproach to backwards compatibility as the #1 impediment to Bitcoin&#39;s ad=
option and growth.<div dir=3D"auto"><br></div><div dir=3D"auto">Again, the =
point being not to throw caution to the wind, but that a case like this whe=
re extensive research unearthed zero users, is taking caution too far.<br><=
div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Mar 12, 2019, 5:48 PM Matt Corallo vi=
a bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Note that even your carve-outs for OP_NOP is not sufficie=
nt here - if you were using nSequence to tag different pre-signed transacti=
ons into categories (roughly as you suggest people may want to do with extr=
a sighash bits) then their transactions could very easily have become un-re=
alistically-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.<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" rel=3D"noreferrer">roconnor@block=
stream.io</a>&gt; wrote:<br>
&gt; Bitcoin has *never* made a soft-fork, since the time of Satoishi, that=
 invalidated transactions that send secured inputs to secured outputs (excl=
uding uses of OP_NOP1-OP_NOP10).<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev<br></a><br>
</blockquote></div></div></div></div>

--0000000000006339fe0583ed5d14--