From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <F4631D31-54E2-43EF-B6BA-69B7371F1E6D@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 21 Dec 2017 10:04:44 +0100
In-Reply-To: <CA+1nnr=oCWwibecFGXpOJbtWnQ1b9=+Qx0nQcKoJRgdxyWZVrg@mail.gmail.com>
To: Nicolas Dorier <nicolas.dorier@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CA+1nnr=-6UkJT=TWjDHhZtXsic8p0fzQ=Yk1tSqkhL+NuvqCQw@mail.gmail.com>
	<A2014DA0-F6F8-470F-A167-E66723281269@sprovoost.nl>
	<CA+1nnr=oCWwibecFGXpOJbtWnQ1b9=+Qx0nQcKoJRgdxyWZVrg@mail.gmail.com>
Subject: Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)
Precedence: list


--Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3"


--Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Just to clarify two points:

> The good part is that it does not have to be adopted by exchanges. If =
popular exchanges do not adopt it, it is trivial to make an adapter =
service which translate COX to whatever proprietary API of the exchange.

Be sure to elaborate on the difference in trust assumptions between a =
merchant running such an adapter on their own infrastructure vs. =
trusting a SAAS that sits in between the exchange and the merchants =
infrastructure.

In general adapters would create additional risks to think about, =
depending on how fine-tuned the API key permissions are. E.g. if API =
keys come with full permissions you don=E2=80=99t want to install an =
adaptor plugin if your shop is hosted on wordpress.com. PayPal and =
Stripe make sure their API keys can=E2=80=99t do too much damage in case =
the merchant shop hosting is compromised.

> > Can this be combined with an invoice mechanism similar to Lightning, =
e.g. where the exchange sends a pre-image to the users wallet (relayed =
via and retained by the web shop) upon receipt of the funds, which they =
can then present to the merchant in case something went wrong. Exchanges =
might be happy to support this protocol, but they don=E2=80=99t want the =
burden of dealing with user support requests, so having signed invoices =
could help with that.
>=20
> This protocol can be expanded later for lightning trivially, where the =
call to the address source uri also returns a lightning payment request. =
(BOLT11)

I didn=E2=80=99t mean adding Lightning support (though that would be =
cool), I mean adding an invoice system to your proposal that is similar =
to how Lightning invoices work. Right now if the customer pays and the =
merchant has a poorly functioning shopping cart system, which I=E2=80=99ve=
 seen more often than not, the customer would have to email their =
