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
|
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 47105D96
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 18:41:46 +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 A19AE183
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 18:41:45 +0000 (UTC)
Received: from localhost ([::1]:57363 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1a8Baa-002x1D-6R; Sun, 13 Dec 2015 13:41:44 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 13 Dec 2015 13:41:44 -0500
From: jl2012@xbt.hk
To: Pieter Wuille <pieter.wuille@gmail.com>
In-Reply-To: <CAPg+sBia_rCNkPfKhKxDiOaun5zRKj9LVRkGf_YqVvYWiTox1A@mail.gmail.com>
References: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
<CAAS2fgT09Tk+5dBQ4YJA_pwK56xX2mEQe9TkJqgcB0j2BZZJ1g@mail.gmail.com>
<2498d6a0691fde6f62453294da6118d0@xbt.hk>
<CAPg+sBia_rCNkPfKhKxDiOaun5zRKj9LVRkGf_YqVvYWiTox1A@mail.gmail.com>
Message-ID: <a46f4277e8859affba4e5cfe5474d53a@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 20:30:01 +0000
Cc: Gregory Maxwell <gmaxwell@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 18:41:46 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Pieter Wuille 2015-12-13 13:07 :
> The use of a NOP opcode to indicate a witness script was something I
> considered at first too, but it's not really needed. You wouldn't be
> able to use that opcode in any place a normal opcode could occur, as
> it needs to be able to inspect the full scriptSig (rather than just
> its resulting stack) anyway. So both in practice and conceptually it
> is only really working as a template that gets assigned a special
> meaning (like P2SH did). We don't need an opcode for that, and instead
> we could say that any scriptPubKey (or redeemscript) that consists of
> a single push is a witness program.
>
>> 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
>
> What is that good for?
Just to make sure a script like OP_0 OP_SEGWIT will fail.
Anyway, your design may be better so forget it
>> 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)
>
> Do you mean the scriptPubKey itself, or the script that follows after
> the version byte?
> * The scriptPubKey itself: that's in contradiction with your rule 4,
> as segwit scripts are by definition only a push (+ opcode), so they
> can't be an OP_RETURN.
> * The script after the version byte: agree - though it doesn't
> actually need to be a script at all even (see further).
I am not referring to the serialized script, but the witness. Basically,
it doesn't care what the content look like.
> It is useful however to allow segwit inside P2SH
Agree
> So let me summarize by giving an equivalent to your list above,
> reflecting how my current prototype works:
> A) A scriptPubKey or P2SH redeemscript that consists of a single push
> of 2 to 41 bytes gets a new special meaning, and the byte vector
> pushed by it is called the witness program.
Why 41 bytes? Do you expect all witness program to be P2SH-like?
> The program
> must not fail and result in a single TRUE on the stack, and nothing
> else (to prevent stuffing the witness with pointless data during relay
> of transactions).
Could we just implement this as standardness rule? It is always possible
to stuff the scriptSig with pointless data so I don't think it's a new
attack vector. What if we want to include the height and tx index of
the input for compact fraud proof? Such fraud proof should not be an
opt-in function and not be dependent on the version byte
For the same reason, we should also allow traditional tx to have data
in the witness field, for any potential softfork upgrade
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCAAGBQJWbbugAAoJEO6eVSA0viTSD8oMAKFvd/+KZgH13tErEA+iXzF5
pwT4/eoQWSTvxIDVrFN+9wV79ogO4/aiCDEdmNF2IZD3QqmhKl7iOPw2SEseRTbe
e1r5z67yuudXyEQocZvy5+NOUp3N978b8weuRsHWG1HXgxTRmgZTrEeNtbEUs0X2
n5l6e0scnZAu70svBXr8X9HnOm2P/QLxtAqyNW19caCi+Dg/4Curx48tXQ/I9IxT
SYFVzB++FIoua49Cf1RJN+dUfywg67wT5l9NX4uWAX0qNB+p6BPP8df/72G/u564
NIaJs3IFiUaNktXz9aDM4s7pSzR6PlCK6LFKjE52sBY5uREHGU4PnfX9YqtwiEXA
Hr3YoFiepxAwl6icJi3wHKa6i0NGvj1fR1h6xuJ7ulzNv5mwuzXPOgvTDK4wpejl
ee8wsQZwmzchAfgyfPsgSaPh/jjBwm2S+WDMbL4HDmnWqVDl8dG3I/b3XP0aegY9
4RxPhLOA1qToNDGhnm+JNqT60OKgatpDN/4bRgRscA==
=4B1D
-----END PGP SIGNATURE-----
|
