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>
	<CAAUaCyixU14z-ym6s62b_BDn2c4TL9jEk-Fa7VwPeNWPm9SPbg@mail.gmail.com>
In-Reply-To: <CAAUaCyixU14z-ym6s62b_BDn2c4TL9jEk-Fa7VwPeNWPm9SPbg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 13 Mar 2019 00:54:23 +0000
Message-ID: <CAAS2fgQPtMG0Fad6=wR-KcQ18bDQzXWDgwHtN9edQ51VZMsmrw@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
 Consensus Cleanup
Precedence: list

On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Also, if future disabling isn't the point of making a tx type like OP_COD=
ESEPARATOR non-standard - what is?  If we're committed to indefinite suppor=
t of these oddball features, what do we gain by making them hard to use/min=
e?

It makes them infeasible to abuse without miner assistance... which
doesn't fix them, but in practice greatly reduces the risk they create
and allows efforts improving the system to be allocated to other more
pressing issues.

> 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, e=
tc.

Don't underestimate the value of taking a principled position that
*strongly* avoids confiscating user funds.  Among many other benefits
being cautious about this avoids creating a situation where people are
demanding human intervention to restore improperly lost funds and the
associated loss of effort that would come from the effort wasted
debating that.

It's true that most other cryptocurrencies proceed without any such
caution or care-- e.g. bcash recently confiscating all funds
accidentally sent to segwit using Bitcoin addresses because of their
reckless address aliasing as a result of promoting the standardness
rule that made those txn non-standard before segwit without
considering the implications--, but they're not the standard we should
hold Bitcoin to...

> 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.

All things in balance: Codeseperator and its related costs are not an
especially severe problem. The arguments on both side of this point
have enough merit to be worth discussing, at least.