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; 
MIME-Version: 1.0
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
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?
Precedence: list

--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">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank"=
>mike@plan99.net</a>&gt;</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&#39;ll just have to agree to disagree on this one=
. I&#39;ve implemented BIP70 a couple of times now and didn&#39;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&#39;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&#39;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&#39;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&#39;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">&lt;<a href=
=3D"mailto:nicolas.dorier@gmail.com" target=3D"_blank">nicolas.dorier@gmail=
.com</a>&gt;</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&#39;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">&lt;<a h=
ref=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</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&#39;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&#39;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&#39;=
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&#39;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&#39;t even exist. So we&#39=
;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&#39;s store=
, then you are toasted</div></div></div></div></div></blockquote><div><br><=
/div><div>That&#39;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&#39;s a one-liner).=C2=A0</div><div><br></div><div>Yes, that&#3=
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&#39;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&#39;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&#39;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--