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
|
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 84210BD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 15:25:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77C06159
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 15:25:12 +0000 (UTC)
Received: from localhost ([::1]:39818 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1a88WM-001lFt-SD; Sun, 13 Dec 2015 10:25:10 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 13 Dec 2015 10:25:10 -0500
From: jl2012@xbt.hk
To: Gregory Maxwell <greg@xiph.org>
In-Reply-To: <CAAS2fgT09Tk+5dBQ4YJA_pwK56xX2mEQe9TkJqgcB0j2BZZJ1g@mail.gmail.com>
References: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
<CAAS2fgT09Tk+5dBQ4YJA_pwK56xX2mEQe9TkJqgcB0j2BZZJ1g@mail.gmail.com>
Message-ID: <2498d6a0691fde6f62453294da6118d0@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
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
X-Mailman-Approved-At: Sun, 13 Dec 2015 17:13:13 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, gmaxwell@gmail.com
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 13 Dec 2015 15:25:13 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I'm trying to list the minimal consensus rule changes needed for segwit
softfork. The list does not cover the changes in non-consensus critical
behaviors, such as relay of witness data.
1. OP_NOP4 is renamed as OP_SEGWIT
2. A script with OP_SEGWIT must fail if the scriptSig is not completely
empty
3. If OP_SEGWIT is used in the scriptPubKey, it must be the only and the
last OP code in the scriptPubKey, or the script must fail
4. The OP_SEGWIT must be preceded by exactly one data push (the
"serialized script") with at least one byte, or the script must fail
5. The most significant byte of serialized script is the version byte,
an unsigned number
6. If the version byte is 0x00, the script must fail
7. If the version byte is 0x02 to 0xff, the rest of the serialized
script is ignored and the output is spendable with any form of witness
(even if the witness contains something invalid in the current script
system, e.g. OP_RETURN)
8. If the version byte is 0x01,
8a. rest of the serialized script is deserialized, and be interpreted as
the scriptPubKey.
8b. the witness is interpreted as the scriptSig.
8c. the script runs with existing rules (including P2SH)
9. If the script fails when OP_SEGWIT is interpreted as a NOP, the
script must fail. However, this is guaranteed by the rules 2, 3, 4, 6 so
no additional check is needed.
10. The calculation of Merkle root in the block header remains unchanged
11. The witness commitment is placed somewhere in the block, either in
coinbase or an OP_RETURN output in a specific tx
Format of the witness commitment:
The witness commitment could be as simple as a hash tree of all witness
in a block. However, this is bad for further development of sum tree for
compact SPV fraud proof as we have to maintain one more tree in the
future. Even if we are not going to implement any sum checking in first
version of segwit, it's better to make it easier for future softforks.
(credit: gmaxwell)
12. The block should indicate how many sum criteria there are by
committing the number following the witness commitment
13. The witness commitment is a hash-sum tree with the number of sum
criteria committed in rule 12
14. Each sum criterion is a fixed 8 byte signed number (Negative value
is allowed for use like counting delta-UTXO. 8 bytes is needed for fee
commitment. Multiple smaller criteria may share a 8 byte slot, as long
as they do not allow negative value)
15. Nodes will ignore the sum criteria that they do not understand, as
long as the sum is correctly calculated
Size limit:
16. We need to determine the size limit of witness
17. We also need to have an upper limit for the number of sum criteria,
or a malicious miner may find a block with many unknown sum criteria and
feed unlimited amount of garbage to other nodes.
All other functions I mentioned in my wish list could be softforked
later to this system
To mitigate the risk described in rule 17, we may ask miners to vote for
an increase (but not decrease) in the number of sum criteria. Initially
there should be 0 sum criteria. If we would like to introduce a new
criteria, miners will support the proposal by setting the number of sum
criteria as 1. However, until 95% of miners support the increase, all
values of the extra sum criteria must be 0. Therefore, even a malicious
miner may declare any amount of sum criteria, those criteria unknown to
the network must be 0, and no extra data is needed to construct the
block. This voting mechanism could be a softfork over rule 12 and 13,
and is not necessary in the initial segwit deployment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbY0jAAoJEO6eVSA0viTSU1oMAJIrYWerwk84poZBL/ezEsIp
9fCLnFZ4lyO2ijAm5UmwLXGijY03kqp29b0zmyIWV2WuoeW2lN64tLHQRilT0+5R
n5/viQOMv0C0MYs525+/dpNkk2q2MiFmyyozdbU6zcyfdkrkYdChCFOQ9GsxzQHk
n4lL4/RSKdqJZg4x2yEGgdyKA6XrQHaFirdr/K2bhhbk4Q0SOuYjy8Wxa2oCHFCC
WG4K2NBnKCI7DuVXQK+ZC8dYXMwbemeFfPHY6dZVti7j/OFsllyxno/CFKO3rsCs
+uko4XJk6pH0Ncjrc1n0l0v9xIKF5hTqSxFs+GVvhkiBdTDZVe7CdedO9qJWf1hE
bbmLXTURCDQUFe9F3uKsnYfMoD5eniWHx2OQcJcNPlLMJd9zObB3HdgFMW6N53KN
QXLmxobU/xFhmFknz1ShGEIdGSaH0gqnb+WEkO5v5vBO4L6Cikc+lcp7zXqQzWpW
uqm3QSrbKcbR6JEwDFoGQpDkcqpwpTIrOAk4B1jJRg==
=J2KF
-----END PGP SIGNATURE-----
Gregory Maxwell 於 2015-12-10 04:51 寫到:
> On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 4. Sum of fee, sigopcount, size etc as part of the witness hash tree:
>> for
>
> I should have also commented on this: the block can indicate how many
> sum criteria there are; and then additional ones could be soft-forked
> in. Haven't tried implementing it yet, but there you go. :)
|
