None of those listed were in the context of performance. Parsing of binary
or text is quite fast these days, and is not really a consideration versus
other needs such as a predictable encoding for a single data
representation. XML and JSON both can represent the same post-evaluation
user data a
The engineers at Google were well aware that ASN.1 existed. I can assure
you of that, because I was one of them.
The protobuf FAQ has a very polite take on the matter:
https://developers.google.com/protocol-buffers/docs/faq
This email thread gives more enlightenment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 January 2015 12:09:13 GMT-07:00, Jeff Garzik jgar...@bitpay.com wrote:
Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very
hash-able,
the list goes on.
Fair points, although for me the line is blurred between which of those are
security considerations vs performance considerations.
Richard
On 19 January 2015 at 19:09, Jeff Garzik jgar...@bitpay.com wrote:
Text formats such as XML or JSON are far less deterministic, are more
loosely
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
Text formats such as XML or JSON are far less deterministic, are more
loosely specified, have wide variance in parsing, are not very hash-able,
the list goes on.
On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady rnbr...@gmail.com wrote:
Hi Gavin, Mike and co
Is there a strong driver behind the
ASN.1 is not nearly as flexible when it comes to well-supported libraries,
generators, and the ecosystem that surrounds the actual encoding. You
don't see ASN.1 compilers + language support packages for [all popular
programming languages], as you do with protobufs.
Google engineers were well
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
For what it's worth, there was consideration of replacing protocol
buffers when modifying BIP70 to function with the altcoin I work on
(changes were required anyway in eliminate any risk that payment
requests could not be accidentally applied to the wrong blockchain). The
eventual conclusion was
Correct. I should have said more likely to be deterministic Bitcoin
Core does not *rely* on determinism in BIP70; I was referring to recent
upstream efforts to make protobufs usable in a deterministic fashion by
default.
On Mon, Jan 19, 2015 at 3:03 PM, Alan Reiner etothe...@gmail.com wrote:
Damn if SPKI had won out we would be parsing S-expressions instead of X.509
certificates. ASN.1 is not fun IMHO.
On Jan 19, 2015, at 3:56 PM, Gavin Andresen ga...@bitcoinfoundation.org
wrote:
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn m...@plan99.net wrote:
OK, I guess we can boil this
I'm a bit confused. It's been a long time since I looked at protobuf
(and will have to dig into it soon), but I seem to recall it doesn't
have any of the determinism properties you guys just said. It is
intended to allow you to skip details of the on-the-wire representations
and just send a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
That's 100% true: BIP70 passes around serialized protobuf data that it signs
directly for this reason; it could just as easily be a byte array with json in
it. (not that json/XML/etc. doesn't have other flaws)
On 19 January 2015 13:03:32
I'm a bit confused. It's been a long time since I looked at protobuf (and
will have to dig into it soon), but I seem to recall it doesn't have any of
the determinism properties you guys just said.
It's not guaranteed no, which is why we store signed sub-messages as byte
arrays instead of
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn m...@plan99.net wrote:
OK, I guess we can boil this down more simply. BIP 70 uses protocol
buffers because I designed it and implemented the original prototype (with
lots of input from Gavin and an earlier proposal by sipa). I used protocol
buffers
15 matches
Mail list logo
