diff options
| author | Angel Leon <gubatron@gmail.com> | 2015-01-28 12:17:54 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-01-28 17:18:25 +0000 |
| commit | 712dbeb2c4b6840d24aff7245621b10194a92b62 (patch) | |
| tree | 2b2611138da6ab15833b800c91ac5a3db3e624d5 | |
| parent | fb6b7638b4beed00fdc49b59a7e2f75874d3d0cf (diff) | |
| download | pi-bitcoindev-712dbeb2c4b6840d24aff7245621b10194a92b62.tar.gz pi-bitcoindev-712dbeb2c4b6840d24aff7245621b10194a92b62.zip | |
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
| -rw-r--r-- | 0f/2effe03203498cd941a9de16b738655583bf75 | 367 |
1 files changed, 367 insertions, 0 deletions
diff --git a/0f/2effe03203498cd941a9de16b738655583bf75 b/0f/2effe03203498cd941a9de16b738655583bf75 new file mode 100644 index 000000000..990720577 --- /dev/null +++ b/0f/2effe03203498cd941a9de16b738655583bf75 @@ -0,0 +1,367 @@ +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 <gubatron@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CANEZrP3ta59A0Fr9-afd1ByQ7U0G7kQVu_EsK-8AZkud74Kxpw@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> + <CANEZrP3ta59A0Fr9-afd1ByQ7U0G7kQVu_EsK-8AZkud74Kxpw@mail.gmail.com> +From: Angel Leon <gubatron@gmail.com> +Date: Wed, 28 Jan 2015 12:17:54 -0500 +Message-ID: <CADZB0_a84VDU1iz8H_6AifsvZ5k68H10c1NV8irWuaz2v46EeQ@mail.gmail.com> +To: Mike Hearn <mike@plan99.net> +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 <nicolas.dorier@gmail.com>, + 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: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 <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 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. +>>> +>> +>> +> +> +> ------------------------------------------------------------------------------ +> 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 + +<div dir=3D"ltr">why not allow both serializations and keep serialization f= +ormat a parameter, keep everyone happy.</div><div class=3D"gmail_extra"><br= + clear=3D"all"><div><div class=3D"gmail_signature"><a href=3D"http://twitte= +r.com/gubatron" target=3D"_blank">http://twitter.com/gubatron</a><br></div>= +</div> +<br><div class=3D"gmail_quote">On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn= + <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank"= +>mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote"= + style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d= +iv dir=3D"ltr">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= +.<div><br></div><div>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.</div><div><br></d= +iv><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class=3D"HOEnZb"><div= + class=3D"h5"><div class=3D"gmail_extra"><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" target=3D"_blank">nicolas.dorier@gmail= +.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= +r"><div><div><div>Mike, I am not denying it is impossible to do all of that= +.<br></div>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= +.<br></div>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.<b= +r><br></div>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.<br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu= +ote">On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <span dir=3D"ltr"><<a h= +ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></s= +pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= +;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class= +=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot= +e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo= +r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt= +r"><div><div><div><div><div><div><div>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.<br></div></div></div></div></div></div></div></div>= +</blockquote><div><br></div><div>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.</div><div><br></div><div>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</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 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.</div><div><br></d= +iv><div>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.</div><div>=C2= +=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= +x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl= +e:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div><div><d= +iv></div></div></div>However, if you want to use your plateform's store= +, then you are toasted</div></div></div></div></div></blockquote><div><br><= +/div><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</div><div><br></div><div>Yes, that= +9;s not <i>every</i>=C2=A0platform. Some will require custom binding glue a= +nd it depends what abstractions and languages you are using.</div><div>=C2= +=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= +x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl= +e:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>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)<br></div></= +div></div></div></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/voisine/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><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid= +th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= +eft:1ex"><div 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 have the same codebase on winrt/win/android/ios/tablets)<br></div>= +</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><div>= +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.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2= +04,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, 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.<br></div></div></blockquote><div><br></div><div>Yes, there are pr= +os and cons to bundling a custom root store.</div><div>=C2=A0</div><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid= +th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= +eft:1ex"><div dir=3D"ltr"><div></div><div>Also, does java stores deals with= + certificate revocations ? sure you can theorically code that too... or jus= +t let the plateform deals with it.<br></div></div></blockquote><div><br></d= +iv><div>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.</div></div></div></div> +</blockquote></div><br></div> +</div></div></blockquote></div><br></div> +</div></div><br>-----------------------------------------------------------= +-------------------<br> +Dive into the World of Parallel Programming. The Go Parallel Website,<br> +sponsored by Intel and developed in partnership with Slashdot Media, is you= +r<br> +hub for all things parallel software development, from weekly thought<br> +leadership blogs to news, videos, case studies, tutorials and more. Take a<= +br> +look and join the conversation now. <a href=3D"http://goparallel.sourceforg= +e.net/" target=3D"_blank">http://goparallel.sourceforge.net/</a><br>_______= +________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br></div> + +--001a11c003728c3622050db98e3a-- + + |