Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAMZUoKnK2YhucaJ-1HxH3MXeBtQZebV+h_rcS5Oq=yCMDC5u7A@mail.gmail.com>
Date: Tue, 12 Mar 2019 17:08:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com>
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>
To: Russell O'Connor <roconnor@blockstream.io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
	Consensus Cleanup
Precedence: list

Note that even your carve-outs for OP_NOP is not sufficient here - if you we=
re using nSequence to tag different pre-signed transactions into categories (=
roughly as you suggest people may want to do with extra sighash bits) then t=
heir transactions could very easily have become un-realistically-spendable. T=
he whole point of soft forks is that we invalidate otherwise-unused bits of t=
he 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 inv=
alidated transactions that send secured inputs to secured outputs (excluding=
 uses of OP_NOP1-OP_NOP10).