transaction id to the merchant, who then needs to login to their =
exchange to check if that address indeed belongs to them. But a merchant =
shouldn=E2=80=99t give all their support staff such access, and support =
staff may not have the right training, or even permission, to assess =
whether a transaction is cleared (=E2=80=9Ccomputer says no").

So you=E2=80=99d want some sort of signed message as part of the =
protocol that says =E2=80=9Cif this transaction ID confirms, this order =
ID is paid for=E2=80=9D.   Although this specific example wouldn=E2=80=99t=
 play well with RBF. So maybe =E2=80=9Cif the confirmed balance of this =
address is >=3D X, this order ID is paid for=E2=80=9D, but then the =
exchange can=E2=80=99t sweep it. So maybe instead you need a callback =
from the exchange to just tell you when it=E2=80=99s (expected to be) =
confirmed. BitPay offers merchants various risk settings for this, so =
that might be worth looking into.

Sjors

--Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><div>Just to clarify two points:</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D"">The good part is that it =
does not have to be adopted by exchanges. If popular exchanges do not =
adopt it, it is trivial to make an adapter service which translate COX =
to whatever proprietary API of the exchange.</blockquote><br =
class=3D""></div><div>Be sure to elaborate on the difference in trust =
assumptions between a merchant running such an adapter on their own =
infrastructure vs. trusting a SAAS that sits in between the exchange and =
the merchants infrastructure.</div><div><br class=3D""></div><div>In =
general adapters would create additional risks to think about, depending =
on how fine-tuned the API key permissions are. E.g. if API keys come =
with full permissions you don=E2=80=99t want to install an adaptor =
plugin if your shop is hosted on <a href=3D"http://wordpress.com" =
class=3D"">wordpress.com</a>. PayPal and Stripe make sure their API keys =
can=E2=80=99t do too much damage in case the merchant shop hosting is =
compromised.</div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D""><span style=3D"font-size:12.8px" =
class=3D"">&gt;&nbsp;</span><span style=3D"font-size:12.8px" =
class=3D"">Can this be combined with an invoice mechanism similar to =
Lightning, e.g. where the exchange sends a pre-image to the users wallet =
(relayed via and retained by the web shop) upon receipt of the funds, =
which they can then present to the merchant in case something went =
wrong. Exchanges might be happy to support this protocol, but they =
don=E2=80=99t want the burden of dealing with user support requests, so =
having signed invoices could help with that.</span></div><div =
class=3D""><span style=3D"font-size:12.8px" class=3D""><br =
class=3D""></span></div><div class=3D""><span style=3D"font-size:12.8px" =
class=3D"">This protocol can be expanded later for lightning trivially, =
where the call to the address source uri also returns a lightning =
payment request. (BOLT11)</span></div></div></div></blockquote><div><br =
class=3D""></div><div>I didn=E2=80=99t mean adding Lightning support =
(though that would be cool), I mean adding an invoice system to your =
proposal that is similar to how Lightning invoices work. Right now if =
the customer pays and the merchant has a poorly functioning shopping =
cart system, which I=E2=80=99ve seen more often than not, the customer =
would have to email their transaction id to the merchant, who then needs =
to login to their exchange to check if that address indeed belongs to =
them. But a merchant shouldn=E2=80=99t give all their support staff such =
access, and support staff may not have the right training, or even =
permission, to assess whether a transaction is cleared (=E2=80=9Ccomputer =
says no").</div><div><br class=3D""></div><div>So you=E2=80=99d want =
some sort of signed message as part of the protocol that says =E2=80=9Cif =
this transaction ID confirms, this order ID is paid for=E2=80=9D. &nbsp; =
Although this specific example wouldn=E2=80=99t play well with RBF. So =
maybe =E2=80=9Cif the confirmed balance of this address is &gt;=3D X, =
this order ID is paid for=E2=80=9D, but then the exchange can=E2=80=99t =
sweep it. So maybe instead you need a callback from the exchange to just =
tell you when it=E2=80=99s (expected to be) confirmed. BitPay offers =
merchants various risk settings for this, so that might be worth looking =
into.&nbsp;</div><div><br =
class=3D""></div><div>Sjors</div></div></body></html>=

--Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3--

--Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlo7eSwACgkQV/+b28ww
EAlITRAAsvtVX0nm1NZwseKSfdwm6XAmcJMUHTvVfVlNoShfyTbcvb3SkrV9MbLu
qJZZzrNrOGdP5ZoA+8V+GfXl86Cnr5bse8L8ELinBOr6RVLtU4V3Nvvz8meduAGU
gAUIG6/XhDL4bf/zKVHKfZprG/UrJkOwzTwE8i0kYJ2z2iELTv9doDAdoGH0tqWo
9VSHtBIpmm3UPMqOj1naSzn2OwCtzUAdZcqwY7So42FOGzlAlgFAgHN+l/Yx43MT
LqWh5foP2OPMj13LgsbN32oNX99NfptVwOGPYSwiZlX6mDs5HGeQJ3a16cw9Fppm
BuI7DZ1zVdT+anNdpVQzQbci6qlSdBASfz68GI022kFAVDwMluAbG12WqtKAYl0m
6CY7kt2oWL8uEhmHRfK5OIgKlWbYc3zEhkXg/+0sn1mCyI92PxZv59N/ELpDd528
ZNlQhm1tJLpBvVI1LVR0WXdye97thitZxNlVbWDWNWL6c2SvprVUizgqBZqAe8Ik
T9tQGMnRipa39TuzogprmbUPzVBTXullC8LDnyImQdqgsFlUgRF7K+ZCuJ8Pk+vk
1OhTklFLF0knwQR/Hgj/iRB24WZo/Gz+2TbWrJeXzP9PqNGckA7Z1UaFIC5RQnzn
nTqINVyU36orMjKS5eKohrXOfD2BbZPemrXvRoXhHXnyPor+BRU=
=wpIj
-----END PGP SIGNATURE-----

--Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95--