path: root/f1/561bbed74a453c9f62a79407a8b91d515079dc

Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9903171F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 20 Dec 2017 08:49:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
	[66.111.4.27])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADE6087
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 20 Dec 2017 08:49:13 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id A1A5120BFE;
	Wed, 20 Dec 2017 03:49:12 -0500 (EST)
Received: from frontend2 ([10.202.2.161])
	by compute1.internal (MEProxy); Wed, 20 Dec 2017 03:49:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
	content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; bh=mIDsB9NmnZ6Tgt/WdXgXJCteDH8+ykMu6MepVXEWzbE=; b=KOLPcUbs
	bRi7Cs2nmdEZeLfMkrAJjqahlyAF9wgnZqzJM0jJQSc6zD6HYm8jZlgtPlpG3HKo
	1WVdXEEr6sB6I6MnNP5bvTRexLDLOieUzJ70HLGra6RVuakOR8eLuXIoiuyIZFea
	HDj1zRtwdh0pg8y1VPYWjT84zrjlBCoa3yhpoGijv/wiv8FpjWay1w9ImGKtdUrJ
	WSsEi16RI7RNuj93wEiT91ALnBbPUxWv7ntEqujdbYVvYYIx4wgEMokeTjlyXw25
	Ia415MmamR7fheSTtI9Z7opUr81n4I+FkeguH0nKucrXtQ3slK+8nMSUDDjecbZY
	BMNmMGSYwcaBvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; bh=mIDsB9NmnZ6Tgt/WdXgXJCteDH8+y
	kMu6MepVXEWzbE=; b=X6fWKJTakS2sWOz8xaWFOaR2gTy4765fYjiMPe4lzWz3o
	tysHfQM5RRO1DlRnvie8tjRzyVvqcZ2fOK8GC0yzgUAquft+I3lu4gmjNoyp10BR
	Ng/mBkgc4fL9IRcklPpVDbIANDZ0isphiANQybyhpREdKFOJevkj/UaN9yDAETFx
	N+aGw1VqApRCb/UdcqgI2XbZTqV2Uowf0ifwZSCVE/5Kz6c54Mjd9/q5dt74D1uC
	CrSp9rXqBuFqKeBHSPfjgwQdWxFxvFGITzdFLS7CQbiXQAwWJ66wkzpi0k7Jen+7
	Ajg04oqdQa+oSIv//+PzzedcRA6Gka+UwDvihBzcA==
X-ME-Sender: <xms:CCQ6WhmnZ1MHAW9nCk_DPFnzWmtjvgWxdaxA-TZMgdbF1WOkZfZJnw>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
	[84.105.61.15])
	by mail.messagingengine.com (Postfix) with ESMTPA id B4BE8240F6;
	Wed, 20 Dec 2017 03:49:11 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 20 Dec 2017 09:49:09 +0100
References: <CA+1nnr=-6UkJT=TWjDHhZtXsic8p0fzQ=Yk1tSqkhL+NuvqCQw@mail.gmail.com>
To: Nicolas Dorier <nicolas.dorier@gmail.com>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CA+1nnr=-6UkJT=TWjDHhZtXsic8p0fzQ=Yk1tSqkhL+NuvqCQw@mail.gmail.com>
Message-Id: <A2014DA0-F6F8-470F-A167-E66723281269@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.5.20)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,
	TVD_PH_BODY_ACCOUNTS_PRE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 20 Dec 2017 15:17:16 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 08:49:15 -0000


--Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8"


--Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



I think this could be quite useful, although I don=E2=80=99t know if it =
will get adopted. If any such small local exchanges want to weigh in on =
this proposal, that would help. Same goes for shopping cart integrators, =
e.g. the folks writing WooCommerce and Shopify plugins.

Consider adding some requirements around the use of SSL and certificate =
pinning. Can you refer to the kind of best practices Stripe and PayPal =
recommend? Should some additional shared-secret or cookie / macaroon =
based authentication be added?

Can you clarify if this integration can run in a browser, or due to =
security / privacy constraints must be server-to-server?

