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
|
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 85F3389F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Sep 2016 21:32:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (unknown [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0B5AD1BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Sep 2016 21:32:43 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 0E72A38AB7F6;
Tue, 20 Sep 2016 21:31:51 +0000 (UTC)
X-Hashcash: 1:25:160920:bitcoin-dev@lists.linuxfoundation.org::ioIbQ6sQV19TyKtS:hb0sK
X-Hashcash: 1:25:160920:tomz@freedommail.ch::eq3+HKtKj6j8KNVz:CIPX
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Tom <tomz@freedommail.ch>
Date: Tue, 20 Sep 2016 21:31:47 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; )
References: <7844645.RLYLWYmWtM@garp>
In-Reply-To: <7844645.RLYLWYmWtM@garp>
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="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201609202131.49881.luke@dashjr.org>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
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: Tue, 20 Sep 2016 21:32:44 -0000
On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote:
> As the title suggests, I would like to formally request the assignment of a
> BIP number for my FT spec.
Please open a pull request on the bitcoin/bips repo after this has been
discussed a bit on the ML.
Note that at least a basic backwards compatibility section is required for
assignment, especially since this appears to be a hard-fork proposal (if it is
meant as a soft-fork, please explain how that would work).
> ==Motivation==
>
> Token based file-formats are not new, systems like XML and HTMl use a
> similar system to allow future growth and they have been quite successful
> for decades in part because of this property.
There is already a binary-safe format called EBML. Why not use that as the
basis for this BIP?
> Next to that this protocol upgrade will re-order the data-fields which
> allows us to cleanly fix the malleability issue which means that future
> technologies like Lightning Network will depend on this BIP being deployed.
Note this won't fix malleability entirely, only third-party malleability (much
like segwit). The sender can always modify the transaction with more
inputs/outputs.
> |TxEnd || 0 ||BoolTrue || Required ||A marker that is the last
> byte in the txid calculation
The last byte in the txid calculation, or the last byte of the entire
transaction?
It seems from the later comments, that it is the end of the transaction as a
whole. Yet a separator between the txid and non-txid data would probably be
valuable, rather than hard-coding txid to skip signature types (which may be
unknown to old nodes, when extended).
> The OP_CHECKSIG is the most well known and, as its name implies, it
> validates a signature.
> In the new version of 'script' (version 2) the data that is signed is
> changed to be equivalent to the transaction-id. This is a massive
> simplification and also the only change between version 1 and version 2 of
> script.
This seems to be a major regression. What is the replacement for
SIGHASH_SINGLE and SIGHASH_ANYONECANPAY?
When revising OP_CHECKSIG, it would also be nice to add the ability to use
*only* a hash of the prevout's scriptPubKey in the input, so that *when* the
prevtx is malleated, the spending one remains valid. (This use case is
currently not supported.)
> === Serialization order===
>
> The tokens defined above have to be serialized in a certain order for the
> transaction to be well-formatted. Not serializing transactions in the
> order specified would allow multiple interpretations of the data which
> can't be allowed.
What happens if nodes encounter a different order in a block?
> Notice that the token ScriptVersion is currently not allowed because we
> don't have any valid value to give it. But if we introduce a new script
> version it would be placed in the outputs segment.
What happens if I put ScriptVersion=1 here?
> === Script v2 ===
>
> TODO: does check-multisig need its own mention?
Does multisig still require a dummy item on the stack?
> === Block-malleability ===
>
> For this reason the merkle tree is extended to include (append) the hash of
> the v4 transactions (and those alone) where the hash is taken over a
> data-blob that is build up from:
How should nodes know where in the merkle-tree the txids end, and the v4hashes
begin?
Luke
|
