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 6BC5997
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 18:34:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com
[209.85.192.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DCC7E3D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 18:34:09 +0000 (UTC)
Received: by mail-pf0-f169.google.com with SMTP id p87so1918787pfj.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Oct 2017 11:34:09 -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=UAv1FDDXjNcP+XEOq14057pu+fwfJgFDUq7kkOMFo0I=;
b=JWapo2X6dFBsYpt4tZNdirqjp+/1sJ6Wt7Uao7lZgNY4ZDiY8xViaWYFrXKRXN+eQT
AGv3EdqAdiOky65zAdjA/IAwD4Ku6KRzYC6IeQIvtH1Ma1jB8G/IWerdbQ7Uth9jcSKH
lBNVY4zMZrIjcYFaObtjSKiKPT0CHZjESDHLxXjURQGSRfASoYGPoIKCQYrjycxqHEfI
1Wc8pNJJdosKVyNKJAABZlQAk2CRTAQ9T0TNiAzC69OXp8HvcpHffAtHzJ+a2BEYaKf0
EvnVSj2gG6qhfHwHCdVSJVgq2ecyktnS+mb99oELI9XHrZlAwgBIc9n2hQXzA0YFzKUl
gbVA==
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=UAv1FDDXjNcP+XEOq14057pu+fwfJgFDUq7kkOMFo0I=;
b=m0xuqn9iFYzBpjZ9Y3qgP2FRQTwf775qLa/TEm+5XDuoh4SuyScDrWCf1/VG73t8C8
Ms/kOihbsJasfaIDuZHR9aVCvqxn/Ap1Cf2GWy+jNZP6tjbm+FqOgQLRwb/b5Gk4sHri
vyLXKnsIWAAOHawY0kkqo6h4MKqfJmZpYYSIH3f25SKJ5EYAXX4oGIJIdvBJp38fkfza
tuDva5bf9EIEJFLpXOwZYny1A43sgqRUsWhKXT4yUKe+IDIlUlVL6i0RK3KGQFj4vqof
7k4iVWitJa41omGCFtAHB9Q0fyyynYukLSpjfEkPcszaBcN8A5lU3pgxFN3rm2kQZd8M
Y0qg==
X-Gm-Message-State: AMCzsaXgv4P/DMDMKzMYei88VbLxGzlLc8NdycVChaCV4AlwTlfSJqws
9Gf7tXCE9sevyxz1MJH0KqtN44fAb4k=
X-Google-Smtp-Source: AOwi7QAqQzPttBHgmPFfL51Tf85JqjQVB5IYgiiB3ZACqFxfgvM/wbago6ecjC74m963+3kqIifFCA==
X-Received: by 10.84.229.68 with SMTP id d4mr1595702pln.397.1506882849419;
Sun, 01 Oct 2017 11:34:09 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:39e7:3724:6f96:6f4b?
([2601:646:8080:1291:39e7:3724:6f96:6f4b])
by smtp.gmail.com with ESMTPSA id
y1sm14523724pgp.15.2017.10.01.11.34.07
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 01 Oct 2017 11:34:08 -0700 (PDT)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Sun, 1 Oct 2017 11:34:07 -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: <089161B1-9AD6-45A2-BE0A-215FECC19510@friedenbach.org>
X-Mailer: Apple Mail (2.3445.1.6)
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
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 18:34:12 -0000
I would also suggest that the 520 byte push limitation be removed for v1 =
scripts as well. MERKLEBRANCHVERIFY in particular could benefit from =
larger proof sizes. To do so safely would require reworking script =
internals to use indirect pointers and reference counting for items on =
stack, but this is worth doing generally, and introducing a per-input =
hashing limit equal to a small multiple of the witness size (or =
retaining the opcount limit).
> 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
|