Though it=E2=80=99s important to remain future-proof by being flexible, =
leaving the above details to individual implementers is probably going =
to result in bad things.

What are your thoughts on rate limiting vs. privacy? Should a payment =
source never return the same address even if nothing is paid to it? =
Otherwise someone could just crawl webshops to create an inventory of =
payment addresses. A new address every page reload could be a DDOS =
vector. It also wouldn't be compatible with BIP44 because of its gap =
limit, although I don=E2=80=99t think that=E2=80=99s a huge problem for =
exchanges.

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.

I would consider a more specific name like Delegated UTXO or something. =
=E2=80=9CExchange=E2=80=9D suggests is more like 0X or Bisq.

Speaking of Bisq, it would be neat if merchants can rely on random peer =
to peer counterparties to convert to fiat, so their customer information =
and revenue figures aren=E2=80=99t in the hands of a single counter =
party. Obviously that=E2=80=99s a can of worms today, but it would be =
nice if the protocol was able to support that if one day someone figures =
out the fraud, compliance and bookkeeping stuff.

Finally, why only exchanges? It could make sense fo shopping cart =
software to talk to a Bitcoin wallet that=E2=80=99s hosted somewhere =
else for similar reasons. Right now the best these plugins can do is =
hold on to an XPUB, and I=E2=80=99ve even seen solutions that just send =
the customers coins to their own backend wallet and then forward it.

Sjors

