diff options
| author | Mike Hearn <mike@plan99.net> | 2015-01-28 18:14:07 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-01-28 17:14:14 +0000 |
| commit | fb6b7638b4beed00fdc49b59a7e2f75874d3d0cf (patch) | |
| tree | e07476451ad49f9b7606632454eae411f6d1ef14 /0c/0f0063194b75fb0164e552be89f88c4a3e40ea | |
| parent | 1cad98d1a9abf7a7936c2e9e596cf2c1b03eb655 (diff) | |
| download | pi-bitcoindev-fb6b7638b4beed00fdc49b59a7e2f75874d3d0cf.tar.gz pi-bitcoindev-fb6b7638b4beed00fdc49b59a7e2f75874d3d0cf.zip | |
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Diffstat (limited to '0c/0f0063194b75fb0164e552be89f88c4a3e40ea')
| -rw-r--r-- | 0c/0f0063194b75fb0164e552be89f88c4a3e40ea | 315 |
1 files changed, 315 insertions, 0 deletions
diff --git a/0c/0f0063194b75fb0164e552be89f88c4a3e40ea b/0c/0f0063194b75fb0164e552be89f88c4a3e40ea new file mode 100644 index 000000000..f8604dd3e --- /dev/null +++ b/0c/0f0063194b75fb0164e552be89f88c4a3e40ea @@ -0,0 +1,315 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1YGWBy-0000wv-K5 + for bitcoin-development@lists.sourceforge.net; + Wed, 28 Jan 2015 17:14:14 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.212.182 as permitted sender) + client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com; + helo=mail-wi0-f182.google.com; +Received: from mail-wi0-f182.google.com ([209.85.212.182]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YGWBw-0001tK-Nd + for bitcoin-development@lists.sourceforge.net; + Wed, 28 Jan 2015 17:14:14 +0000 +Received: by mail-wi0-f182.google.com with SMTP id n3so13376877wiv.3 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 28 Jan 2015 09:14:07 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.194.219.68 with SMTP id pm4mr9535449wjc.71.1422465247658; + Wed, 28 Jan 2015 09:14:07 -0800 (PST) +Sender: mh.in.england@gmail.com +Received: by 10.194.188.9 with HTTP; Wed, 28 Jan 2015 09:14:07 -0800 (PST) +In-Reply-To: <CA+1nnr=5PVhME1nZz=5Ki9SXH4Ok=pamDSGr_8Pz6nzyM9SRbQ@mail.gmail.com> +References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com> + <alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz> + <CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com> + <CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com> + <CALYO6Xucf7xqE_4ykJqFyS_AEAT0X-1aGvYmA0WXzX7By0c0uQ@mail.gmail.com> + <CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@mail.gmail.com> + <CA+1nnr=5PVhME1nZz=5Ki9SXH4Ok=pamDSGr_8Pz6nzyM9SRbQ@mail.gmail.com> +Date: Wed, 28 Jan 2015 18:14:07 +0100 +X-Google-Sender-Auth: Pn2Tv6VdKNRDKTU36KvYCx87LFE +Message-ID: <CANEZrP3ta59A0Fr9-afd1ByQ7U0G7kQVu_EsK-8AZkud74Kxpw@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Nicolas Dorier <nicolas.dorier@gmail.com> +Content-Type: multipart/alternative; boundary=001a11c1b9c2cac9f7050db97f61 +X-Spam-Score: -0.5 (/) +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 + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 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: 1YGWBw-0001tK-Nd +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 28 Jan 2015 17:14:14 -0000 + +--001a11c1b9c2cac9f7050db97f61 +Content-Type: text/plain; charset=UTF-8 + +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 <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 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. +>> +> +> + +--001a11c1b9c2cac9f7050db97f61 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">I think we'll just have to agree to disagree on this o= +ne. 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 implemen= +tation you were using but library bugs can happen for any kind of programmi= +ng.<div><br></div><div>I forgot to mention the other reason it's done t= +his way. One of the driving goals of BIP70 was to support the TREZOR and si= +milar devices. For hardware wallets, it's critical to keep the amount o= +f code they need to run as small as possible. Any bugs in the code there ca= +n cause security holes and lead to the device being hacked.</div><div><br><= +/div><div>Doing it the way you suggest would mean the secure code would hav= +e to contain complex and bug-prone text parsing logic as well as a full blo= +wn 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 secu= +rity quite a bit.</div><div><br></div><div>Whilst I appreciate if your plat= +form provides a scripting-like API and nothing low level it might seem easi= +er to use JSON+HTTPS, that isn't the case for one of the primary design= + targets.</div><div><br></div><div><br></div></div><div class=3D"gmail_extr= +a"><br><div class=3D"gmail_quote">On Wed, Jan 28, 2015 at 6:04 PM, Nicolas = +Dorier <span dir=3D"ltr"><<a href=3D"mailto:nicolas.dorier@gmail.com" ta= +rget=3D"_blank">nicolas.dorier@gmail.com</a>></span> wrote:<br><blockquo= +te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= +lid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Mike, I am not denyin= +g it is impossible to do all of that.<br></div>Just that it is not a trivia= +l stuff to do to make it works everywhere, and I think that it is not a goo= +d thing for a client side technology.<br></div>BIP70 has its use, and I und= +erstand why there is case where it is good to ship the certs in the message= + and not depends on the transport.<br><br></div>But a standard that just us= +e JSON and HTTPS, even if less flexible that BIP70, would make it easier an= +d sufficient for today's use case.<br></div><div class=3D"HOEnZb"><div = +class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On W= +ed, Jan 28, 2015 at 5:55 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"ma= +ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrot= +e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= +eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e= +xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= +"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2= +04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><di= +v><div><div><div><div><div>My point is not that there is a limitation in BI= +P70. My point is that you put the burden of certificate verification on dev= +eloper's shoulder when we can just leverage built in HTTPS support of t= +he platform.<br></div></div></div></div></div></div></div></div></blockquot= +e><div><br></div><div>Platforms that support HTTPS but not certificate hand= +ling are rare - I know HTML5 is such a platform but such apps are inherentl= +y 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.</div><di= +v><br></div><div>The embedding of the certificates is not arbitrary or poin= +tless, by the way. It's there for a very good reason - it makes the sig= +ned payment request verifiable by third parties. Effectively you can store = +the signed message and present it later to someone else, it's undeniabl= +e. Combined with the transactions and merkle branches linking them to the b= +lock chain, what you have is a form of digital receipt ... a proof of purch= +ase that can be automatically verified as legitimate. This has all kinds of= + use cases.=C2=A0</div><div><br></div><div>Because of how HTTPS works, you = +can't easily prove to a third party that a server gave you a piece of d= +ata. 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.</div><div><br></div><div>Add= +itionally, doing things this way means BIP70 requests can be signed by thin= +gs which are not HTTPS servers. For example you can sign with an email addr= +ess cert, an EV certificate i.e. a company, a certificate issued by some us= +er forum, whatever else we end up wanting. Not every payment recipient can = +be identified by a domain name + dynamic session.</div><div>=C2=A0</div><bl= +ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= +t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= +ing-left:1ex"><div dir=3D"ltr"><div><div><div><div><div><div><div></div></d= +iv></div>However, if you want to use your plateform's store, then you a= +re toasted</div></div></div></div></div></blockquote><div><br></div><div>Th= +at's a bit melodramatic. BitcoinJ is able to use the Android, JRE, Wind= +ows and Mac certificate stores all using the same code or very minor varian= +ts on it (e.g. on Mac you have to specify you want the system store but it&= +#39;s a one-liner).=C2=A0</div><div><br></div><div>Yes, that's not <i>e= +very</i>=C2=A0platform. Some will require custom binding glue and it depend= +s what abstractions and languages you are using.</div><div>=C2=A0</div><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= +-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi= +ng-left:1ex"><div dir=3D"ltr"><div><div><div><div>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, si= +nce the API is a stripped down version of windows)<br></div></div></div></d= +iv></div></blockquote><div><br></div><div>There is code to do iOS using the= + Apple APIs here:</div><div><br></div><div><a href=3D"https://github.com/vo= +isine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391" target= +=3D"_blank">https://github.com/voisine/breadwallet/blob/master/BreadWallet/= +BRPaymentProtocol.m#L391</a><br></div><div>=C2=A0</div><blockquote class=3D= +"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde= +r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di= +v dir=3D"ltr"><div><div><div><div></div></div>Why have you not heard about = +the problem ? (until now, because I have this problem because I need to hav= +e the same codebase on winrt/win/android/ios/tablets)<br></div></div></div>= +</blockquote><div><br></div><div>WinRT is a minority platform in the extrem= +e, and all the other platforms you mentioned have the necessary APIs. Java = +abstracts you from them. So I think you are encountering this problem becau= +se you desire to target WinRT and other platforms with a single codebase. T= +hat's an unusual constraint.</div><div><br></div><div><div>AFAIK the on= +ly other people who encountered this are BitPay, because they want to do ev= +erything in Javascript which doesn't really provide any major APIs.</di= +v></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:= +0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);= +border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div></div>= +</div><div>Also, you bundle mozilla's store in bitcoinj, what happen wh= +en the store change and your customer have not intent to use bitcoinj new v= +ersion ? by leveraging the plateform you benefit from automatic updates.<br= +></div></div></blockquote><div><br></div><div>Yes, there are pros and cons = +to bundling a custom root store.</div><div>=C2=A0</div><blockquote class=3D= +"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde= +r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><di= +v dir=3D"ltr"><div></div><div>Also, does java stores deals with certificate= + revocations ? sure you can theorically code that too... or just let the pl= +ateform deals with it.<br></div></div></blockquote><div><br></div><div>It c= +an do OCSP checks, yes, although I believe no wallets currently do so. A be= +tter solution would be to implement an OCSP stapling extension to BIP70 tho= +ugh.</div></div></div></div> +</blockquote></div><br></div> +</div></div></blockquote></div><br></div> + +--001a11c1b9c2cac9f7050db97f61-- + + |