From: Mike Hearn <mike@plan99•net>
To: Nicolas DORIER <nicolas.dorier@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 17:55:43 +0100 [thread overview]
Message-ID: <CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@mail.gmail.com> (raw)
In-Reply-To: <CALYO6Xucf7xqE_4ykJqFyS_AEAT0X-1aGvYmA0WXzX7By0c0uQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3692 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.
>
Platforms that support HTTPS but not certificate handling are rare - I know
HTML5 is such a platform but such apps are inherently dependent on the
server anyway and the server can just do the parsing and validation work
itself. If WinRT is such a platform, OK, too bad.
The embedding of the certificates is not arbitrary or pointless, by the
way. It's there for a very good reason - it makes the signed payment
request verifiable by third parties. Effectively you can store the signed
message and present it later to someone else, it's undeniable. Combined
with the transactions and merkle branches linking them to the block chain,
what you have is a form of digital receipt ... a proof of purchase that can
be automatically verified as legitimate. This has all kinds of use cases.
Because of how HTTPS works, you can't easily prove to a third party that a
server gave you a piece of data. Doing so requires staggeringly complex
hacks (see tls notary) and when we designed BIP70, those hacks didn't even
exist. So we'd lose the benefit of having a digitally signed request.
Additionally, doing things this way means BIP70 requests can be signed by
things which are not HTTPS servers. For example you can sign with an email
address cert, an EV certificate i.e. a company, a certificate issued by
some user forum, whatever else we end up wanting. Not every payment
recipient can be identified by a domain name + dynamic session.
> However, if you want to use your plateform's store, then you are toasted
>
That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
Windows and Mac certificate stores all using the same code or very minor
variants on it (e.g. on Mac you have to specify you want the system store
but it's a one-liner).
Yes, that's not *every* platform. Some will require custom binding glue and
it depends what abstractions and languages you are using.
> 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)
>
There is code to do iOS using the Apple APIs here:
https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
> 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)
>
WinRT is a minority platform in the extreme, and all the other platforms
you mentioned have the necessary APIs. Java abstracts you from them. So I
think you are encountering this problem because you desire to target WinRT
and other platforms with a single codebase. That's an unusual constraint.
AFAIK the only other people who encountered this are BitPay, because they
want to do everything in Javascript which doesn't really provide any major
APIs.
> 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.
>
Yes, there are pros and cons to bundling a custom root store.
> Also, does java stores deals with certificate revocations ? sure you can
> theorically code that too... or just let the plateform deals with it.
>
It can do OCSP checks, yes, although I believe no wallets currently do so.
A better solution would be to implement an OCSP stapling extension to BIP70
though.
[-- Attachment #2: Type: text/html, Size: 5748 bytes --]
next prev parent reply other threads:[~2015-01-28 16:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER
2015-01-28 15:42 ` Mike Hearn
2015-01-28 16:04 ` Jeff Garzik
2015-01-28 16:52 ` Nicolas DORIER
2015-01-28 17:29 ` Jeff Garzik
2015-01-28 17:45 ` Mike Hearn
2015-01-28 16:19 ` Giuseppe Mazzotta
2015-01-28 16:51 ` Matt Whitlock
2015-01-28 17:02 ` Mike Hearn
2015-01-28 16:34 ` Nicolas DORIER
2015-01-28 16:55 ` Mike Hearn [this message]
2015-01-28 17:04 ` Nicolas Dorier
2015-01-28 17:14 ` Mike Hearn
2015-01-28 17:17 ` Angel Leon
2015-01-28 17:27 ` Nicolas DORIER
-- strict thread matches above, loose matches on Subject: below --
2015-01-19 19:07 Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16 ` Richard Brady
2015-01-19 19:34 ` Jeff Garzik
2015-01-19 19:48 ` Peter Todd
2015-01-19 19:57 ` Richard Brady
2015-01-19 20:03 ` Alan Reiner
2015-01-19 20:06 ` Peter Todd
2015-01-19 20:40 ` Mike Hearn
2015-01-19 20:56 ` Gavin Andresen
2015-01-19 21:22 ` Brian Hoffman
2015-01-19 20:59 ` Ross Nicoll
2015-01-24 13:19 ` Isidor Zeuner
2015-01-25 22:59 ` Ross Nicoll
2015-03-14 15:58 ` Isidor Zeuner
2015-03-24 12:08 ` Jorge Timón
2015-01-19 21:21 ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37 ` Mike Hearn
2015-01-19 19:38 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=nicolas.dorier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox