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 1YGWG1-0006zF-Jn for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:18:25 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.44 as permitted sender) client-ip=209.85.216.44; envelope-from=gubatron@gmail.com; helo=mail-qa0-f44.google.com; Received: from mail-qa0-f44.google.com ([209.85.216.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YGWFv-0005lj-Nq for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 17:18:25 +0000 Received: by mail-qa0-f44.google.com with SMTP id w8so17057061qac.3 for ; Wed, 28 Jan 2015 09:18:15 -0800 (PST) X-Received: by 10.140.22.99 with SMTP id 90mr14389547qgm.72.1422465495215; Wed, 28 Jan 2015 09:18:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.42 with HTTP; Wed, 28 Jan 2015 09:17:54 -0800 (PST) In-Reply-To: References: From: Angel Leon Date: Wed, 28 Jan 2015 12:17:54 -0500 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c003728c3622050db98e3a 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 (gubatron[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: 1YGWFv-0005lj-Nq Cc: Nicolas Dorier , 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:18:25 -0000 --001a11c003728c3622050db98e3a Content-Type: text/plain; charset=UTF-8 why not allow both serializations and keep serialization format a parameter, keep everyone happy. http://twitter.com/gubatron On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn wrote: > 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. >>> >> >> > > > ------------------------------------------------------------------------------ > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11c003728c3622050db98e3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
why not allow both serializations and keep serialization f= ormat a parameter, keep everyone happy.

On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn= <mike@plan99.net> wrote:
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 t= o be difficult. I know you had odd problems with the C# protobuf implementa= tion you were using but library bugs can happen for any kind of programming= .

I forgot to mention the other reason it's done thi= s way. One of the driving goals of BIP70 was to support the TREZOR and simi= lar 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 securi= ty quite a bit.

Whilst I appreciate if your platfo= rm 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 t= argets.



On = Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier <nicolas.dorier@gmail= .com> 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 every= where, 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 i= s 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 flexi= ble that BIP70, would make it easier and sufficient for today's use cas= e.

On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike@plan99.net> wrote:
My point is not that there is a limit= ation in BIP70. My point is that you put the burden of certificate verifica= tion on developer's shoulder when we can just leverage built in HTTPS s= upport of the platform.
=

Platforms that support HTTPS but not certi= ficate handling are rare - I know HTML5 is such a platform but such apps ar= e 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 ba= d.

The embedding of the certificates is not arbitr= ary or pointless, by the way. It's there for a very good reason - it ma= kes 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 th= em to the block chain, what you have is a form of digital receipt ... a pro= of of purchase that can be automatically verified as legitimate. This has a= ll 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 notar= y) 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 sig= ned 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 rec= ipient can be identified by a domain name + dynamic session.
=C2= =A0
However, if you want to use your plateform's store= , then you are toasted

<= /div>
That's a bit melodramatic. BitcoinJ is able to use the Androi= d, 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 s= tore but it's a one-liner).=C2=A0

Yes, that= 9;s not every=C2=A0platform. Some will require custom binding glue a= nd it depends what abstractions and languages you are using.
=C2= =A0
Have you tri= ed 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:

=C2=A0
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 i= n 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 p= roblem 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 w= ant to do everything in Javascript which doesn't really provide any maj= or APIs.
=C2=A0
Also, you bundle mozilla's store in bitcoinj, wh= at happen when the store change and your customer have not intent to use bi= tcoinj new version ? by leveraging the plateform you benefit from automatic= updates.

Yes, there are pr= os and cons to bundling a custom root store.
=C2=A0
Also, does java stores deals with= certificate revocations ? sure you can theorically code that too... or jus= t 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.



-----------------------------------------------------------= -------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is you= r
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a<= br> look and join the conversation now. http://goparallel.sourceforge.net/
_______= ________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c003728c3622050db98e3a--