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
|
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 F28CFA58
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 04:41:04 +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 17BB4125
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 04:41:02 +0000 (UTC)
Received: from localhost (unknown [127.0.0.1])
by erelay1.ox.registrar-servers.com (Postfix) with ESMTP id
84F4A2207FD2 for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 04:41:01 +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 Z0ZbzwPKduvS for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 00:40:58 -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
9FFB82208004 for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 00:40:58 -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 71FCF60032
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Sep 2016 04:40:58 +0000 (UTC)
Date: Fri, 2 Sep 2016 00:40:58 -0400 (EDT)
From: Johnson Lau <jl2012@xbt.hk>
Reply-To: Johnson Lau <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <1317364559.64256.1472791258452@privateemail.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-Rev19
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: [bitcoin-dev] New BIP: Dealing with dummy stack element malleability
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, 02 Sep 2016 04:41:05 -0000
https://github.com/bitcoin/bips/pull/440
https://github.com/bitcoin/bitcoin/pull/8636
This document specifies proposed changes to the Bitcoin transaction validity rules to fix the malleability of extra stack element for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.
The original plan was to do the LOW_S and NULLDUMMY (BIP146) together with segwit in 0.13.1. However, as we discovered some undocumented behavior in LOW_S, we may want to deploy the LOW_S softfork in a later release. https://github.com/bitcoin/bitcoin/pull/8533#issuecomment-243973512
I will edit the BIP146 later.
BIP: ?
Title: Dealing with dummy stack element malleability
Author: Johnson Lau <jl2012@xbt.hk>
Status: Draft
Type: Standards Track
Created: 2016-09-02
Abstract
This document specifies proposed changes to the Bitcoin transaction validity rules to fix the malleability of extra stack element for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY.
Motivation
Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay (BIP152).
A design flaw in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY makes them consuming an extra stack element ("dummy element") after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script. This document specifies a new rule to fix this signature malleability.
Specification
To fix the dummy element malleability, a new consensus rule ("NULLDUMMY") is deployed to require that the dummy element MUST be the empty byte array. Anything else makes the script evaluate to false immediately. The NULLDUMMY rule applies to OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY in pre-segregated scripts, and also pay-to-witness-script-hash scripts described in BIP141.
Deployment
This BIP will be deployed by "version bits" BIP9 using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
For Bitcoin mainnet, the BIP9 starttime is midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout is midnight TBD UTC (Epoch timestamp TBD).
For Bitcoin testnet, the BIP9 starttime is midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout is midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
Compatibility
The reference client has produced compatible signatures from the beginning, and the NULLDUMMY rule has been enforced as relay policy by the reference client since v0.10.0. There has been no transactions violating the requirement being added to the chain since at least August 2015. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement.
Implementation
An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8636
Acknowledgements
This document is extracted from the previous BIP62 proposal, which was composed by Pieter Wuille and had input from various people.
Copyright
This document is placed in the public domain.
|
