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 : > 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. > >