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
|
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 EF1AE8B1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 22:23:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3BFE2FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 22:23:22 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id n59so145289740uan.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 16 Aug 2016 15:23:22 -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;
bh=UGB0aN+DN07dob6s8QJ1NbOoo+i3C/MVp3GqSLv9A4I=;
b=m5V76RDmdTAoI5SYmZ+FxG2y6KHhaAZCOvN4YjiTgk36rCJa5/WiTcwOT4MhrbPlK0
nfvWBWkq/mUwGm1JP94Nx50338o2i0vrQ5C5Ub3rdGJm3jWqTyRrUlpBpWbIG4PqRoux
/QrIMdqqGadPBaosBybFChGyiEhrh06biwyMpd3jvSqz2cwx9KzOiw3ffggPKL5J8oAG
d1VKl3loJYgg+ihSrhnI1t0P0+B99oeqMjqS4b2KIKXPA4mwuxxT1v8kHk3Wy3rQdTxB
46lOK4CNcHWC+OcoonogpmlMjSwI+Ncf8SDainVcqkgydT1y71unkbrKhKw1pJ8Ahe44
BdAg==
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;
bh=UGB0aN+DN07dob6s8QJ1NbOoo+i3C/MVp3GqSLv9A4I=;
b=KHgAwSNAK0VCh3XDC+dEl2OX6JhFCYEpxY9xLFlUw/bql7JTngV7HcTxcZ8K2ZCuEY
Hvx4NwQbro5OGt5WJDGJlQz+Jq+oXZ5kXQWKbpWr+bvzuIFrIC9K5rYzgn8stclev6fr
pR+TO7qQsV9MQ5618yf7PmRqwwpOWEIu768Jo9UyIEHMqGqGX1FC/Pdy4nuWPQ6dSRh8
PpQUVLz0YDnWnmKlZIU6wFUM20DhuxKbVNVXjt2TnNz1IVfaBSz9OhMLkDNOhIAlPd61
POHED0BNG3KDLGPoWeW80FDw4T7URcYu8lOhtuxYmulIDlMHSS2WOFsc5qXcbsNcYq81
0/fw==
X-Gm-Message-State: AEkoouuLH22HhSbSxS7wyd0lYKhesf0zE/9RJuS0EqT8wCmlQkUOWYUmKFGhNaI/Jeni9uNZkh0S8vy9gsFTuEKP
X-Received: by 10.159.40.163 with SMTP id d32mr18173551uad.115.1471386201124;
Tue, 16 Aug 2016 15:23:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.83.45 with HTTP; Tue, 16 Aug 2016 15:23:00 -0700 (PDT)
In-Reply-To: <20160816194332.GA5888@fedora-21-dvm>
References: <1736097121.90204.1471369988809@privateemail.com>
<201608161937.20748.luke@dashjr.org>
<20160816194332.GA5888@fedora-21-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 16 Aug 2016 18:23:00 -0400
Message-ID: <CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1227d0d8890a053a37cb55
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
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: Tue, 16 Aug 2016 22:23:23 -0000
--94eb2c1227d0d8890a053a37cb55
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Aug 16, 2016 at 07:37:19PM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> > > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> > > P2WSH:
> > > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> > > https://github.com/bitcoin/bitcoin/pull/8526
> >
> > I am not sure this makes sense. SegWit transactions are already
> non-malleable
> > due to skipping the witness data in calculating the transaction id. What
> is
> > the benefit to this?
>
> SegWit txids aren't malleable, but segwit transactions as a whole still
> are.
> For instance, I could mess with a segwit transaction by replacing part of
> the
> witness that is used as an argument to an OP_IF with a much larger push,
> potentially making the transaction larger, thus making it not get mined
> due to
> the higher fee. There are also potential legal issues if someone replaces a
> push with data where posession in your jurisdiction is illegal.
>
If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness. Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.
Worries about "illegal data" appearing in the blockchain is not an issue
worth writing a soft-fork over.
There may be good reasons for this BIP, but I don't think the reasons give
above are good.
--94eb2c1227d0d8890a053a37cb55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, Aug 16, 2016 at 07=
:37:19PM +0000, Luke Dashjr via bitcoin-dev wrote:<br>
> On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wro=
te:<br>
> > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleabilit=
y in<br>
> > P2WSH:<br>
> > <a href=3D"https://github.com/jl2012/bips/blob/minimalif/bip-mini=
malif.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl=
2012/<wbr>bips/blob/minimalif/bip-<wbr>minimalif.mediawiki</a><br>
> > <a href=3D"https://github.com/bitcoin/bitcoin/pull/8526" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/bitcoin/<wbr>bitcoin/pull/8=
526</a><br>
><br>
> I am not sure this makes sense. SegWit transactions are already non-ma=
lleable<br>
> due to skipping the witness data in calculating the transaction id. Wh=
at is<br>
> the benefit to this?<br>
<br>
</span>SegWit txids aren't malleable, but segwit transactions as a whol=
e still are.<br>
For instance, I could mess with a segwit transaction by replacing part of t=
he<br>
witness that is used as an argument to an OP_IF with a much larger push,<br=
>
potentially making the transaction larger, thus making it not get mined due=
to<br>
the higher fee. There are also potential legal issues if someone replaces a=
<br>
push with data where posession in your jurisdiction is illegal.<br></blockq=
uote><div><br></div><div>If one's goal is to mess with an transaction t=
o prevent it from being mined, it is more effective to just not relay the t=
ransaction rather than to mess with the witness.=C2=A0 Given two transactio=
ns with the same txid and different witness data, miners and good nodes oug=
ht to mine/relay the version with the lower cost (smaller?) witness data.<b=
r><br></div><div>Worries about "illegal data" appearing in the bl=
ockchain is not an issue worth writing a soft-fork over.<br><br></div><div>=
There may be good reasons for this BIP, but I don't think the reasons g=
ive above are good.</div></div><br></div></div>
--94eb2c1227d0d8890a053a37cb55--
|