> Op 20 dec. 2017, om 07:28 heeft Nicolas Dorier via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> Hi everyone,
>=20
> As some of you know, I am working on a complete open source =
replacement of Bitpay for allowing merchant to accept cryptocurrency =
payments while having a way to sell automatically.
>=20
> A crucial, missing part, is fiat conversion. And I figured out a =
simple protocol that exchanges (or adapters) can implement to allow any =
merchant to cash out BTC in fiat while giving them the freedom to choose =
their own payment processor solution.
>=20
> This also have positive impact on scalability: Before, a merchant =
would receive the bitcoin from the customer then would send to the =
exchange, resulting in two transactions.
> With this specification, it would be one transaction.
>=20
> Special thanks to anditto and kallewoof for reviewing. I am waiting =
for your feedback:
>=20
> Github link: =
https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki =
<https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki>
>=20
> <pre>
>   BIP: XXX
>   Layer: Applications
>   Title: Crypto Open Exchange Protocol (COX)
>   Author: Nicolas Dorier <nicolas.dorier@gmail.com =
<mailto:nicolas.dorier@gmail.com>>
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX =
<https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX>
>   Status: Draft
>   Type: Standards Track
>   Created: 2017-12-20
>   License: BSD-3-Clause
>            CC0-1.0
> </pre>
>=20
> =3D=3DAbstract=3D=3D
>=20
> A simple protocol for decoupling payment processor solutions from =
exchanges.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Cryptocurrency merchant adoption is mainly driven by availability, =
ease of use and means of acceptance.
> We call such solutions `Payment Processors`.
>=20
> Until now, payment processing solutions fall into one of the two =
following categories:
>=20
> # Self-hosted with the customer paying in cryptocurrency and the =
merchant receiving it directly.
> # Centralized, coupled with an exchange feature, with the customer =
paying in cryptocurrency to the merchant, and receiving fiat or =
cryptocurrency on his exchange account.
>=20
> The self-hosted solution has two issues:
>=20
> # The merchant becomes vulnerable to the wild volatility of =
cryptocurrencies.
> # It is wasteful of blockchain space, if the merchant does not pay =
suppliers in crypto, as they need a second transaction to change to his =
exchange,
>=20
> The centralized solution has two issues:
>=20
> # It locks-in the merchant to a particular payment processor whose =
intentions might not be aligned (e.g. Bitpay who tried to redefine =
Bitcoin as being a different chain, without merchant approval)
> # It has to deal with local regulations (e.g. Bitpay does not provide =
fiat CAD to canadian merchants)
>=20
> The goal of this BIP is to specify a simple protocol which makes =
possible decoupling of payment processors from exchanges.
>=20
> We believe this BIP will gather a lot of interest among local =
exchanges which do not have the resources to develop their own payment =
solutions.
>=20
> Their customers can decide which payment processor solution they =
prefer, while the exchanges give them a way to protect against =
cryptocurrency volatility.
>=20
> =3D=3DSummary=3D=3D
>=20
> The merchant log in to its exchange website, go into "Address sources" =
section of it, an click on "Create a new address source".
>=20
> The address source creation wizard asks him questions about what to do =
when crypto currency is sent to this the address source. =
(Cryptocurrency, Market sell order, limit order of past day average =
etc...)
>=20
> The merchant receives an "address source URI" which they can input =
inside the payment processor.
>=20
> An exchange compatible with the Crypto Open Exchange Protocol would =
reply to any HTTP POST request to this  "address source URI" returning =
the following information (more details in the Specification part)
>=20
> # A deposit address for accepting a payment
> # The current rate
> # Optional: If the exchange is willing to take the risk of rate =
fluctuation, until when this rate is guaranteed and under which =
conditions.
>=20
> <img src=3D"bip-xxx/overview.png"></img>
>=20
> =3D=3D=3DInteraction=3D=3D=3D
>=20
> * Manny (the "merchant") wants to accept Bitcoin payments on his =
e-commerce website.
> * Manny chooses the payment processor "PROCCO" which has a powerful =
plugin for his e-commerce website.
> * Manny is based in Canada and already has an account on the exchange =
"MYCOIN" which supports the Crypto Open Exchange Protocol.
> * Manny connects to the exchange website, and creates a new address =
source.
> * In the configuration screen of the address source, for each payment =
sent to this address source, Manny decides to keep 30% in Bitcoin and =
place a market sell order for the remaining 70% of the amount.
> * "MYCOIN" creates the address source, and gives the "address source =
URI" to the merchant. (e.g. =
https://example.com/addresssources/abd29ddn92 =
<https://example.com/addresssources/abd29ddn92>)
> * Manny copies the address source URI and goes inside "PROCCO" =
settings, and configures his store to use this address source URI.
>=20
> Now a customer, Carol, wants to order a brand new phone for 0.01 BTC =
on Manny's store and decides to pay in Bitcoin.
>=20
> * The E-Commerce website plugin requests the creation of an invoice =
from PROCCO.
> * PROCCO queries the "address source URI" and retrieves the rate, the =
expiration of this rate and conditions.
> * PROCCO can now show the Bitcoin Payment Checkout page.
> * Carla pays.
> * PROCCO marks the payment as paid and redirects to the e-commerce =
website.
> * MYCOIN, under its own policy (typically after 6 confirmations), =
credits Manny's account of 0.01 BTC and simultaneously creates a market =
sell order of 0.007 BTC on behalf of Manny.
>=20
> =3D=3DSpecification=3D=3D
>=20
> The payment processor sends a POST request to the "address source =
URI", the response from a Crypto Open Exchange Protocol exchange would =
be:
>=20
> If the exchange does not guarantee the rate:
>=20
>     {
>         "depositAddress" : "13....abd",
>         "currencyCode" : "CAD",
>         "cryptoCurrencyCode" : "BTC",
>         "rate" : "15600",
>         # When the merchant account get credited on the exchange
>         "requiredConfirmations" : blockcount
>     }
>=20
>=20
> If the exchange guarantee the rate:
>=20
>     {
>         "depositAddress" : "13....abd",
>         "currencyCode" : "CAD",
>         "cryptoCurrencyCode" : "BTC",
>         "rate" : "15600",
>         "requiredConfirmations" : blockcount
>         "conditions" :
>         {
>             # When the transaction should be seen on the blockchain to =
guarantee the rate
>             "receivedBefore" : timestamp,
>             # When the transaction should be confirmed on the =
blockchain to guarantee the rate
>             "confirmedBefore" : timestamp
>         }
>     }
>=20
>=20
> The payment processor is responsible for giving feedback to the =
customer if the fees of the received transaction are not enough to =
guarantee the rate.
>=20
> =3D=3DNote on adoption=3D=3D
>=20
> While local exchanges have incentives to implement this simple =
protocol, it is not strictly needed.
>=20
> An alternative is to develop an adapter server which expose Crypto =
Open Exchange Protocol endpoint and connect to underlying exchange's =
API.
>=20
> The only downside is that the rate can't be guaranteed.
>=20
> =3D=3DCopyright=3D=3D
>=20
> This document is dual licensed as BSD 3-clause, and Creative Commons =
CC0 1.0 Universal.
>=20
>=20
> Nicolas,
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8
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""><br =
class=3D""><div class=3D""><br class=3D""></div><div class=3D"">I think =
this could be quite useful, although I don=E2=80=99t know if it will get =
adopted. If any such small local exchanges want to weigh in on this =
proposal, that would help. Same goes for shopping cart integrators, e.g. =
the folks writing WooCommerce and Shopify plugins.&nbsp;</div><div =
class=3D""><br class=3D""></div><div class=3D"">Consider adding some =
requirements around the use of SSL and certificate pinning. Can you =
refer to the kind of best practices Stripe and PayPal recommend? Should =
some additional shared-secret or cookie / macaroon based authentication =
be added?&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">Can you clarify if this integration can run in a browser, or =
due to security / privacy constraints must be =
server-to-server?</div><div class=3D""><br class=3D""></div><div =
class=3D"">Though it=E2=80=99s important to remain future-proof by being =
flexible, leaving the above details to individual implementers is =
probably going to result in bad things.</div><div class=3D""><br =
class=3D""></div><div class=3D"">What are your thoughts on rate limiting =
vs. privacy? Should a payment source never return the same address even =
if nothing is paid to it? Otherwise someone could just crawl webshops to =
create an inventory of payment addresses. A new address every page =
reload could be a DDOS vector. It also wouldn't be compatible with BIP44 =
because of its gap limit, although I don=E2=80=99t think that=E2=80=99s =
a huge problem for exchanges.</div><div class=3D""><br =
class=3D""></div><div 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.</div><div class=3D""><br class=3D""></div><div class=3D"">I would =
consider a more specific name like Delegated UTXO or something. =
=E2=80=9CExchange=E2=80=9D suggests is more like 0X or Bisq.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Speaking of Bisq, it =
would be neat if merchants can rely on random peer to peer =
counterparties to convert to fiat, so their customer information and =
revenue figures aren=E2=80=99t in the hands of a single counter party. =
Obviously that=E2=80=99s a can of worms today, but it would be nice if =
the protocol was able to support that if one day someone figures out the =
fraud, compliance and bookkeeping stuff.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Finally, why only exchanges? It could =
make sense fo shopping cart software to talk to a Bitcoin wallet =
that=E2=80=99s hosted somewhere else for similar reasons. Right now the =
best these plugins can do is hold on to an XPUB, and I=E2=80=99ve even =
seen solutions that just send the customers coins to their own backend =
wallet and then forward it.</div><div class=3D""><br class=3D""></div><div=
 class=3D"">Sjors</div><div class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">Op 20 dec. 2017, om 07:28 heeft =
