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
|
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 63748721
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Sep 2016 09:44:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
[74.201.84.163])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C448CE9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Sep 2016 09:44:58 +0000 (UTC)
Received: from mail.zoho.com by mx.zohomail.com
with SMTP id 1473499790046493.99296726335467;
Sat, 10 Sep 2016 02:29:50 -0700 (PDT)
Date: Sat, 10 Sep 2016 17:29:50 +0800
From: Johnson Lau <jl2012@xbt.hk>
To: "bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <157136e7ad6.122f8dcad4225.6188604322226919947@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
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] Proposed segwit related consensus and policy rules in
Bitcoin Core 0.13.1
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: Sat, 10 Sep 2016 09:44:59 -0000
There are several opening pull requests for segwit related consensus and policy rules. This email summarize and explain the rationale.
As a general warning, people must not assume that a script spendable in pre-segwit system would also be spendable as a segwit script. They share much similarity but there are also notable differences, such as BIP143 and those proposals listed below. In any case, test your segwit system on testnet with the standard rules turned on, and a small amount of money after segwit is activated on mainnet.
*******************
Script Malleability fixes: Segwit (BIP141) fixes the most nasty malleability in Bitcoin: transaction ID malleability. However, due to the flexibility of scripting system, it is still possible for a relay node to insert arbitrary data to the witness without invalidating the transaction. Although segwit makes such attacks much harmless, this could still be annoying as people may write data to the blockchain at others costs.
NULLDUMMY, MINIMALIF, NULLFAIL are fixing this type of problem. NULLDUMMY has been implemented as a policy for more than a year and a softfork is proposed in the upcoming 0.13.1. MINIMALIF and NULLFAIL are both new policy proposed for 0.13.1, and may become softforks in the future. Script designers must pay attention to these potential softforks to avoid creation of unspendable scripts.
Consensus:
BIP147 "NULLDUMMY" softfork (for both segwit and pre-segwit scripts)
PR: https://github.com/bitcoin/bitcoin/pull/8636
Related discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013096.html
Policy:
"MINIMALIF" Minimal OP_IF/NOTIF argument (segwit scripts only)
PR: https://github.com/bitcoin/bitcoin/pull/8526
Related discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html
Policy:
"NULLFAIL" Null signature for failed CHECK(MULTI)SIG (for both segwit and pre-segwit scripts)
PR: https://github.com/bitcoin/bitcoin/pull/8634
Related discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013098.html
*******************
Policy: Resources limit for P2WSH
PR: https://github.com/bitcoin/bitcoin/pull/8499
For P2WSH, a policy limit is proposed with witnessScript <= 3600 bytes, witness stack item size <= 80 bytes, and witness stack items <= 100
3600 bytes witnessScript and 100 stack items are adequate for a n-of-100 multisig using 100 OP_CHECKSIG, 99 OP_ADD, and 1 OP_EQUAL. Before segwit, the biggest standard mutlisig is n-of-15 with P2SH.
The max size for ECDSA signature is 73 bytes and nothing (except hashing opcodes) should use more than that with the current scripting language.
This is to prevent abuse of witness space, and reduce the risks of DoS attack with some unknown special and big scripts.
The consensus limits described in BIP141 are not changed, as witnessScript <= 10000 bytes and witness stack item size <= 520 bytes. (There is also an implied limit for witness stack items of 412, see the inline comments in #8499)
*******************
Policy: Public key must be compressed (segwit only)
PR: https://github.com/bitcoin/bitcoin/pull/8499
It is proposed that only compressed keys (33 bytes starting with 0x02 or 0x03) are allowed in segwit scripts.
This is a policy only and non-compressed keys are still valid in a block. A softfork based on this may be proposed with further risks and benefits analysis
We can't have such policy or softfork in non-segwit scripts since there are many UTXOs being stored that way. Since segwit is a completely new script system, there is no strong reasons to support non-compressed keys.
Wallet developers must pay attention to this policy and must not assume that existing P2PKH hashes or P2SH scripts are spendable in segwit.
The RPC command addwitnessaddress will refuse to return a segwit address if the given key/multi-sig is unknown or is not compressed.
createwitnessaddress will return an address for whatever scripts given, without checking the validity at all. (even an OP_RETURN is provided, it will still return a P2WSH address). We may need to give a warning, or simply remove this command.
*******************
DoS protection: Banning peers for sending certain types of consensus invalid witness
PR: https://github.com/bitcoin/bitcoin/pull/8499
Peers sending certain types of invalid witness will be banned before fee and SigOp policy are checked. Those are all based on explicit or implicit consensus rules, and will protect P2WPKH and canonical multisigs against the DoS issues described in #8279. The rest of P2WSH scripts will be covered by #8525 by not storing witness txs in rejection cache.
*******************
DoS protection: Mandatory softfork flags for segwit txs
PR: https://github.com/bitcoin/bitcoin/pull/8499
Since all segwit-aware nodes must be aware of all existing softforks, including BIP66, 65, 112, 141, and 143, the verification flags for these BIPs will be mandatory for transactions with non-empty witness. Wallets relaying witness transactions violating these rules will be banned (even if the violation happens in a non-segwit input).
|
