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
|
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 F17A9B02
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 08:56:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2472A135
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 08:56:40 +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-out03.mykolab.com (Postfix) with ESMTPS id E312A237DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 10:56:32 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Thu, 22 Sep 2016 10:56:31 +0200
Message-ID: <1988067.b5KirJFSKj@garp>
In-Reply-To: <CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
References: <7844645.RLYLWYmWtM@garp>
<CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
<CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
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: Thu, 22 Sep 2016 09:13:33 +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: Thu, 22 Sep 2016 08:56:41 -0000
On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
>
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > BIP number for my FT spec.
>
> This document does not appear to be concretely specified enough to
> review or implement from it.
>
> For example, it does not specify the serialization of "integer"
It refers to the external specification which is linked at the bottom.
In that spec you'll see that "Integer" is the standard var-int that Bitcoin
has used for years.
> nor does it specify how the
> presence of the optional fields are signaled
How does one signals an optional field except of in the spec? Thats the job of
a specification.
> nor the cardinality of
> the inputs or outputs.
Did you miss this in the 3rd table ? I suggest clicking on the github bips
repo link as tables are not easy to read in mediawiki plain format that the
email contained.
> For clearly variable length elements
> ('bytearray') no mention is made of their length encoding. etc.
Also in the external CMF spec.
> Without information like this, I don't see how someone could
> realistically begin reviewing this proposal.
I agree, that would be bad. Luckily that you just missed the link :)
Here it is;
https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md
> The motivation seems unclear to me as well: The scheme is described as
> 'flexible' but it appears to remove flexibility from the existing
> system. The "schema" appears to be hardcoded and never communicated.
Being hardcoded and never communicated is what the current format does to. How
does that "remove flexibility".
Also read my reply to Peter Todd on why this is flexible.
> If the goal is to simply have {snip}
It is not.
Thanks for asking, I understand that the CMF spec is useful to see as well.
Hopefully you can now review it properly since I linked to it above.
Cheers!
|
