Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

[Nicolas DORIER <nicolas.dorier@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

My point is not that there is a limitation in BIP70. My point is that you
put the burden of certificate verification on developer's shoulder when we
can just leverage built in HTTPS support of the platform.
This make cross plateform dev a nightmare.

Sure I can use a snapshot of moz/apple/msft store. I depends on
BouncyCastle, as bitcoinj, so I theorically can use that way.
However, if you want to use your plateform's store, then you are toasted,
and the code for converting from BC X509 Certificate to one of each
plateform is not obvious and is a headache. Thing that could be just left
to the HTTPS support of your plateform.

Have you tried to do that on windows RT and IOS ? I tried, and I quickly
stopped doing that since it is not worth the effort. (Frankly I am not even
sure you can on win rt, since the API is a stripped down version of windows)

Why have you not heard about the problem ? (until now, because I have this
problem because I need to have the same codebase on
winrt/win/android/ios/tablets)
Because bitcoinj just rely either java's own abstraction of certificate or
on BC one. But I highly doubt they are using the plateform store, and even
if you theorically can, dealing with X509 is very prone to error... for
something that the plateform should just do for you.
Also, you bundle mozilla's store in bitcoinj, what happen when the store
change and your customer have not intent to use bitcoinj new version ? by
leveraging the plateform you benefit from automatic updates.
Also, does java stores deals with certificate revocations ? sure you can
theorically code that too... or just let the plateform deals with it.

BIP70 does not limit to anything but it is a gigantic pain in the ass for
easy cross development because of protobuff and embedded certificates.
BIP70 is a client side technology, not a performance and storage critical
data structure.

The only valid point of having embedded certificates is to allow the owner
of the website to be different from the merchant. But since merchants often
have their own website, a protocol without having to reinvent x509 would
have been better suited to current needs.

2015-01-28 16:42 GMT+01:00 Mike Hearn <mike@plan99.net>:

> On the other hand, if you charge the developer (and not the plateform) to
>> check certificate validity, it means that you have to develop a different
>> codebase for all plateform you are targeting, because each plateform store
>> trusted root certificate in a different manner with different APIs, and
>> also have different types representing a X509 Certificate.
>>
>
> That's what cross-platform abstraction libraries are for. Both Java and Qt
> provide a key store library that can load from either the OS root store or
> a custom one. If your chosen app platform doesn't, OK, then you'll have to
> make or find one yourself. Perhaps contribute it upstream or make it a
> library. But that's not a limitation of BIP70.
>
> Just as a reminder, there is no obligation to use the OS root store. You
> can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
> etc stores and load it in your app. We do this in bitcoinj by default to
> avoid cases where BIP70 requests work on some platforms and not others,
> although the developer can easily override this and use the OS root store
> instead.
>
> Of all possible solutions, using a third party service to convert things
> to JSON is one of the least obvious and highest effort. I don't know anyone
> else who arrived at such a conclusion and respectfully disagree that this
> is a problem with the design choices in BIP70. It sounds like a bizarre
> hack around lack of features in whatever runtime you're using.
>
>

[-- Attachment #2: Type: text/html, Size: 4517 bytes --]