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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YGWP9-0007QK-Ts for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:27:51 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.46 as permitted sender) client-ip=74.125.82.46; envelope-from=nicolas.dorier@gmail.com; helo=mail-wg0-f46.google.com; Received: from mail-wg0-f46.google.com ([74.125.82.46]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YGWP7-0006EW-UD for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:27:51 +0000 Received: by mail-wg0-f46.google.com with SMTP id l2so21940687wgh.5 for ; Wed, 28 Jan 2015 09:27:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.2.178 with SMTP id 18mr9553575wjv.67.1422466064857; Wed, 28 Jan 2015 09:27:44 -0800 (PST) Sender: slashene@gmail.com X-Google-Sender-Delegation: slashene@gmail.com Received: by 10.194.92.112 with HTTP; Wed, 28 Jan 2015 09:27:44 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 18:27:44 +0100 X-Google-Sender-Auth: 2HlGphfTITnfiCl8yzZ2Tb3vRkc Message-ID: From: Nicolas DORIER To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7b3a86ba803e59050db9b053 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 (nicolas.dorier[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: 1YGWP7-0006EW-UD 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:27:52 -0000 --047d7b3a86ba803e59050db9b053 Content-Type: text/plain; charset=UTF-8 Sure, But the mobile targets, it is still easier to use Json + HTTPS, especially when you want one code base for everything. And as you said, developers need to think about fetching mozilla store time to time, and check revocations themselves. This is not obvious thing to do, and hard to test correctly. If your use case was the primary utility of BIP70, then I'd say it fit the bill. But for cross plateform client development an atlernative would be easier. > why not allow both serializations and keep serialization format a parameter, keep everyone happy. It would be another BIP, because if we use JSON with HTTPS, the difference is also in the semantic (no embedded certificates) I will likely provide this option for a product I am developing. I will only use another Content Type. We'll see then how it goes. 2015-01-28 18:14 GMT+01:00 Mike Hearn : > I think we'll just have to agree to disagree on this one. I've implemented > BIP70 a couple of times now and didn't find it to be difficult. I know you > had odd problems with the C# protobuf implementation you were using but > library bugs can happen for any kind of programming. > > I forgot to mention the other reason it's done this way. One of the > driving goals of BIP70 was to support the TREZOR and similar devices. For > hardware wallets, it's critical to keep the amount of code they need to run > as small as possible. Any bugs in the code there can cause security holes > and lead to the device being hacked. > > Doing it the way you suggest would mean the secure code would have to > contain complex and bug-prone text parsing logic as well as a full blown > HTTP and SSL stack, that requires not only X.509 handling but also lots of > other stuff on top. It'd increase cost, complexity and decrease security > quite a bit. > > Whilst I appreciate if your platform provides a scripting-like API and > nothing low level it might seem easier to use JSON+HTTPS, that isn't the > case for one of the primary design targets. > > > > On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier > wrote: > >> 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. >>> >> >> > --047d7b3a86ba803e59050db9b053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure,

But the mobile= targets, it is still easier to use Json + HTTPS, especially when you want = one code base for everything.
And as you said, developers need to = think about fetching mozilla store time to time, and check revocations them= selves. This is not obvious thing to do, and hard to test correctly.

If your use case was the primary utility of BIP70, then I'd say = it fit the bill. But for cross plateform client development an atlernative = would be easier.

> why not allow both serializations and keep ser= ialization format a parameter, keep everyone happy.

It would b= e another BIP, because if we use JSON with HTTPS, the difference is also in= the semantic (no embedded certificates)

I will likely provide= this option for a product I am developing. I will only use another Content= Type. We'll see then how it goes.
=
2015-01-28 18:14 GMT+01:00 Mike Hearn <mike@p= lan99.net>:
I think we'll just have to agree to disagree on this one. I've im= plemented BIP70 a couple of times now and didn't find it to be difficul= t. I know you had odd problems with the C# protobuf implementation you were= using but library bugs can happen for any kind of programming.

I forgot to mention the other reason it's done this way. One of= the driving goals of BIP70 was to support the TREZOR and similar devices. = For hardware wallets, it's critical to keep the amount of code they nee= d to run as small as possible. Any bugs in the code there can cause securit= y holes and lead to the device being hacked.

Doing= it the way you suggest would mean the secure code would have to contain co= mplex and bug-prone text parsing logic as well as a full blown HTTP and SSL= stack, that requires not only X.509 handling but also lots of other stuff = on top. It'd increase cost, complexity and decrease security quite a bi= t.

Whilst I appreciate if your platform provides a= scripting-like API and nothing low level it might seem easier to use JSON+= HTTPS, that isn't the case for one of the primary design targets.
=



On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier <nicolas.dorier@gmail.com> wrote:
Mike, I am not denying it is impossi= ble to do all of that.
Just that it is not a trivial stuff to do t= o make it works everywhere, and I think that it is not a good thing for a c= lient side technology.
BIP70 has its use, and I understand why the= re is case where it is good to ship the certs in the message and not depend= s on the transport.

But a standard that just use JSON and HTTP= S, even if less flexible that BIP70, would make it easier and sufficient fo= r 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 ser= ver anyway and the server can just do the parsing and validation work itsel= f. If WinRT is such a platform, OK, too bad.

The e= mbedding of the certificates is not arbitrary or pointless, by the way. It&= #39;s there for a very good reason - it makes the signed payment request ve= rifiable by third parties. Effectively you can store the signed message and= present it later to someone else, it's undeniable. Combined with the t= ransactions and merkle branches linking them to the block chain, what you h= ave is a form of digital receipt ... a proof of purchase that can be automa= tically verified as legitimate. This has all kinds of use cases.=C2=A0

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, th= ose hacks didn't even exist. So we'd lose the benefit of having a d= igitally signed request.

Additionally, doing thing= s 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 certif= icate i.e. a company, a certificate issued by some user forum, whatever els= e we end up wanting. Not every payment recipient can be identified by a dom= ain name + dynamic session.
=C2=A0
However, if y= ou want to use your plateform's store, then you are toasted
=

That's a bit melodra= matic. BitcoinJ is able to use the Android, JRE, Windows and Mac certificat= e 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).=C2= =A0

Yes, that's not every=C2=A0platform= . Some will require custom binding glue and it depends what abstractions an= d languages you are using.
=C2=A0
Have you tried to do that on windows RT and IO= S ? I tried, and I quickly stopped doing that since it is not worth the eff= ort. (Frankly I am not even sure you can on win rt, since the API is a stri= pped down version of windows)

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

=C2=A0
Why have you not heard about the problem ? (until n= ow, 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 p= latforms you mentioned have the necessary APIs. Java abstracts you from the= m. So I think you are encountering this problem because you desire to targe= t WinRT and other platforms with a single codebase. That's an unusual c= onstraint.

AFAIK the only other people who en= countered this are BitPay, because they want to do everything in Javascript= which doesn't really provide any major APIs.
=C2=A0
Also, you b= undle mozilla's store in bitcoinj, what happen when the store change an= d 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 r= oot store.
=C2=A0
Also, does java stores deals with certificate revocations ? sure yo= u 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.
=



--047d7b3a86ba803e59050db9b053--