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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
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 BB8D0CA21
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 18:35:48 +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 A90075E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Mar 2019 18:35:45 +0000 (UTC)
Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id 398C11841A9;
Fri, 8 Mar 2019 18:35:43 +0000 (UTC)
To: Russell O'Connor <roconnor@blockstream.io>
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>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <db3405ef-7e06-9538-0700-df37abaa602d@mattcorallo.com>
Date: Fri, 8 Mar 2019 18:35:42 +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: <CAMZUoKk3CgatSexAHRuxn3ibCYwgHpTkc0gF0yDi6hLAVcCiNA@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: Fri, 08 Mar 2019 18:58:57 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 08 Mar 2019 18:35:48 -0000
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.
> 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).
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.
>
> > 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?!
|
