From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YGW39-0002SS-OK for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:05:07 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.174 as permitted sender) client-ip=209.85.217.174; envelope-from=slashene@gmail.com; helo=mail-lb0-f174.google.com; Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YGW38-00052X-5K for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:05:07 +0000 Received: by mail-lb0-f174.google.com with SMTP id f15so19901570lbj.5 for ; Wed, 28 Jan 2015 09:05:00 -0800 (PST) X-Received: by 10.112.151.228 with SMTP id ut4mr9499035lbb.77.1422464700800; Wed, 28 Jan 2015 09:05:00 -0800 (PST) MIME-Version: 1.0 Sender: slashene@gmail.com Received: by 10.25.30.21 with HTTP; Wed, 28 Jan 2015 09:04:40 -0800 (PST) In-Reply-To: References: From: Nicolas Dorier Date: Wed, 28 Jan 2015 18:04:40 +0100 X-Google-Sender-Auth: uDFsAX8a6nMnR1RxB8C6HYibG3M Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bb70b0c32656e050db95f76 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slashene[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YGW38-00052X-5K Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 17:05:07 -0000 --047d7bb70b0c32656e050db95f76 Content-Type: text/plain; charset=UTF-8 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 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. > --047d7bb70b0c32656e050db95f76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 s= ide technology.
BIP70 has its use, and I understand why there is c= ase where it is good to ship the certs in the message and not depends on th= e 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 lim= itation in BIP70. My point is that you put the burden of certificate verifi= cation on developer's shoulder when we can just leverage built in HTTPS= support of the platform.

Platforms that support HTTPS but not cer= tificate 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 th= e parsing and validation work itself. If WinRT is such a platform, OK, too = bad.

The embedding of the certificates is not arbi= trary or pointless, by the way. It's there for a very good reason - it = makes the signed payment request verifiable by third parties. Effectively y= ou can store the signed message and present it later to someone else, it= 9;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 p= roof of purchase that can be automatically verified as legitimate. This has= all kinds of use cases.=C2=A0

Because of how HTTP= S 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 not= ary) and when we designed BIP70, those hacks didn't even exist. So we&#= 39;d lose the benefit of having a digitally signed request.

<= /div>
Additionally, doing things this way means BIP70 requests can be s= igned 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 issu= ed by some user forum, whatever else we end up wanting. Not every payment r= ecipient can be identified by a domain name + dynamic session.
= =C2=A0
However, if you want to use your plateform's st= ore, then you are toasted
That's a bit melodramatic. BitcoinJ is able to use the And= roid, JRE, Windows and Mac certificate stores all using the same code or ve= ry minor variants on it (e.g. on Mac you have to specify you want the syste= m store but it's a one-liner).=C2=A0

Yes, that= 's not every=C2=A0platform. Some will require custom binding glu= e and it depends what abstractions and languages you are using.
= =C2=A0
Have you = tried to do that on windows RT and IOS ? I tried, and I quickly stopped doi= ng that since it is not worth the effort. (Frankly I am not even sure you c= an on win rt, since the API is a stripped down version of windows)

There is code to = do iOS using the Apple APIs here:

=C2=A0
Why have you n= ot heard about the problem ? (until now, because I have this problem becaus= e I need to have the same codebase on winrt/win/android/ios/tablets)

WinRT is a minority platfor= m in the extreme, and all the other platforms you mentioned have the necess= ary APIs. Java abstracts you from them. So I think you are encountering thi= s problem because you desire to target WinRT and other platforms with a sin= gle codebase. That's an unusual constraint.

AFAIK the only other people who encountered this are BitPay, because the= y want to do everything in Javascript which doesn't really provide any = major APIs.
=C2=A0
<= div>
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 automa= tic updates.

Yes, there are= pros and cons to bundling a custom root store.
=C2=A0
Also, does java stores deals w= ith 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 curren= tly do so. A better solution would be to implement an OCSP stapling extensi= on to BIP70 though.

--047d7bb70b0c32656e050db95f76--