Nicolas Dorier via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; het volgende =
geschreven:</div><br class=3D"Apple-interchange-newline"><div =
class=3D""><div dir=3D"ltr" class=3D"">Hi everyone,<div class=3D""><br =
class=3D""></div><div class=3D"">As some of you know, I am working on a =
complete open source replacement of Bitpay for allowing merchant to =
accept cryptocurrency payments while having a way to sell =
automatically.</div><div class=3D""><br class=3D""></div><div class=3D"">A=
 crucial, missing part, is fiat conversion. And I figured out a simple =
protocol that exchanges (or adapters) can implement to allow any =
merchant to cash out BTC in fiat while giving them the freedom to choose =
their own payment processor solution.</div><div class=3D""><br =
class=3D""></div><div class=3D"">This also have positive impact on =
scalability: Before, a merchant would receive the bitcoin from the =
customer then would send to the exchange, resulting in two =
transactions.</div><div class=3D"">With this specification, it would be =
one transaction.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Special thanks to anditto and kallewoof for reviewing. I am =
waiting for your feedback:</div><div class=3D""><br class=3D""></div><div =
class=3D"">Github link:&nbsp;<a =
href=3D"https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawik=
i" =
class=3D"">https://github.com/NicolasDorier/bips/blob/master/bip-xxx.media=
wiki</a></div><div class=3D""><br class=3D""></div><div class=3D""><div =
class=3D"">&lt;pre&gt;</div><div class=3D"">&nbsp; BIP: XXX</div><div =
class=3D"">&nbsp; Layer: Applications</div><div class=3D"">&nbsp; Title: =
Crypto Open Exchange Protocol (COX)</div><div class=3D"">&nbsp; Author: =
Nicolas Dorier &lt;<a href=3D"mailto:nicolas.dorier@gmail.com" =
class=3D"">nicolas.dorier@gmail.com</a>&gt;</div><div class=3D"">&nbsp; =
Comments-Summary: No comments yet.</div><div class=3D"">&nbsp; =
Comments-URI: <a =
href=3D"https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX" =
class=3D"">https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX</a></div>=
<div class=3D"">&nbsp; Status: Draft</div><div class=3D"">&nbsp; Type: =
Standards Track</div><div class=3D"">&nbsp; Created: =
2017-12-20</div><div class=3D"">&nbsp; License: BSD-3-Clause</div><div =
class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CC0-1.0</div><div =
class=3D"">&lt;/pre&gt;</div><div class=3D""><br class=3D""></div><div =
class=3D"">=3D=3DAbstract=3D=3D</div><div class=3D""><br =
class=3D""></div><div class=3D"">A simple protocol for decoupling =
payment processor solutions from exchanges.</div><div class=3D""><br =
class=3D""></div><div class=3D"">=3D=3DMotivation=3D=3D</div><div =
class=3D""><br class=3D""></div><div class=3D"">Cryptocurrency merchant =
adoption is mainly driven by availability, ease of use and means of =
acceptance.</div><div class=3D"">We call such solutions `Payment =
Processors`.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Until now, payment processing solutions fall into one of the =
two following categories:</div><div class=3D""><br class=3D""></div><div =
class=3D""># Self-hosted with the customer paying in cryptocurrency and =
the merchant receiving it directly.</div><div class=3D""># Centralized, =
coupled with an exchange feature, with the customer paying in =
cryptocurrency to the merchant, and receiving fiat or cryptocurrency on =
his exchange account.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The self-hosted solution has two issues:</div><div =
class=3D""><br class=3D""></div><div class=3D""># The merchant becomes =
vulnerable to the wild volatility of cryptocurrencies.</div><div =
class=3D""># It is wasteful of blockchain space, if the merchant does =
not pay suppliers in crypto, as they need a second transaction to change =
to his exchange,</div><div class=3D""><br class=3D""></div><div =
class=3D"">The centralized solution has two issues:</div><div =
class=3D""><br class=3D""></div><div class=3D""># It locks-in the =
merchant to a particular payment processor whose intentions might not be =
aligned (e.g. Bitpay who tried to redefine Bitcoin as being a different =
chain, without merchant approval)</div><div class=3D""># It has to deal =
with local regulations (e.g. Bitpay does not provide fiat CAD to =
canadian merchants)</div><div class=3D""><br class=3D""></div><div =
class=3D"">The goal of this BIP is to specify a simple protocol which =
makes possible decoupling of payment processors from =
exchanges.</div><div class=3D""><br class=3D""></div><div class=3D"">We =
believe this BIP will gather a lot of interest among local exchanges =
which do not have the resources to develop their own payment =
solutions.</div><div class=3D""><br class=3D""></div><div class=3D"">Their=
 customers can decide which payment processor solution they prefer, =
