<unnamed>

Public Key

npub1yex0huuw9mg3lksxwszh2q7v9rh52kfnprsjvg7wdlp202h2wlqsenmnxv

Profile Code

nprofile1qqszvn8m7w8za5glmgr8gpt4q0xz3m69tyes3cfxy08xls484t480sgpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc6ek4yl

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:28:39 UTC

- reply

📅 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>

2023-06-07 15:28:36 UTC

- reply

📅 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>

2023-06-07 15:28:35 UTC

- reply

📅 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>