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
162
|
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 D9A05B65
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Oct 2017 20:33:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2353FA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Oct 2017 20:33:58 +0000 (UTC)
Received: by mail-pg0-f48.google.com with SMTP id p5so8840319pgn.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Oct 2017 13:33:58 -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=36txL3dRC/HZ/jS7rJvWHUoAWMfyDuMutmeascNUzqI=;
b=PFSxpozCbCEWfFmf4oP9ozw8WogxBHw0rIqMFMwvKbcTqR2qsSJ8DjUyYXZEmELpuc
WlBBP8md2zvDt5sovBsGkzPy2DgZCM2zEM9kt87MrxWz4VMFHgSyHpiBGbR6AuMwiwyu
Aygerw5rb/SFaj2deaDDKa1Rw5Cak8JnwwYLcuiVNvyRLw4tTqayh7TeTT9pqIZ6arXM
bi/YmFsxdqmop0DzD48e12xVj0oVEoWzHgIX0vXVahRbgTVs21qoSFAdntkWwU9lAswe
R7ygLf9lftgmy56H1wA0fE1P5MmijiUjQBB70c92LEDL6F0NYPyM+hq0I13YQBQXO6Ys
9A7Q==
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=36txL3dRC/HZ/jS7rJvWHUoAWMfyDuMutmeascNUzqI=;
b=W24RM9yJoyj26z563wdkrOr8CmtQiMeXjwJoHHtek3yo5FI1rwLZW4TTWid8cNHsE2
VnLMSA2bheXFx709Az0zcFAfqEQIWNjreFVqz3zxHk6WvqNlR0YOM3joKtl8mJdGoxlr
4Z/bHvbOBP+anNY0lzhJ4weDtgxxbtpUSjoO6X7tvEO707ECqgLw7LPHYT77Lj/VVfd/
XuxbldHJYhc1NEO7JKbHu1pZMIphT2G7tctXsVzbSC/M7iPdiQZ9fm+0hwRhmOATf/vY
0r3ZIjXozlLruRejnnqmtp02pB1Q1+gpiq/aBPBA8nXm+l19kUpFi2xL1WIb4/2BHfD9
Fxow==
X-Gm-Message-State: AMCzsaWu8w4p2Xw3l8i7b3DEbIk2HWkur64ix2hx+D5uAoRNS9U5ghKt
AQ+kPlkJU6wI+QQ+toqKwzL1AnttYVE=
X-Google-Smtp-Source: AOwi7QDQLBEdiE1p3feJ1QM8xtmiEiB5hgWyxIEVKXem6NkiAh8MTPKDOeUoznBjdjMqmqJJ8acP+Q==
X-Received: by 10.99.123.88 with SMTP id k24mr11138081pgn.213.1507235638483;
Thu, 05 Oct 2017 13:33:58 -0700 (PDT)
Received: from [10.1.10.181] (c-73-189-35-88.hsd1.ca.comcast.net.
[73.189.35.88]) by smtp.gmail.com with ESMTPSA id
j186sm32493587pfg.164.2017.10.05.13.33.57
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 05 Oct 2017 13:33:57 -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 11.0 \(3445.1.6\))
Date: Thu, 5 Oct 2017 13:33:56 -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: <AEABDAC5-AAFB-4345-BD0D-4F61CA075A1C@friedenbach.org>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Thu, 05 Oct 2017 20:34:00 -0000
Here=E2=80=99s an additional (uncontroversial?) idea due to Russell =
O=E2=80=99Connor:
Instead of requiring that the last item popped off the stack in a =
CHECKMULTISIG be zero, have it instead be required that it is a bitfield =
specifying which pubkeys are used, or more likely the complement =
thereof. This allows signatures to be matched to pubkeys in the order =
given, and batch validated, with no risk of 3rd party malleability.
Mark
> 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
|
