<unnamed>

Public Key

npub1cd4e6u5fxf2jjznq3esvdnz4x49njfdu8mp6l5v89mnwu6x9jauqp682r9

Profile Code

nprofile1qqsvx6uaw2yny4ffpfsgucxxe32n2jeeyk7rasa06xrjaehwdrzew7qpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46q69w3el

Publishing to

relay.nostr.net

Last Notes

2023-06-07 15:28:43 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message: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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/8a32ba6e/attachment.html>

2023-06-07 15:28:41 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message:For the number of field there is in the spec, I don't consider having a
JSON to schama really worthwhile.
If you fear it is error prone, then we should provide some testing data for
the BIP70. (Which I already did for protobuf, but was rejected, because
deemed no useful thanks to the code generator... But such code generator
gave me inconsistencies with gavin's implementation for example)
Why do you think type support is very useful in our case ? we have 3 types,
and dealing only with bytes, int, and string.
It cost me more time to find a suitable cross plateform lib for protobuf
(in c#, that works in ios and winrt) than I would by just coding the json
wrapper classes by hand. (JSON libs are more wildspread and supported than
protobuf)
2015-01-28 17:04 GMT+01:00 Jeff Garzik <jgarzik at bitpay.com>:
> Not to mention the tiresome and error-prone task of writing your own
> JSON-to-schema marshalling code -- or something equivalent to the protobufs
> compiler and libs for JSON.
>
> protobufs -- and its modern competitors such as msgpack -- natively
> provide type support in a way that must be hacked into JSON or XML.
>
> The protobuf/msgpack design is engineered to avoid bugs routinely found in
> JSON parsing code; due to the amount of code & effort involved in JSON
> input sanity checking, bugs and inconsistencies inevitable arise. We have
> seen this in bitcoind with JSON-RPC.
>
>
>
> On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/2eaf6cc2/attachment.html>

2023-06-07 15:28:40 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message:I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
The choice should have been done to maximize portability, not to maximize
efficiency and flexibility.
What I ended up doing for having a similar codebase on all plateform is to
parse a BIP70 messages with the help of a web service that convert it to
JSON.
I don't like this solution since it had a trust dependency, and the
certificate verification become handled by the web service, not the device.
But even if I solved google buffer problem, I would stumble upon having
headache to validate the x509 certificate chain on every plateforms.
A simple BIP70 using JSON + HTTPS would have make things more easy.
I agree that it requires that the merchant own the domain name of the BIP70
endpoint, but I don't consider such a big of a deal, since this is how
e-commerce works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/6e5b0a0e/attachment.html>

2023-06-07 15:28:40 UTC

- reply

📅 Original date posted:2015-01-28
📝 Original message:Sure I know that x509 is international standard. And that HTTPS uses TLS.
This is not my point, my point is that when we use HTTPS the developer
delegates certificates verification to the plateform he is running on, so
developer don't have to bother about it, making the implementation safer
and easier.
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.
So, let's say I want to target IOS + WP + Android + WinRT + desktop win, I
need to develop 4 times chain verification and certificate parsing.
(Because I can't verify a certificate if it is not in the specific type of
the underlying plateform)
And since it would take too much time to do that, I end up delegating
parsing and trust verification to a third party service.
2015-01-28 14:32 GMT+01:00 Wladimir <laanwj at gmail.com>:
>
> On Wed, 28 Jan 2015, Nicolas DORIER wrote:
>
> I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
>>
>
> Well x509 is an international standard in common use, you can't do much
> better with regard to portability. Your suggestion about HTTPS makes little
> sense, you do know what TLS uses x509 internally as well?
>
> Re: protocol buffers, I don't know if it's the best possible one, but one
> serialization method had to be picked. If it weren't, we could still have
> still been discussing which one to use by now. Just like for JSON there are
> bindings for many languages.
>
> Though JSON parsers are much more diverse, which people using Bitcoin
> Core's RPC have bumped into e.g. some have some problems handling large
> numbers. Something you wouldn't expect using a straightforward binary
> format. There's no obvious best choice.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150128/193f06f5/attachment.html>