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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7BF3A82
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 02:47:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9E5F020C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 02:47:51 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 6D49038A0072;
Sun, 1 Oct 2017 02:47:47 +0000 (UTC)
X-Hashcash: 1:25:171001:mark@friedenbach.org::M+bzBV30sGTRGNdj:yG6Z
X-Hashcash: 1:25:171001:bitcoin-dev@lists.linuxfoundation.org::xb/=9fTaJHOAj772:dZW
From: Luke Dashjr <luke@dashjr.org>
To: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 1 Oct 2017 02:47:41 +0000
User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; )
References: <201710010113.30518.luke@dashjr.org>
<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
In-Reply-To: <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201710010247.42180.luke@dashjr.org>
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,
RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
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: Sun, 01 Oct 2017 02:47:52 -0000
Should it perhaps commit to the length of the serialised witness data inste=
ad=20
or additionally? Now that signatures are no longer variable-length, that'd =
be=20
possible...
As far as tail-call needs are concerned, CLEANSTACK wouldn't have been chec=
ked=20
until AFTER the tail-call in the first draft. But I suppose eliminating it =
for=20
other possible future purposes is still useful.
Luke
On Sunday 01 October 2017 2:23:47 AM Mark Friedenbach wrote:
> The CLEANSTACK rule should be eliminated, and instead the number of items
> on the stack should be incorporated into the signature hash. That way any
> script with a CHECKSIG is protected from witness extension malleability,
> and those rare ones that do not use signature operations can have a =E2=
=80=9CDEPTH
> 1 EQUALVERIFY=E2=80=9D at the end. This allows for much simpler tail-call
> evaluation as you don=E2=80=99t need to pass arguments on the alt-stack.
>=20
> > On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >=20
> > I've put together a first draft for what I hope to be a good next step
> > for
> >=20
> > Segwit and Bitcoin scripting:
> > https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawi=
ki
> >=20
> > This introduces 5 key changes:
> >=20
> > 1. Minor versions for witnesses, inside the witness itself. Essentially
> > the witness [major] version 1 simply indicates the witness commitment is
> > SHA256d, and nothing more.
> >=20
> > The remaining two are witness version 1.0 (major 1, minor 0):
> >=20
> > 2. As previously discussed, undefined opcodes immediately cause the
> > script to exit with success, making future opcode softforks a lot more
> > flexible.
> >=20
> > 3. If the final stack element is not exactly true or false, it is
> > interpreted as a tail-call Script and executed. (Credit to Mark
> > Friedenbach)
> >=20
> > 4. A new shorter fixed-length signature format, eliminating the need to
> > guess the signature size in advance. All signatures are 65 bytes, unless
> > a condition script is included (see #5).
> >=20
> > 5. The ability for signatures to commit to additional conditions,
> > expressed in the form of a serialized Script in the signature itself.
> > This would be useful in combination with OP_CHECKBLOCKATHEIGHT (BIP
> > 115), hopefully ending the whole replay protection argument by
> > introducing it early to Bitcoin before any further splits.
> >=20
> > This last part is a big ugly right now: the signature must commit to the
> > script interpreter flags and internal "sigversion", which basically ser=
ve
> > the same purpose. The reason for this, is that otherwise someone could
> > move the signature to a different context in an attempt to exploit
> > differences in the various Script interpretation modes. I don't consider
> > the BIP deployable without this getting resolved, but I'm not sure what
> > the best approach would be. Maybe it should be replaced with a witness
> > [major] version and witness stack?
> >=20
> > There is also draft code implementing [the consensus side of] this:
> > https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
> >=20
> > Thoughts? Anything I've overlooked / left missing that would be
> > uncontroversial and desirable? (Is any of this unexpectedly controversi=
al
> > for some reason?)
> >=20
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
