From: Nicolas Dorier <nicolas.dorier@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 18:04:40 +0100 [thread overview]
Message-ID: <CA+1nnr=5PVhME1nZz=5Ki9SXH4Ok=pamDSGr_8Pz6nzyM9SRbQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]
Mike, I am not denying it is impossible to do all of that.
Just that it is not a trivial stuff to do to make it works everywhere, and
I think that it is not a good thing for a client side technology.
BIP70 has its use, and I understand why there is case where it is good to
ship the certs in the message and not depends on the transport.
But a standard that just use JSON and HTTPS, even if less flexible that
BIP70, would make it easier and sufficient for today's use case.
On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike@plan99•net> wrote:
> 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: 6654 bytes --]
next prev parent reply other threads:[~2015-01-28 17:05 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
2015-01-28 17:04 ` Nicolas Dorier [this message]
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='CA+1nnr=5PVhME1nZz=5Ki9SXH4Ok=pamDSGr_8Pz6nzyM9SRbQ@mail.gmail.com' \
--to=nicolas.dorier@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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