while the exchanges give them a way to protect against cryptocurrency =
volatility.</div><div class=3D""><br class=3D""></div><div =
class=3D"">=3D=3DSummary=3D=3D</div><div class=3D""><br =
class=3D""></div><div class=3D"">The merchant log in to its exchange =
website, go into "Address sources" section of it, an click on "Create a =
new address source".</div><div class=3D""><br class=3D""></div><div =
class=3D"">The address source creation wizard asks him questions about =
what to do when crypto currency is sent to this the address source. =
(Cryptocurrency, Market sell order, limit order of past day average =
etc...)</div><div class=3D""><br class=3D""></div><div class=3D"">The =
merchant receives an "address source URI" which they can input inside =
the payment processor.</div><div class=3D""><br class=3D""></div><div =
class=3D"">An exchange compatible with the Crypto Open Exchange Protocol =
would reply to any HTTP POST request to this&nbsp; "address source URI" =
returning the following information (more details in the Specification =
part)</div><div class=3D""><br class=3D""></div><div class=3D""># A =
deposit address for accepting a payment</div><div class=3D""># The =
current rate</div><div class=3D""># Optional: If the exchange is willing =
to take the risk of rate fluctuation, until when this rate is guaranteed =
and under which conditions.</div><div class=3D""><br class=3D""></div><div=
 class=3D"">&lt;img src=3D"bip-xxx/overview.png"&gt;&lt;/img&gt;</div><div=
 class=3D""><br class=3D""></div><div =
