1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 30337C7CB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:50:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8D463F7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 19:50:54 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id 6924F184F43;
Thu, 7 Mar 2019 19:50:53 +0000 (UTC)
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
Date: Thu, 7 Mar 2019 19:50:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Thu, 07 Mar 2019 23:48:02 +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: Thu, 07 Mar 2019 19:50:55 -0000
Replies inline.
Matt
On 3/7/19 3:03 PM, Russell O'Connor wrote:
>
> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
> This includes OP_CODESEPARATORs in unexecuted branches of if
> statements,
> similar to other disabled opcodes, but unlike OP_RETURN.
>
>
> OP_CODESEPARATOR is the only mechanism available that allows users to
> sign which particular branch they are authorizing for within scripts
> that have multiple possible conditions that reuse the same public key.
This is true, and yet it does not appear to actually be practically
usable. Thus far, despite a ton of effort, I have not yet seen a
practical use-case for OP_CODESEPARATOR (except for one example of it
being used to make SegWit scripts ever-so-slightly more effecient in
TumbleBit, hence why this BIP does not propose disabling it for SegWit).
> Because of P2SH you cannot know that no one is currently using this
> feature. Activating a soft-fork as describe above means these sorts of
> funds would be permanently lost. It is not acceptable to risk people's
> money like this.
(1) It has been well documented again and again that there is desire to
remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
non-segwit scripts represents a rather significant vulnerability in
Bitcoin today, and (3) lots of effort has gone into attempting to find
practical use-cases for OP_CODESEPARATOR's specific construction, with
no successes as of yet. I strongly, strongly disagree that the
highly-unlikely remote possibility that someone created something before
which could be rendered unspendable is sufficient reason to not fix a
vulnerability in Bitcoin today.
> 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.
|
