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
> wrote:
>
> On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn wrote:
>>> OK, I guess we can boil this down more simply. BIP 70 uses protoc
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 wrote:
> I'm a bit confus
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 th
On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn 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 because,
>
> 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 o
-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 GMT-07:0
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 bunch
Thanks guys, great answers.
The design choice certainly makes a lot more sense now regardless of
whether one agrees with it or not.
Regards,
Richard
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 January 2015 12:09:13 GMT-07:00, Jeff Garzik 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.
Protocol buffers isn't
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 awar
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:
https://groups.google
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 m
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 wrote:
> Hi Gavin, Mike and co
>
> Is there a strong driver behind the choice of Googl
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 binar
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 wrote:
> Text formats such as XML or JSON are far less deterministic, are more
> loosely specified, have wide varia
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 reque
16 matches
Mail list logo
