path: root/47/8226a46e673ba7cbd8e77b61a3f3b4783ed87d

Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E81609F0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 03:25:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com
	[209.85.166.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2927D81A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 10 Mar 2019 03:25:50 +0000 (UTC)
Received: by mail-it1-f171.google.com with SMTP id l15so2241764iti.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 09 Mar 2019 19:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=8EYky97t+uvp4FyDpmijTbZ+Sham35rerU8mcHQoTu4=;
	b=AvUny0AOE3OWIh3vlJdi1OcpLTWuEZJ5lHGON5FHtiU/8mhCxJTTtIXJeQ7tT7cJDi
	UokM/Lk4q26jDSqfhlIWmRzKkMuyWeOII0arT0y7hYgun53tcvmmzbCQjufRxY3DhK7u
	2BLIRohiO8AHDQ7ofFYA3+c7mWEhFRjlqyvGR9tuz0cBlkv0nW8SPb2i5bciUQv0o5R4
	qCbfYbwnSbn3ytkCABCDtcrP+p1y60yPbNYNcwmChIGDX8Vg6XFVKDouED4MD4tujtvF
	4+VISZxT75+NeN/SwQ/ibZSLMRgkvUU7vyABYLO/zjILLnUv3jCwt1MF08cx8jTiX4mf
	PF0Q==
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=8EYky97t+uvp4FyDpmijTbZ+Sham35rerU8mcHQoTu4=;
	b=dWJftEPd9aPiOqLam9wLIc7Bv1ucqnIeys0VlYABjeDWzCrOCH4QKcByv7aiWFWUZf
	BcxLSDREka2PMWlRBFbDk5t/au7Yz6WUWMCrGq4lIQZcawxVWoYMmdS58L1uwiqhgvN9
	zslctzVqNB3U+F8Bk5mVHYj+rVeK1Kb1hdsBVAmDglDgFLAnBovhy5nS1xJhi9KPkaP8
	gTjQszzj01uFQtgiVohmwHAIBT5rzNndYTuM+DOzpBt8LNMZ5xUnOSyNGLkPsNs7UNFe
	pzuCC5EBnLcYChfAC2zM9xhKA1wWRya0CNVQg93/6DqIMlGSUBH7Wr6KwGKkgRp8eO+A
	40FA==
X-Gm-Message-State: APjAAAUTvww48djLzQNno4iZanFTzgZWn9OLnBjIZBAGB2YXKvv+7Qsh
	cs8r4udN+HDAFeq67m2nO+QdyMShInIRRZ78IASv+nx/khI=
X-Google-Smtp-Source: APXvYqzBpCjgrIJK5Gw/9WBktORUMxQ7a6L+4sQ72qXvHiXP5pd29xveN9vO/Om6uIMPb6RtOFEWRP2P1YB3a5W276c=
X-Received: by 2002:a24:2e90:: with SMTP id
	i138mr13689778ita.158.1552188349127; 
	Sat, 09 Mar 2019 19:25:49 -0800 (PST)
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>
In-Reply-To: <CAMZUoKnK2YhucaJ-1HxH3MXeBtQZebV+h_rcS5Oq=yCMDC5u7A@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Sat, 9 Mar 2019 22:25:36 -0500
Message-ID: <CAAUaCyh09NkgVi2fCNGaNikmaNJ1Yi7AYtBnK9f+Qg8sFoA+_Q@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002ca37b0583b50327"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Sun, 10 Mar 2019 13:23:16 +0000
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR 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: Sun, 10 Mar 2019 03:25:52 -0000

--0000000000002ca37b0583b50327
Content-Type: text/plain; charset="UTF-8"

>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> 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).
>

This principle was only ever a rule of thumb to protect users, not a
commandment from God.  It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.

Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years.  Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do.  Perhaps others don't want to risk
> blowing their pseudonymity.  Perhaps they think that attempting to undo
> some of these non-standardness changes is futile.  I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>

Like Matt, I understand non-standardness to be specifically for making a
transaction type more difficult to set the stage for a future disabling.

If anyone is actually harmed by this change, let them at least speak up
pseudonymously as others have before.  Backwards compatibility shouldn't
mean letting imaginary implausible cases veto net-beneficial changes.


On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>
>> Replies inline.
>>
>> On 3/8/19 3:57 PM, Russell O'Connor wrote:
>> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo.com
>> > <mailto:lf-lists@mattcorallo.com>> wrote:
>> > It's very easy to construct a practical script using OP_CODESEPARATOR.
>> >
>> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
>> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
>> >
>> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
>> > she has the option of either signing it unilaterally herself, or
>> > creating a partial signature such that the transaction additionally
>> > needs Bob, the CEOs signature as well, and Alice's choice is committed
>> > to the blockchain for auditing purposes later.
>> >
>> > Now, there are many things you might object about this scheme, but my
>> > point is that (A) regardless of what you think about this scheme, it,
>> or
>> > similar schemes, may have been devised by users, and (B) users may have
>> > already committed funds to such schemes, and due to P2SH you cannot
>> know
>> > that this is not the case.
>>
>> The common way to set that up is to have a separate key, but, ok, fair
>> enough. That said, the argument that "it may be hidden by P2SH!" isn't
>> sufficient here. It has to *both* be hidden by P2SH and have never been
>> spent from (either on mainnet or testnet) or be lock-timed a year in the
>> future. I'm seriously skeptical that someone is using a highly esoteric
>> scheme and has just been pouring money into it without ever having
>> tested it or having withdrawn any money from it whatsoever. This is just
>> a weird argument.
>>
>
> No one is required to test their Scripts on a public testnet; they can use
> regtest. Because these transactions are non-standard on mainnet, it could
> take years to arrange for these funds to be recovered by having their
> transactions mined directly, or take years to become valuable enough to be
> worth bothering having them directly mined.  As I have noted elsewhere, you
> cannot first make transactions non-standard and then use the fact that you
> don't see them being used on mainnet to justify a soft-fork.
>
> My argument isn't weird; it is principled.  You are skeptical that any
> uses of OP_CODESEPARATOR have P2SH commitments.  I am also skeptical, and
> so is everyone reading this mailing list.  But none of us know this with
> certainty, and it is /wrong/ for any of us to gamble with other people's
> money that our assumptions are true.
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> 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).
>
> The fact that Bitcoin has stuck to this principle gives me and everyone
> else confidence in the protocol; that anyone can secure their funds by
> whatever scheme they dream up, and deploy it without needing permission or
> anyone else to vet their Scripts. So long as they are not impairing the
> Bitcoin protocol itself, the most that Bitcoin Core will do is stop
> relaying their transactions by default.
>
> Undermining this principle means undermining what provides Bitcoin's value
> in the first place.
>
> The problem in this particular case is that there exist valid secure
> transactions that make use OP_CODESEPARATOR such that these transactions
> themselves impair the Bitcoin protocol (through excessive validation costs)
> in a way that, AFAIU, is fundamental to the nature of such transactions (in
> particular, it isn't just due to an implementation detail of Bitcoin
> Core).  Thus to fix this vulnerability we must necessarily violate the
> principle of not invalidating, secure transactions.  However, this fact
> isn't license to freely invalidate any transactions we want.  We ought to
> strive to minimize the scope of violation of this principle.  Alice and Bob
> from XYZ. corp should be able to keep their benign transaction illustrated
> above, and we only eliminate those transactions that actually impair the
> Bitcoin protocol.
>
> This is the perfect opportunity to show the world that Bitcoin Core simply
> doesn't take chances when it comes to other people money.
>
> > Please don't strawman my position.  I am not suggesting we don't fix a
>> > vulnerability in Bitcoin.  I am suggesting we find another way.  One
>> > that limits the of risk destroying other people's money.
>> >
>> > Here is a more concrete proposal:  No matter how bad OP_CODESEPARATOR
>> > is, it cannot be worse than instead including another input that spends
>> > another identically sized UTXO.  So how about we soft-fork in a rule
>> > that says that an input's weight is increased by an amount equal to the
>> > number of OP_CODESEPARATORs executed times the sum of weight of the
>> UTXO
>> > being spent and 40 bytes, the weight of a stripped input. The risk of
>> > destroying other people's money is limited and AFAIU it would
>> completely
>> > address the vulnerabilities caused by OP_CODESEPARATOR.
>>
>> You're already arguing that someone has such an esoteric use of script,
>> suggesting they aren't *also* creating pre-signed, long-locktimed
>> transactions with many inputs isn't much of a further stretch
>> (especially since this may result in the fee being non-standardly low if
>> you artificially increase its weight).
>>
>
> There is no consensus rule about minimum fees, and CPFP could add the more
> fees. But yes, I am saying that Alice and Bob could be building on their
> transaction illustrated above, but not creating a many input tx that
> wouldn't fit into a block with my proposed added weight, because if their
> transaction won't fit into a block with the added weight then it was a
> malicious transaction to begin with.
>
> Do you not recognize the material difference between a soft-fork that
> doubles the cost of a transaction like Alice and Bob's versus making their
> transaction entirely illegal?
>
>
>> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
>> of complexity and reduces the simple analysis that fees (almost) have
>> today vs just removing it allows us to also remove a ton of code.
>
>
> Further note that if you don't remove it getting the efficiency wins
>> right is even harder because instead of being able to cache sighashes
>> you now have to (at a minimum) wipe the cache between each
>> OP_CODESEPARATOR call, which results in a ton of additional
>> implementation complexity.
>>
>
> How can this be "additional" complexity when this is how the protocol
> works today?  All you have to do is not change the semantics of
> OP_CODESEPARATOR.  It is literally no work.
> Regarding the efficiency wins, let me repeat myself: The performance costs
> of wiping the cached sighashs is not worse than what the performance costs
> would be if the transaction had an additional input spending an equally
> sized UTXO.
>
>
>> >      > I suggest an alternative whereby the execution of
>> OP_CODESEPARATOR
>> >      > increases the transactions weight suitably as to temper the
>> >      > vulnerability caused by it.  Alternatively there could be some
>> >     sort of
>> >      > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
>> >     allowed to be
>> >      > executed per script, but that would require an argument as to why
>> >      > exceeding that limit isn't reasonable.
>> >
>> >     You could equally argue, however, that any such limit could render
>> some
>> >     moderately-large transaction unspendable, so I'm somewhat skeptical
>> of
>> >     this argument. Note that OP_CODESEPARATOR is non-standard, so
>> getting
>> >     them mined is rather difficult in any case.
>> >
>> >
>> > I already know of people who's funds are tied up due to in other
>> changes
>> > to Bitcoin Core's default relay policy.  Non-standardness is not an
>> > excuse to take other people's tied up funds and destroy them
>> permanently.
>>
>> Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years.  Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do.  Perhaps others don't want to risk
> blowing their pseudonymity.  Perhaps they think that attempting to undo
> some of these non-standardness changes is futile.  I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
> Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
> transactions partially mitigates the vulnerability.  Once the vulnerability
> is properly patched, for example by suitably increasing the weight of the
> operation or opcode, we could drop the prohibition on relaying such
> transactions.  Non-standardness is not necessarily a path to a new
> consensus rule. We have several non-standardness rules in place that are
> never intended to become new consensus rules.  Sometimes non-standardness
> is a temporary mitigation.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr"><div class=3D"gmail_quote"><=
div>Instead, it is this soft-fork proposal that is unprecedented. Let me re=
iterate what I posted in another thread:=C2=A0<br></div><div><br></div><div=
 style=3D"margin-left:40px">Bitcoin has *never* made a soft-fork, since the=
 time of Satoishi, that invalidated transactions that send secured inputs t=
o secured outputs (excluding uses of OP_NOP1-OP_NOP10).</div></div></div></=
div></div></blockquote><div><br></div><div>This principle was only ever a r=
ule of thumb to protect users, not a commandment from God.=C2=A0 It shouldn=
&#39;t be violated lightly, but that&#39;s why Matt did the legwork to show=
 that the tradeoffs around OP_CODESEPARATOR justify=C2=A0removing it.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Huh?! The whole point of non-=
standardness in this context is to (a) make=C2=A0<br>soft-forking something=
 out safer by derisking miners not upgrading right=C2=A0<br>away and (b) si=
gnal something that may be a candidate for soft-forking=C2=A0<br>out so tha=
t we get feedback. Who is getting things disabled who isn&#39;t=C2=A0<br>bo=
thering to *tell* people that their use-case is being hurt?!<br></blockquot=
e><div><br></div><div>People have told me that they are hurt by some other =
non-standardness changes and I understand that they have been sitting on th=
ose funds for years.=C2=A0 Maybe they don&#39;t realize their is some place=
 to complain or maybe they think there must be a good reason why they are n=
ot allowed to do what they were previously allowed to do.=C2=A0 Perhaps oth=
ers don&#39;t want to risk blowing their pseudonymity.=C2=A0 Perhaps they t=
hink that attempting to undo some of these non-standardness changes is futi=
le.=C2=A0 I can bring up the specific cases I&#39;ve encountered in a new t=
hread if you think it is worthwhile.</div></div></div></div></div></blockqu=
ote><div><br></div><div>Like Matt, I understand non-standardness to be spec=
ifically for making a transaction type more difficult to set the stage for =
a future disabling.</div><div><br></div><div>If anyone is actually harmed b=
y this change, let them at least speak up pseudonymously as others have bef=
ore.=C2=A0 Backwards compatibility shouldn&#39;t mean letting imaginary imp=
lausible cases veto net-beneficial changes.</div><div><br></div></div></div=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Sat, Mar 9, 2019 at 5:21 PM Russell O&#39;Connor via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D=
"ltr"><div>Hi Matt,<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo &lt;<a h=
ref=3D"mailto:lf-lists@mattcorallo.com" rel=3D"noreferrer" target=3D"_blank=
">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Replies inline.<br>
<br>
On 3/8/19 3:57 PM, Russell O&#39;Connor wrote:<br>
&gt; On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo &lt;<a href=3D"mailto:lf-l=
ists@mattcorallo.com" rel=3D"noreferrer" target=3D"_blank">lf-lists@mattcor=
allo.com</a> <br>
&gt; &lt;mailto:<a href=3D"mailto:lf-lists@mattcorallo.com" rel=3D"noreferr=
er" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt;&gt; wrote:<br>
&gt; It&#39;s very easy to construct a practical script using OP_CODESEPARA=
TOR.<br>
&gt; <br>
&gt; IF &lt;2&gt; &lt;ALICEPUBKEY&gt; &lt;BOBPUBKEY&gt; &lt;2&gt; CHECKMULT=
ISIGVERIFY ELSE <br>
&gt; CODESEPARATOR &lt;ALICEPUBKEY&gt; CHECKSIGVERFY ENDIF<br>
&gt; <br>
&gt; Now when someone hands Alice, the CFO of XYZ corp., some transaction, =
<br>
&gt; she has the option of either signing it unilaterally herself, or <br>
&gt; creating a partial signature such that the transaction additionally <b=
r>
&gt; needs Bob, the CEOs signature as well, and Alice&#39;s choice is commi=
tted <br>
&gt; to the blockchain for auditing purposes later.<br>
&gt; <br>
&gt; Now, there are many things you might object about this scheme, but my =
<br>
&gt; point is that (A) regardless of what you think about this scheme, it, =
or <br>
&gt; similar schemes, may have been devised by users, and (B) users may hav=
e <br>
&gt; already committed funds to such schemes, and due to P2SH you cannot kn=
ow <br>
&gt; that this is not the case.<br>
<br>
The common way to set that up is to have a separate key, but, ok, fair <br>
enough. That said, the argument that &quot;it may be hidden by P2SH!&quot; =
isn&#39;t <br>
sufficient here. It has to *both* be hidden by P2SH and have never been <br=
>
spent from (either on mainnet or testnet) or be lock-timed a year in the <b=
r>
future. I&#39;m seriously skeptical that someone is using a highly esoteric=
 <br>
scheme and has just been pouring money into it without ever having <br>
tested it or having withdrawn any money from it whatsoever. This is just <b=
r>
a weird argument.<br></blockquote></div><div class=3D"gmail_quote"><br></di=
v><div class=3D"gmail_quote">No one is required to test their Scripts on a =
public testnet; they can use regtest. Because these transactions are non-st=
andard on mainnet, it could take years to arrange for these funds to be rec=
overed by having their transactions mined directly, or take years to become=
 valuable enough to be worth bothering having them directly mined.=C2=A0 As=
 I have noted elsewhere, you cannot first make transactions non-standard an=
d then use the fact that you don&#39;t see them being used on mainnet to ju=
stify a soft-fork.<div></div><div><br></div><div>My argument isn&#39;t weir=
d; it is principled.=C2=A0 You are skeptical that any uses of OP_CODESEPARA=
TOR have P2SH=20
commitments.=C2=A0 I am also skeptical, and so is everyone reading this=20
mailing list.=C2=A0 But none of us know this with certainty, and it is /wro=
ng/
for any of us to gamble with other people&#39;s money that our assumptions =
are true.<br><div><br></div></div><div> Instead, it is this soft-fork propo=
sal that is unprecedented. Let me reiterate what I posted in another thread=
: <br></div><div><br></div><div style=3D"margin-left:40px">Bitcoin has=20
*never* made a soft-fork, since the time of Satoishi, that invalidated=20
transactions that send secured inputs to secured outputs (excluding uses of=
 OP_NOP1-OP_NOP10).</div><div><br></div><div>The fact that
 Bitcoin has stuck to this principle gives me and everyone else=20
confidence in the protocol; that anyone can secure their funds by=20
whatever scheme they dream up, and deploy it without needing permission=20
or anyone else to vet their Scripts. So long as they are not=20
impairing the Bitcoin protocol itself, the most that Bitcoin Core will do i=
s stop
 relaying their transactions by default.<div><br></div><div>Undermining thi=
s principle means undermining what provides Bitcoin&#39;s value in the firs=
t place.</div><div><br></div><div>The problem in this particular case is th=
at there exist valid secure transactions that make=20
use OP_CODESEPARATOR such that these transactions themselves impair the Bit=
coin protocol (through
excessive validation costs) in a way that, AFAIU, is fundamental to
 the nature of such transactions (in particular, it isn&#39;t just due to a=
n implementation detail of Bitcoin Core).=C2=A0 Thus to fix this vulnerabil=
ity we must=20
necessarily violate the principle of not invalidating, secure=20
transactions.=C2=A0 However, this fact isn&#39;t license to freely invalida=
te any=20
transactions we want.=C2=A0 We ought to strive to minimize the scope of vio=
lation of=20
this principle.=C2=A0 Alice and Bob from XYZ. corp should be able to keep t=
heir benign transaction illustrated above,=20
and we only eliminate those transactions that actually impair the=20
Bitcoin protocol.</div><div><br></div>This is the perfect opportunity to sh=
ow the world that Bitcoin Core simply doesn&#39;t take chances when it come=
s to other people money.</div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">&gt; Please don&#39;t strawman my position.=C2=A0 I am =
not suggesting we don&#39;t fix a <br>
&gt; vulnerability in Bitcoin.=C2=A0 I am suggesting we find another way.=
=C2=A0 One <br>
&gt; that limits the of risk destroying other people&#39;s money.<br>
&gt; <br>
&gt; Here is a more concrete proposal:=C2=A0 No matter how bad OP_CODESEPAR=
ATOR <br>
&gt; is, it cannot be worse than instead including another input that spend=
s <br>
&gt; another identically sized UTXO.=C2=A0 So how about we soft-fork in a r=
ule <br>
&gt; that says that an input&#39;s weight is increased by an amount equal t=
o the <br>
&gt; number of OP_CODESEPARATORs executed times the sum of weight of the UT=
XO <br>
&gt; being spent and 40 bytes, the weight of a stripped input. The risk of =
<br>
&gt; destroying other people&#39;s money is limited and AFAIU it would comp=
letely <br>
&gt; address the vulnerabilities caused by OP_CODESEPARATOR.<br>
<br>
You&#39;re already arguing that someone has such an esoteric use of script,=
 <br>