class=3D"">=3D=3D=3DInteraction=3D=3D=3D</div><div class=3D""><br =
class=3D""></div><div class=3D"">* Manny (the "merchant") wants to =
accept Bitcoin payments on his e-commerce website.</div><div class=3D"">* =
Manny chooses the payment processor "PROCCO" which has a powerful plugin =
for his e-commerce website.</div><div class=3D"">* Manny is based in =
Canada and already has an account on the exchange "MYCOIN" which =
supports the Crypto Open Exchange Protocol.</div><div class=3D"">* Manny =
connects to the exchange website, and creates a new address =
source.</div><div class=3D"">* In the configuration screen of the =
address source, for each payment sent to this address source, Manny =
decides to keep 30% in Bitcoin and place a market sell order for the =
remaining 70% of the amount.</div><div class=3D"">* "MYCOIN" creates the =
address source, and gives the "address source URI" to the merchant. =
(e.g. <a href=3D"https://example.com/addresssources/abd29ddn92" =
class=3D"">https://example.com/addresssources/abd29ddn92</a>)</div><div =
class=3D"">* Manny copies the address source URI and goes inside =
"PROCCO" settings, and configures his store to use this address source =
URI.</div><div class=3D""><br class=3D""></div><div class=3D"">Now a =
customer, Carol, wants to order a brand new phone for 0.01 BTC on =
Manny's store and decides to pay in Bitcoin.</div><div class=3D""><br =
class=3D""></div><div class=3D"">* The E-Commerce website plugin =
requests the creation of an invoice from PROCCO.&nbsp;</div><div =
class=3D"">* PROCCO queries the "address source URI" and retrieves the =
rate, the expiration of this rate and conditions.</div><div class=3D"">* =
PROCCO can now show the Bitcoin Payment Checkout page.</div><div =
class=3D"">* Carla pays.</div><div class=3D"">* PROCCO marks the payment =
as paid and redirects to the e-commerce website.</div><div class=3D"">* =
MYCOIN, under its own policy (typically after 6 confirmations), credits =
Manny's account of 0.01 BTC and simultaneously creates a market sell =
order of 0.007 BTC on behalf of Manny.</div><div class=3D""><br =
class=3D""></div><div class=3D"">=3D=3DSpecification=3D=3D</div><div =
class=3D""><br class=3D""></div><div class=3D"">The payment processor =
sends a POST request to the "address source URI", the response from a =
Crypto Open Exchange Protocol exchange would be:</div><div class=3D""><br =
class=3D""></div><div class=3D"">If the exchange does not guarantee the =
rate:</div><div class=3D""><br class=3D""></div><div class=3D"">&nbsp; =
&nbsp; {</div><div class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; =
"depositAddress" : "13....abd",</div><div class=3D"">&nbsp; &nbsp; =
&nbsp; &nbsp; "currencyCode" : "CAD",</div><div class=3D"">&nbsp; &nbsp; =
&nbsp; &nbsp; "cryptoCurrencyCode" : "BTC",</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; "rate" : "15600",</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; # When the merchant account get credited on the =
exchange</div><div class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; =
"requiredConfirmations" : blockcount</div><div class=3D"">&nbsp; &nbsp; =
}</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">If the exchange guarantee the =
rate:</div><div class=3D""><br class=3D""></div><div class=3D"">&nbsp; =
&nbsp; {</div><div class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; =
"depositAddress" : "13....abd",</div><div class=3D"">&nbsp; &nbsp; =
&nbsp; &nbsp; "currencyCode" : "CAD",</div><div class=3D"">&nbsp; &nbsp; =
&nbsp; &nbsp; "cryptoCurrencyCode" : "BTC",</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; "rate" : "15600",</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; "requiredConfirmations" : blockcount</div><div =
class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; "conditions" :&nbsp;</div><div =
class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; {</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # When the transaction should be seen =
on the blockchain to guarantee the rate</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; "receivedBefore" : =
timestamp,</div><div class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; # When the transaction should be confirmed on the blockchain to =
guarantee the rate</div><div class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; "confirmedBefore" : timestamp</div><div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; }</div><div class=3D"">&nbsp; &nbsp; }</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">The payment processor is responsible for giving feedback to =
the customer if the fees of the received transaction are not enough to =
guarantee the rate.</div><div class=3D""><br class=3D""></div><div =
class=3D"">=3D=3DNote on adoption=3D=3D</div><div class=3D""><br =
class=3D""></div><div class=3D"">While local exchanges have incentives =
to implement this simple protocol, it is not strictly needed.</div><div =
class=3D""><br class=3D""></div><div class=3D"">An alternative is to =
develop an adapter server which expose Crypto Open Exchange Protocol =
endpoint and connect to underlying exchange's API.</div><div =
class=3D""><br class=3D""></div><div class=3D"">The only downside is =
that the rate can't be guaranteed.</div><div class=3D""><br =
class=3D""></div><div class=3D"">=3D=3DCopyright=3D=3D</div><div =
class=3D""><br class=3D""></div><div class=3D"">This document is dual =
licensed as BSD 3-clause, and Creative Commons CC0 1.0 =
Universal.</div></div><div class=3D""><div class=3D""><br =
class=3D""></div></div><div class=3D""><br class=3D""></div><div =
class=3D"">Nicolas,</div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8--

--Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD
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/+b28wwEAkFAlo6JAUACgkQV/+b28ww
EAlQShAArarVXEfutFB4TYnD8seBXVcLMFv42FnqcMJgaaeJrkOrWPOYHw4lIqHe
S4wUnUeRPAczUIjBrV6q3jdIzjhevgZN3ekgUs4NVp2fN9RFJZkxB1sqiroCYk7J
UDSQYzgv/AeeBMSH0TeulPcA47rzpTT+eCpgoCcKizuWT8RnohYJF76b1pgmUxlX
KThcPtuNVE8X5nVGVAkesBmBGjZxfqaObDhLWSPQ3cA2XtlNUPdhzQqTPczYD5h7
ZN/2AsoptEHZ5pFmqpWOHAIMsz1825QDy1uDK+ofLVP4zlfK1KA0K8k44XRmrSxA
aCGBOJymkkbGE3krOkfofV7uPGF/Tawh2DWrIWC+/h/UgUVXiRHHBRltxRr60Kdv
57GnUegw9RbFJ4OnxDIVHz7NBecMWpB774lF6S9O1H/ODTU2DKfo7uqHSFHVIBwo
sHh5ni3WPiyengvoxLAeW6Cm2oaFmXHiMexlzPfDOwZvG/Ee5mjebARTYdagKuv3
46N4b8CaRmqnwUkph4/XMXQbSeVC6HSRaQoSEpnUxsI66zLVtk4Ox+a+17S3opWI
jha2wzoBX1LX0CdgH1U8Q2G/ESbyVwyXyR+ZbyU4ysi/s2eNlMBOXLyE3j5YNfds
pOT1dYCxzDaYBBh4T+06350WiorNonUE/plfOE5zetpj143+AJ4=
=/Zdv
-----END PGP SIGNATURE-----

--Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD--