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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1YDHrj-0007Wj-QX
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 19:19:59 +0000
X-ACL-Warn:
Received: from resqmta-ch2-04v.sys.comcast.net ([69.252.207.36])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1YDHri-00076D-5J
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 19:19:59 +0000
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116])
by resqmta-ch2-04v.sys.comcast.net with comcast
id hvJy1p0062XD5SV01vKslC; Mon, 19 Jan 2015 19:19:52 +0000
Received: from crushinator.localnet
([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6])
by resomta-ch2-20v.sys.comcast.net with comcast
id hvKr1p0062JF60R01vKs6f; Mon, 19 Jan 2015 19:19:52 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-development@lists.sourceforge.net
Date: Mon, 19 Jan 2015 14:19:50 -0500
Message-ID: <2109963.TWzmcrtnFv@crushinator>
User-Agent: KMail/4.14.3 (Linux/3.16.5-gentoo; KDE/4.14.3; x86_64; ; )
In-Reply-To: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
References: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [69.252.207.36 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YDHri-00076D-5J
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
encoding?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 19:20:00 -0000
Even if a compact binary encoding is a high priority, there are more "standard" choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema. In practice, I'm mostly agnostic about what encoding is actually used in BIP70, and I wouldn't fault BIP70 for choosing Google Protocol Buffers, but the very existence of Protobuf perplexes me, as it apparently re-solves a problem that was solved 40 years ago by ASN.1. It's as though the engineers at Google weren't aware that ASN.1 existed.
On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:
> Hi Gavin, Mike and co
>
> Is there a strong driver behind the choice of Google Protocol Buffers for
> payment request encoding in BIP-0070?
>
> Performance doesn't feel that relevant when you think that:
> 1. Payment requests are not broadcast, this is a request / response flow,
> much more akin to a web request.
> 2. One would be cramming this data into a binary format just so you can
> then attach it to a no-so-binary format such as HTTP.
>
> Some great things about protocols/encodings such as HTTP/JSON/XML are:
> 1. They are human readable on-the-wire. No Wireshark plugin required,
> tcpdump or ngrep will do.
> 2. There are tons of great open source libraries and API for parsing /
> manipulating / generating.
> 3. It's really easy to hand-craft a test message for debugging.
> 4. The standards are much easier to read and write. They don't need to
> contain code like BIP-0070 currently does and they can contain examples,
> which BIP70 does not.
> 5. They are thoroughly specified by independent standards bodies such as
> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
> 6. They're a family ;-)
>
> Keen to hear your thoughts on this and very keen to watch the payment
> protocol grow regardless of encoding choice! My background is SIP / VoIP
> and I think that could be a fascinating use case for this protocol which
> I'm hoping to do some work on.
>
> Best,
> Richard
|
