path: root/6d/7d0c67f829507995d64f382d7fb4b24dc7d1c6

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <slashene@gmail.com>) id 1YGW39-0002SS-OK
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Jan 2015 17:05:07 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.174 as permitted sender)
	client-ip=209.85.217.174; envelope-from=slashene@gmail.com;
	helo=mail-lb0-f174.google.com; 
Received: from mail-lb0-f174.google.com ([209.85.217.174])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YGW38-00052X-5K
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Jan 2015 17:05:07 +0000
Received: by mail-lb0-f174.google.com with SMTP id f15so19901570lbj.5
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 28 Jan 2015 09:05:00 -0800 (PST)
X-Received: by 10.112.151.228 with SMTP id ut4mr9499035lbb.77.1422464700800;
	Wed, 28 Jan 2015 09:05:00 -0800 (PST)
MIME-Version: 1.0
Sender: slashene@gmail.com
Received: by 10.25.30.21 with HTTP; Wed, 28 Jan 2015 09:04:40 -0800 (PST)
In-Reply-To: <CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@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>
From: Nicolas Dorier <nicolas.dorier@gmail.com>
Date: Wed, 28 Jan 2015 18:04:40 +0100
X-Google-Sender-Auth: uDFsAX8a6nMnR1RxB8C6HYibG3M
Message-ID: <CA+1nnr=5PVhME1nZz=5Ki9SXH4Ok=pamDSGr_8Pz6nzyM9SRbQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bb70b0c32656e050db95f76
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
	(slashene[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: 1YGW38-00052X-5K
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:05:07 -0000

--047d7bb70b0c32656e050db95f76
Content-Type: text/plain; charset=UTF-8

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.
>

--047d7bb70b0c32656e050db95f76
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><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 everywhere, and I think that it is not a good thing for a client s=
ide technology.<br></div>BIP70 has its use, and I understand why there is c=
ase where it is good to ship the certs in the message and not depends on th=
e transport.<br><br></div>But a standard that just use JSON and HTTPS, even=
 if less flexible that BIP70, would make it easier and sufficient for today=
&#39;s use case.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, Jan 28, 2015 at 5:55 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"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div><div><div><div><div><div><div>My point is not that there is a lim=
itation in BIP70. My point is that you put the burden of certificate verifi=
cation on developer&#39;s shoulder when we can just leverage built in HTTPS=
 support of the platform.<br></div></div></div></div></div></div></div></di=
v></blockquote><div><br></div><div>Platforms that support HTTPS but not cer=
tificate 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 th=
e parsing and validation work itself. If WinRT is such a platform, OK, too =
bad.</div><div><br></div><div>The embedding of the certificates is not arbi=
trary or pointless, by the way. It&#39;s there for a very good reason - it =
makes the signed payment request verifiable by third parties. Effectively y=
ou can store the signed message and present it later to someone else, it&#3=
9;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 p=
roof of purchase that can be automatically verified as legitimate. This has=
 all kinds of use cases.=C2=A0</div><div><br></div><div>Because of how HTTP=
S 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 not=
ary) 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><=
/div><div>Additionally, doing things this way means BIP70 requests can be s=
igned 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 issu=
ed by some user forum, whatever else we end up wanting. Not every payment r=
ecipient 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=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div><div=
><div></div></div></div>However, if you want to use your plateform&#39;s st=
ore, then you are toasted</div></div></div></div></div></blockquote><div><b=
r></div><div>That&#39;s a bit melodramatic. BitcoinJ is able to use the And=
roid, JRE, Windows and Mac certificate stores all using the same code or ve=
ry minor variants on it (e.g. on Mac you have to specify you want the syste=
m store but it&#39;s a one-liner).=C2=A0</div><div><br></div><div>Yes, that=
&#39;s not <i>every</i>=C2=A0platform. Some will require custom binding glu=
e and 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=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-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 doi=
ng that since it is not worth the effort. (Frankly I am not even sure you c=
an 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/mast=
er/BreadWallet/BRPaymentProtocol.m#L391</a><br></div><div>=C2=A0</div><bloc=
kquote 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;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div><div><div></div></div>Why have you n=
ot heard about the problem ? (until now, because I have this problem becaus=
e I need to have the same codebase on winrt/win/android/ios/tablets)<br></d=
iv></div></div></blockquote><div><br></div><div>WinRT is a minority platfor=
m in the extreme, and all the other platforms you mentioned have the necess=
ary APIs. Java abstracts you from them. So I think you are encountering thi=
s problem because you desire to target WinRT and other platforms with a sin=
gle codebase. That&#39;s an unusual constraint.</div><div><br></div><div><d=
iv>AFAIK the only other people who encountered this are BitPay, because the=
y want to do everything in Javascript which doesn&#39;t really provide any =
major APIs.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,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,=
 what happen when the store change and your customer have not intent to use=
 bitcoinj new version ? by leveraging the plateform you benefit from automa=
tic 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><bloc=
kquote 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;paddin=
g-left:1ex"><div dir=3D"ltr"><div></div><div>Also, does java stores deals w=
ith certificate revocations ? sure you can theorically code that too... or =
just let the plateform deals with it.<br></div></div></blockquote><div><br>=
</div><div>It can do OCSP checks, yes, although I believe no wallets curren=
tly do so. A better solution would be to implement an OCSP stapling extensi=
on to BIP70 though.</div></div></div></div>
</blockquote></div><br></div>

--047d7bb70b0c32656e050db95f76--