Nostr notes by

📅 Original date posted:2015-01-19 📝 Original message:Fair ...

2023-06-07T15:28:39Z

In reply to nevent1q…jjrd
_________________________

📅 Original date posted:2015-01-19
📝 Original message: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 <jgarzik at 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.
>
>
> On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <rnbrady at gmail.com> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/edf3572c/attachment.html>;

📅 Original date posted:2015-01-19 📝 Original message:Thanks ...

2023-06-07T15:28:36Z

In reply to nevent1q…ym6g
_________________________

📅 Original date posted:2015-01-19
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/3e66c433/attachment.html>;

📅 Original date posted:2015-01-19 📝 Original message:Hi ...

2023-06-07T15:28:35Z

In reply to nevent1q…6knr
_________________________

📅 Original date posted:2015-01-19
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/6edaa8fd/attachment.html>;