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
|
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 250B2412
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 01:13:38 +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 92AFF4D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 01:13:37 +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 68D6038A0076
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 01:13:31 +0000 (UTC)
X-Hashcash: 1:25:171001:bitcoin-dev@lists.linuxfoundation.org::TqWu5iFWvCJ48hCF:ZJnn
From: Luke Dashjr <luke@dashjr.org>
To: "bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 1 Oct 2017 01:13:29 +0000
User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; )
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="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201710010113.30518.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
Subject: [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 01:13:38 -0000
I've put together a first draft for what I hope to be a good next step for
Segwit and Bitcoin scripting:
https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
This introduces 5 key changes:
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.
The remaining two are witness version 1.0 (major 1, minor 0):
2. As previously discussed, undefined opcodes immediately cause the script to
exit with success, making future opcode softforks a lot more flexible.
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)
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).
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.
This last part is a big ugly right now: the signature must commit to the
script interpreter flags and internal "sigversion", which basically serve 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?
There is also draft code implementing [the consensus side of] this:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
Thoughts? Anything I've overlooked / left missing that would be
uncontroversial and desirable? (Is any of this unexpectedly controversial for
some reason?)
Luke
|
