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
|
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 DB3018B1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 03:02:56 +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 4F9B8126
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Aug 2016 03:02:56 +0000 (UTC)
Received: from localhost (unknown [127.0.0.1])
by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id
8EB0722088F4; Wed, 17 Aug 2016 03:02:55 +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 ONIstY8794iZ; Tue, 16 Aug 2016 23:02:54 -0400 (EDT)
Received: from MTA-07.privateemail.com (unknown [10.20.150.170])
(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
14B8F22088F3; Tue, 16 Aug 2016 23:02:54 -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-07.privateemail.com (Postfix) with ESMTPSA id 9984760034;
Wed, 17 Aug 2016 03:02:53 +0000 (UTC)
Date: Tue, 16 Aug 2016 23:02:53 -0400 (EDT)
From: Johnson Lau <jl2012@xbt.hk>
Reply-To: Johnson Lau <jl2012@xbt.hk>
To: Gregory Maxwell <greg@xiph.org>,
Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
pete@petertodd.org
Message-ID: <976728541.94211.1471402973613@privateemail.com>
In-Reply-To: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@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>
<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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,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 03:02:57 -0000
> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
Not really. I think the goal is to protect as many common scripts as possible.
For example:
1) BIP146 (Low S values signatures) will eliminate all malleability for P2WPKH
2) BIP146 + null dummy value for CHECKMULTISIG ("NULLDUMMY") will eliminate all malleability for simple multi-sig in P2WSH. This is particularly interesting since without NULLDUMMY, attackers are able to replace the dummy value with anything.
3) BIP146 + NULLDUMMY + minimal IF argument ("MINIMALIF") will eliminate malleability for any Lightening Network scripts that I'm aware of.
With 3), 99.99% of segwit transactions in foreseeable future should be fully protected.
The plan is to implement MINIMALIF as a relay policy first, and enforce the softfork after further risks assessment. This BIP serves as a warning to users for not using incompatible script.
Peter Todd:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode that fails unless the top item on the stack is a minimally encoded true or false value, to allow script writers to opt into this behavior; it's not always ideal.
I believe all Lightening Network scripts (the only real users of IF/NOTIF in foreseeable future) are already compatible with MINIMALIF. It may not be a good idea for them to spend 1 more byte to get protected.
If people want to have the original OP_IF behaviour, a simple way would be using "0NOTEQUAL IF". However, this works only if the argument is a valid number (also beware of MINIMALDATA rule in BIP62).
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 because we don't have a simple OP_CASTTOBOOL, and IFDUP is 1 of the 4 codes that perform CastToBool on top stack item (the others are VERIFY, IF, and NOTIF; and VERIFY can't be used here since it terminates the script with a False).
|
