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
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1B22794E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2016 09:32:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E4D03139
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2016 09:32:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102])
by mx-out01.mykolab.com (Postfix) with ESMTPS id 508556161E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2016 11:32:32 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Wed, 21 Sep 2016 11:32:30 +0200
Message-ID: <2219026.Mlk68OiSLi@garp>
In-Reply-To: <201609202131.49881.luke@dashjr.org>
References: <7844645.RLYLWYmWtM@garp> <201609202131.49881.luke@dashjr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 21 Sep 2016 11:10:52 +0000
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: Wed, 21 Sep 2016 09:32:36 -0000
On Tuesday 20 Sep 2016 21:31:47 Luke Dashjr wrote:
> 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.
> 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?
How is this a regression? Can you explain what functionality is lost please?
> 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.)
Maybe for the next version of script :)
> > Notice that the token ScriptVersion is currently not allowed
> What happens if I put ScriptVersion=1 here?
The transaction is invalid...
> > === 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?
Because the txid based ones are not going away. So the number of transactions
in the block can be used to determine when the pure tx-id segment stops and
when the v4 hashes begin. Then its up to the client to rebuild the tree from
that list based on the larger input set to get the same root-node.
I clarified many little things on my clone of the bips, check there if you
want to see the details.
|