suggesting they aren&#39;t *also* creating pre-signed, long-locktimed <br>
transactions with many inputs isn&#39;t much of a further stretch <br>
(especially since this may result in the fee being non-standardly low if <b=
r>
you artificially increase its weight).<br></blockquote><div><br></div><div>=
There is no consensus rule about minimum fees, and CPFP could add the more =
fees. But yes, I am saying that Alice and Bob could be building on their tr=
ansaction illustrated above, but not creating a many input tx that wouldn&#=
39;t fit into a block with my proposed added weight, because if their trans=
action won&#39;t fit into a block with the added weight then it was a malic=
ious transaction to begin with.<br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Do you not recognize the material difference between a soft-for=
k that doubles the cost of a transaction like Alice and Bob&#39;s versus ma=
king their transaction entirely illegal?</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
Note that &quot;just limit number of OP_CODESEPARATOR calls&quot; results i=
n a ton <br>
of complexity and reduces the simple analysis that fees (almost) have <br>
today vs just removing it allows us to also remove a ton of code.</blockquo=
te><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">
Further note that if you don&#39;t remove it getting the efficiency wins <b=
r>
right is even harder because instead of being able to cache sighashes <br>
you now have to (at a minimum) wipe the cache between each <br>
OP_CODESEPARATOR call, which results in a ton of additional <br>
implementation complexity.<br></blockquote><div><br></div><div>How can this=
 be &quot;additional&quot; complexity when this is how the protocol works t=
oday?=C2=A0 All you have to do is not change the semantics of OP_CODESEPARA=
TOR.=C2=A0 It is literally no work.</div><div>Regarding the efficiency wins=
, let me repeat myself: The performance costs of wiping the cached sighashs=
 is not worse than what the performance costs would be if the transaction h=
ad an additional input spending an equally sized UTXO.<br></div><div>=C2=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I suggest an alternative whereby the executio=
n of OP_CODESEPARATOR<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; increases the transactions weight suitably as=
 to temper the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; vulnerability caused by it.=C2=A0 Alternative=
ly there could be some<br>
&gt;=C2=A0 =C2=A0 =C2=A0sort of<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; limit (maybe 1) on the maximum number of OP_C=
ODESEPARATORs<br>
&gt;=C2=A0 =C2=A0 =C2=A0allowed to be<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; executed per script, but that would require a=
n argument as to why<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; exceeding that limit isn&#39;t reasonable.<br=
>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0You could equally argue, however, that any such lim=
it could render some<br>
&gt;=C2=A0 =C2=A0 =C2=A0moderately-large transaction unspendable, so I&#39;=
m somewhat skeptical of<br>
&gt;=C2=A0 =C2=A0 =C2=A0this argument. Note that OP_CODESEPARATOR is non-st=
andard, so getting<br>
&gt;=C2=A0 =C2=A0 =C2=A0them mined is rather difficult in any case.<br>
&gt; <br>
&gt; <br>
&gt; I already know of people who&#39;s funds are tied up due to in other c=
hanges <br>
&gt; to Bitcoin Core&#39;s default relay policy.=C2=A0 Non-standardness is =
not an <br>
&gt; excuse to take other people&#39;s tied up funds and destroy them perma=
nently.<br>
<br>
Huh?! The whole point of non-standardness in this context is to (a) make <b=
r>
soft-forking something out safer by derisking miners not upgrading right <b=
r>
away and (b) signal something that may be a candidate for soft-forking <br>
out so that we get feedback. Who is getting things disabled who isn&#39;t <=
br>
bothering to *tell* people that their use-case is being hurt?!<br></blockqu=
ote><div><br></div><div>People have told me that they are hurt by some othe=
r non-standardness changes and I understand that they have been sitting on =
those funds for years.=C2=A0 Maybe they don&#39;t realize their is some pla=
ce to complain or maybe they think there must be a good reason why they are=
 not allowed to do what they were previously allowed to do.=C2=A0 Perhaps o=
thers don&#39;t want to risk blowing their pseudonymity.=C2=A0 Perhaps they=
 think that attempting to undo some of these non-standardness changes is fu=
tile.=C2=A0 I can bring up the specific cases I&#39;ve encountered in a new=
 thread if you think it is worthwhile.<br></div><div><br></div><div>Regardi=
ng OP_CODESEAPRATOR specifically, disabling the rely of such transactions p=
artially mitigates the vulnerability.=C2=A0 Once the vulnerability is prope=
rly patched, for example by suitably increasing the weight of the operation=
 or opcode, we could drop the prohibition on relaying such transactions.=C2=
=A0 Non-standardness is not necessarily a path to a new consensus rule. We =
have several non-standardness rules in place that are never intended to bec=
ome new consensus rules.=C2=A0  Sometimes non-standardness is a temporary m=
itigation. </div><br></div></div></div>
</div>
_______________________________________________<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>
</blockquote></div>

--0000000000002ca37b0583b50327--