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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BD5199E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 00:28:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8E04787
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 00:28:15 +0000 (UTC)
Received: by mail-ua0-f175.google.com with SMTP id 97so148784316uav.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 17:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=9U7NqfmgiqpBuyH6+S2B0L3dQOunskx3+cr2z+xIaFE=;
b=PzV+rZmIzU/l+TI6vFZDoo/zpGlxLsmxgbEsRu28piH8wqq7HwA1iG+Kp+0uj9u5ZF
49OkKLH2ZP1w+LMQmxjUwXbA5EQ4Gn4CSK+yavsBZnzeSmVhAdulQBdDb6tYA1vYi3QM
lHHKEowODzX2WArQl9kRCcG1GCOtWhq+KPxKfYkXWO4mGZ8ZZ+IEMnFTc0WpOwVXxjfz
MP2eQJAvd/wcTyMKdY4olrpWFif4MaZzvOz4WBdrZmhSqEOYnHb/RkIvqNMk8sIjU1FX
TqDd/OG3RnoOzN+b3SYfumYFDWv/WwqRZFw0fB+yLfRkxlp0vlGsGJWkpw85vsrul1aP
CsAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=9U7NqfmgiqpBuyH6+S2B0L3dQOunskx3+cr2z+xIaFE=;
b=m47jLUvAzuxoyzp0rHvM7jSe7ZLWIxArR+bjmGzF+ShCqoWt144CleiQo09IxhhQhm
DKv2xWYNrIN5yeTLRuBD7idLgVZaI3LK7ZGiVoTWoDgUTr0m801PgqmMZyRUT3FCpILL
Xy7v0G3cXnJqcc1p5GogeN8onpmrJePW0Z+VhWCzkb5+WWiUt8K+rOkcpy1M0DsgFknD
Qvzo8uXw/S7zQWVFG/lJHw0Sk5/IolIlxX04tUWKiz21XWg5KIemIucLwBfCgdIxMXc8
isqnyrmmTxDD0+fO7EJWymxvmfIe3qW+pQOTJRjfdla6VYVAY+Jk+wHJl3+ZJA+lfiOl
Jr7g==
X-Gm-Message-State: AEkooutXKv4NsEnFelMJ9YM2ABzUNRVQb9nDdKwszsAFRzfgQ+6MsPVM4WCuhR0dmrax22gBu8a1nXktTaVF6MCZ
X-Received: by 10.31.151.196 with SMTP id z187mr15372523vkd.138.1471393694807;
Tue, 16 Aug 2016 17:28:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.83.45 with HTTP; Tue, 16 Aug 2016 17:27:54 -0700 (PDT)
In-Reply-To: <CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
<201608161937.20748.luke@dashjr.org>
<20160816194332.GA5888@fedora-21-dvm>
<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
<CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 16 Aug 2016 20:27:54 -0400
Message-ID: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a11425e44810c62053a398adc
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Wed, 17 Aug 2016 00:31:29 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH
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: Wed, 17 Aug 2016 00:28:19 -0000
--001a11425e44810c62053a398adc
Content-Type: text/plain; charset=UTF-8
Okay.
I'm not really opposed to this BIP, but I am worried that fighting script
malleability is a battle that can never be won; even leaving one avenue of
malleability open is probably just as bad as having many avenues of
malleability, so it just doesn't seem worthwhile to me.
On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <greg@xiph.org> wrote:
> On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I see.
> >
> > But is it really necessary to soft fork over this issue? Why not just
> make
> > it a relay rule? Miners are already incentivized to modify transactions
> to
> > drop excess witness data and/or prioritize (versions of) transactions
> based
> > on their cost. If a miner wants to mine a block with excess witness
> data,
> > it is mostly their own loss.
>
> Relay rules are quite fragile-- people build programs or protocols not
> expecting them to be violated, without proper error handling in those
> cases... and then eventually some miner rips them out because they
> simply don't care about them: not enforcing them won't make their
> blocks invalid.
>
> It's my general view that we should avoid blocking things with relay
> rules unless we think that someday they could be made invalid... not
> necessarily that they will, but that it's plausible. Then the
> elimination at the relay level is just the first exploratory step in
> that direction.
>
> One should also consider adversarial behavior by miners. For example,
> I can mine blocks with mutated witnesses with a keyed mac that chooses
> the mutation. The key is shared by conspirators or customers, and now
> collectively we have a propagation advantage (since we know the
> mutated version before it shows up). Not the _biggest_ concern, since
> parties doing this could just create their own new transactions to
> selectively propagate; but doing that would require leaving behind fee
> paying public transactions, while using malleability wouldn't.
>
--001a11425e44810c62053a398adc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Okay.<br><br>I'm not really opposed to this BIP, but I=
am worried that fighting script malleability is a battle that can never be=
won; even leaving one avenue of malleability open is probably just as bad =
as having many avenues of malleability, so it just doesn't seem worthwh=
ile to me.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <span dir=3D"ltr"><<=
a href=3D"mailto:greg@xiph.org" target=3D"_blank">greg@xiph.org</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, Aug 1=
6, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
> I see.<br>
><br>
> But is it really necessary to soft fork over this issue?=C2=A0 Why not=
just make<br>
> it a relay rule?=C2=A0 Miners are already incentivized to modify trans=
actions to<br>
> drop excess witness data and/or prioritize (versions of) transactions =
based<br>
> on their cost.=C2=A0 If a miner wants to mine a block with excess witn=
ess data,<br>
> it is mostly their own loss.<br>
<br>
</span>Relay rules are quite fragile-- people build programs or protocols n=
ot<br>
expecting them to be violated, without proper error handling in those<br>
cases... and then eventually some miner rips them out because they<br>
simply don't care about them: not enforcing them won't make their<b=
r>
blocks invalid.<br>
<br>
It's my general view that we should avoid blocking things with relay<br=
>
rules unless we think that someday they could be made invalid... not<br>
necessarily that they will, but that it's plausible. Then the<br>
elimination at the relay level is just the first exploratory step in<br>
that direction.<br>
<br>
One should also consider adversarial behavior by miners.=C2=A0 For example,=
<br>
I can mine blocks with mutated witnesses with a keyed mac that chooses<br>
the mutation. The key is shared by conspirators or customers, and now<br>
collectively we have a propagation advantage (since we know the<br>
mutated version before it shows up).=C2=A0 Not the _biggest_ concern, since=
<br>
parties doing this could just create their own new transactions to<br>
selectively propagate; but doing that would require leaving behind fee<br>
paying public transactions, while using malleability wouldn't.<br>
</blockquote></div><br></div>
--001a11425e44810c62053a398adc--
|
