๐
Original date posted:2015-01-19
๐ Original message: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 that while we might have used JSON or XML if we
were starting from scratch, there's no choice that's clearly better.
While deployed infrastructure for payment protocol is still quite
limited, it seems that the cost to replace at this point is higher than not.
If there's ever a major reworking of the standard, for example to handle
recurring payments, it's probably worth thinking about then, but
protocol buffers result in a compact data format which is supported by
most major languages (and size is a concern if dealing with Bluetooth or
NFC), and has no major drawbacks I am aware of.
Ross
On 19/01/2015 20:40, Mike Hearn wrote:
>> 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 typed submessages. In practice though, most
> implementations do seem to serialise things the same way. I recall Python
> used to be an odd one out, unsure if it still is.
>
> 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, beyond all their nice properties, I used to work at Google and so
> was very familiar with them.
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/c508d0e9/attachment.html>