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
|
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 9E6AB94A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2016 12:58:08 +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 E2E8524C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Sep 2016 12:58:07 +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 00C7A2415F;
Wed, 21 Sep 2016 14:58:04 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org,
Andreas Schildbach <andreas@schildbach.de>
Date: Wed, 21 Sep 2016 14:58:02 +0200
Message-ID: <58983644.DvMMf90VdX@garp>
In-Reply-To: <nrtsok$lp5$1@blaine.gmane.org>
References: <7844645.RLYLWYmWtM@garp> <nrtsok$lp5$1@blaine.gmane.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 14:23:48 +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 12:58:08 -0000
On Wednesday 21 Sep 2016 14:00:23 Andreas Schildbach via bitcoin-dev wrote:
> Just glancing over your BIP, I wonder if we should use Protobuf. It uses
> this "flexible" format already and is quite compact/binary. We use
> Protobuf already for the payment protocol, and there is very good tool
> support.
There is a lot of overlap between different binary formats. Looking through
the on-the-wire protocol you'll see that my spec is very similar. Practically
all the advantages of protobuf are present in CMF. I can write you a java
parser if you want, it should be easy to port from Qt/C++ code :)
https://github.com/bitcoinclassic/transactions
CMF:
https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md
There is no tool support needed, just one or two classes. Which personally I
think is an advantage.
Some advantages of CMF over protobuf from the top of my head;
* It reuses the var-int parsing that Bitcoin uses (which is itself slightly
different from others).
* zero-copy support (not relevant for this bip, though).
* Additional values addition (i.e. adding new data) is .. tricky in protobuf.
https://developers.google.com/protocol-buffers/docs/proto#updating
* In my experience parsing a message manually (like a SOX parser) is much
better in reporting errors and detecting wrong usages than auto-generated code
(but personally I'm not much a fan of auto-generated APIs) at all...
* Generated parsing/writing code will not be as fast as we can make it.
* CMF is more compact (uses less bytes) for its messages.
Protobuf is something I've used before and I think we can do better. I think
that CMF together with some support classes can do this better.
|
