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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A4D9699A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 10:15:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from erelay3.ox.registrar-servers.com
(erelay3.ox.registrar-servers.com [192.64.117.2])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1CD94A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 10:15:51 +0000 (UTC)
Received: from localhost (unknown [127.0.0.1])
by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id
9B0CC2206BE5; Wed, 17 Aug 2016 10:15:50 +0000 (UTC)
Received: from erelay1.ox.registrar-servers.com ([127.0.0.1])
by localhost (erelay.ox.registrar-servers.com [127.0.0.1]) (amavisd-new,
port 10024)
with LMTP id Dspc6QKv8ofz; Wed, 17 Aug 2016 06:15:49 -0400 (EDT)
Received: from MTA-10.privateemail.com (unknown [10.20.150.200])
(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by erelay1.ox.registrar-servers.com (Postfix) with ESMTPS id
40F9222067DB; Wed, 17 Aug 2016 06:15:49 -0400 (EDT)
Received: from APP-06 (unknown [10.20.147.156])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by MTA-10.privateemail.com (Postfix) with ESMTPSA id 8DA4960038;
Wed, 17 Aug 2016 10:15:48 +0000 (UTC)
Date: Wed, 17 Aug 2016 06:15:48 -0400 (EDT)
From: Johnson Lau <jl2012@xbt.hk>
Reply-To: Johnson Lau <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org, Luke Dashjr <luke@dashjr.org>
Message-ID: <703193091.96057.1471428948569@privateemail.com>
In-Reply-To: <201608170440.35767.luke@dashjr.org>
References: <1736097121.90204.1471369988809@privateemail.com>
<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
<976728541.94211.1471402973613@privateemail.com>
<201608170440.35767.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_96056_1392606999.1471428948508"
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.8.1-Rev18
X-Originating-Client: open-xchange-appsuite
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Wed, 17 Aug 2016 10:15:52 -0000
------=_Part_96056_1392606999.1471428948508
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
> On August 17, 2016 at 12:40 AM Luke Dashjr <luke@dashjr.org> wrote:
>
>
> On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> > To completely replicate the original behaviour, one may use:
> > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> > ELSE DROP {else script} ENDIF"
>
> This is much uglier than expected. IMO if that's the best workaround for the
> current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they
> need to avoid malleability issues.
It is ugly only if you want to faithfully replicate the behaviour. I'd argue that in no real use case you need to do this. For example, "OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must return a valid MINIMALDATA number.
And your workaround does not fix malleability, since any non-0x01 values are valid FALSE
However, in some case, enforcing MINIMALIF does require 1 more witness byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html
I think the best strategy is to make it a relay policy first, and decide whether we want a softfork later.
------=_Part_96056_1392606999.1471428948508
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html><head>
<meta charset=3D"UTF-8">
</head><body><p><br></p><p>> On August 17, 2016 at 12:40 AM Luke Dashjr=
<luke@dashjr.org> wrote:<br>> <br>> <br>> On Wednesday=
, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:<br>> &#=
62; To completely replicate the original behaviour, one may use:<br>> &=
#62; "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {i=
f script}<br>> > ELSE DROP {else script} ENDIF"<br>> <br>&#=
62; This is much uglier than expected. IMO if that's the best workaroun=
d for the <br>> current behaviour, people should just use "OP_1 OP_=
EQUAL OP_IF" when/if they <br>> need to avoid malleability issues.<=
/p><p>It is ugly only if you want to faithfully replicate the behaviour. I&=
#39;d argue that in no real use case you need to do this. For example, "=
;OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF",=
since OP_SIZE must return a valid MINIMALDATA number.</p><p>And your worka=
round does not fix malleability, since any non-0x01 values are valid FALSE<=
/p><p>However, in some case, enforcing MINIMALIF does require 1 more witnes=
s byte: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2016-August/013036.html">https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2016-August/013036.html</a></p><p>I think the best strategy is t=
o make it a relay policy first, and decide whether we want a softfork later=
.</p></body></html>
=20
------=_Part_96056_1392606999.1471428948508--
|
