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
158
159
160
161
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E61F3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 02:23:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com
[209.85.192.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7779DE1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 02:23:49 +0000 (UTC)
Received: by mail-pf0-f180.google.com with SMTP id x78so1436765pff.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Sep 2017 19:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:mime-version:subject:date:references
:to:in-reply-to:message-id;
bh=O1I0KVOwBun76c7Xyn1CZtfV3MV/haXbqrsiRUR0Jag=;
b=PB81DyEHt5hwsAnPjKMPRvBTJhZ80kBqonUMydYFbNBmhKRUJKk5pw6b4sf26yzH00
22Wn5itVDnaeQJ0KzPNcRMt34QtSxsRLng0PB+Lgjqp5W6wjhfoyTvdi3uunpV0y4io7
42hXWEdi7cFZLdNPskqZxbZUW0LKuamZkZbuhy8sOMsSjDpmCPBnVXAulAyezzJQV1Ey
qpC/gj5cevFW8iGADDTeUhhX5rxfCD1lkUvIzI1CHZDQMypN4e8D8Bldga1pfhW5R4QK
8CT2OomHI6kq5+SxyPV6kCYheEQMuIEOjcFXcDBzwxu8fkV8lSkR3UCF1yI/Hs8yOmyA
f28A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version
:subject:date:references:to:in-reply-to:message-id;
bh=O1I0KVOwBun76c7Xyn1CZtfV3MV/haXbqrsiRUR0Jag=;
b=L1Dt1wDgznvJQ9T1pMtuMnpl8LCCl8dHbIOk+4oFVry5pYrSCjefub6ng3fI2VxMoR
QnDNWxRTIklouv/WsJ8YiMSnHqnkyyTNZ4/0WOlNSSMFUnxKkCQimDnBNzqK+ICuRJCo
H6YccvdJEVlJNctyYahVY2rIamgU3upY0J9GZVgMV0okmnj6slkw80gjBTdqUMAzmCGT
FF5yiWmFI6j2/t9KZksKYFOdCOds2mzR66D5x+8kBXmA+AC2hIgoKKihHNfgXCVBVPuT
SPKx9ONB/8rohGbjRitTBo80j5d+OFwHJ8BgYWV6d7PLrybofCnqd/zl7ocNqw9PITHG
fPhA==
X-Gm-Message-State: AHPjjUgBA9nF1GjKTNp6nsO3QYRbdfQptsOXPCB6sSCPW2K9tXpY6kZX
dRME3Jj2Rb8uBKNTYGdoHp/+wGlJyIw=
X-Google-Smtp-Source: AOwi7QDb4itEy+HOgnNvr84iUFHC0iD8dXdbucpmnfYanefvOGprA7WhPzEGh9K4W5PSS3PDoE5Xbg==
X-Received: by 10.98.32.92 with SMTP id g89mr11394817pfg.285.1506824628889;
Sat, 30 Sep 2017 19:23:48 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:99eb:536:2ab0:7fc6?
([2601:646:8080:1291:99eb:536:2ab0:7fc6])
by smtp.gmail.com with ESMTPSA id
j83sm13739648pfe.133.2017.09.30.19.23.47
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 30 Sep 2017 19:23:47 -0700 (PDT)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 30 Sep 2017 19:23:47 -0700
References: <201710010113.30518.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201710010113.30518.luke@dashjr.org>
Message-Id: <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled 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, 01 Oct 2017 02:28:03 +0000
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:23:50 -0000
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.
> 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.mediawiki
>=20
> This introduces 5 key changes:
>=20
> 1. Minor versions for witnesses, inside the witness itself. =
Essentially the=20
> witness [major] version 1 simply indicates the witness commitment is =
SHA256d,=20
> 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=20
> 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=20
> 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=20
> the signature size in advance. All signatures are 65 bytes, unless a =
condition=20
> script is included (see #5).
>=20
> 5. The ability for signatures to commit to additional conditions, =
expressed in=20
> the form of a serialized Script in the signature itself. This would be =
useful=20
> in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending =
the=20
> whole replay protection argument by introducing it early to Bitcoin =
before any=20
> further splits.
>=20
> This last part is a big ugly right now: the signature must commit to =
the=20
> script interpreter flags and internal "sigversion", which basically =
serve the=20
> same purpose. The reason for this, is that otherwise someone could =
move the=20
> signature to a different context in an attempt to exploit differences =
in the=20
> various Script interpretation modes. I don't consider the BIP =
deployable=20
> without this getting resolved, but I'm not sure what the best approach =
would=20
> be. Maybe it should be replaced with a witness [major] version and =
witness=20
> 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=20
> uncontroversial and desirable? (Is any of this unexpectedly =
controversial for=20
> some reason?)
>=20
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
