Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B8810A80 for ; Thu, 21 Dec 2017 08:20:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D9C9405 for ; Thu, 21 Dec 2017 08:20:33 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id y82so18986335wmg.1 for ; Thu, 21 Dec 2017 00:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ujY3BLwHlWpG8L5lqnk8y0UPep4EDaFhZC+7N74OuII=; b=nvccwqUmGCu1BDSWvQhX2p0zxZgS+/RMaCcNpbLugtFy00vQdsRZgWOkcg1faYVET9 mD6H1dFvM5PtP6XuJb9DObfL8IQyL34Ov9U5KUkgCI3eePPKBm1o3VP/obnMVtvYBcZm LPLMvhaqbh+EcAycKYc3YQCCqTiOgrzw3PzocbBZAz9RXRsiSI7RDEsd+gKyx3HquzfR FGU/8jXvC0oyJgI1uV7iKcdcfYBygYwups5BC/TVGeL9F4o7WqmhGZoGbMF5ryq4TyWp pa0jvFX5+aLvihLTb670HiNFrVyBxxA1w74B5zNn1MQYYyQShYQg2USMJvi09sLfqact Zkzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ujY3BLwHlWpG8L5lqnk8y0UPep4EDaFhZC+7N74OuII=; b=XBklIYMK98m+p98FSfQ6Yrc0yqNSJRef6bMlJayXLn5vCJQbypf6ZyrGTQ4akgMqZn tCa4spPbA0WaN1I8MZHsJbDnjt2SSRUgZtrx5CLtAWQm+sBZ9YWqWIG+HUj3JHFQ3mMd 4N9ElC0mPwoZ61KUyLGcWgnqLr+8stCKWFmM2tdXRrPyypuzwgUYgo6WxD9HtyjR3JKJ B2akADPl0MNh1ahXvrHU/XIP7us0lwVxX5BqczF/iP/z5Lp+RDgsLUUEX9kvajFw+qr0 fLS+l6RTVljtD0nCS8IxoUTVM1MbkeHpNCpZMy8JMMOkaEh4Aj/8vj9QsMuswkDygkTj 2mXA== X-Gm-Message-State: AKGB3mKFpKyMgXB/vcZH3H4Z31f/DMjwMlO9RDsj1OQkir0o8KB+7Iqz +bskQ2W4cqGPp0pgASBELKte2NC9LlV/uyE94FA= X-Google-Smtp-Source: ACJfBouLS/p5Eee5Rep4tq4W9AEZ8DBswY4fABUgHTiYSY+HIFd7B+ys/Q2yQ5q/0hXnm8Msk25Xb8QTUxK5VsSrl3o= X-Received: by 10.80.183.196 with SMTP id i4mr9091657ede.280.1513844431652; Thu, 21 Dec 2017 00:20:31 -0800 (PST) MIME-Version: 1.0 Sender: slashene@gmail.com Received: by 10.80.172.79 with HTTP; Thu, 21 Dec 2017 00:20:11 -0800 (PST) In-Reply-To: References: From: Nicolas Dorier Date: Thu, 21 Dec 2017 17:20:11 +0900 X-Google-Sender-Auth: u00CRB6MaVAKxmXDORcCWfJwQ70 Message-ID: To: Sjors Provoost , lc@humble.af Content-Type: multipart/alternative; boundary="94eb2c0df368980c740560d55fed" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, 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 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:20:35 -0000 --94eb2c0df368980c740560d55fed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot for the feedback > I think this could be quite useful, although I don=E2=80=99t know if it w= ill get adopted. 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. Collaboration with the exchange is only needed if the exchange wants to provide a service for taking the risk of volatility. > I have personally been integrating BitPay into a website for payments in BTC and like what you are trying to do. One of the biggest hurdle=E2=80=99= s I see for merchants to adopt BitCoin today is the transaction fee. This BIP supports alternatives currencies. > 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? Yes, I must add guidelines (SSL and how to manage the addresses). I don't think authentication is needed as the merchant is the only one having access to the source URI. This can be considered as a shared secret. Even if this secret leaks, no funds are in danger. > Can you clarify if this integration can run in a browser, or due to security / privacy constraints must be server-to-server? Thanks, I need to clarify the scope. But indeed, this is not meant to be used by a browser, as merchants will not host their payment processors on their mobile or browser. > Though it=E2=80=99s important to remain future-proof by being flexible, l= eaving the above details to individual implementers is probably going to result in bad things. Thanks, I think you are right I should add more recommendations for implementers. > 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. You are right, I must introduce a sort of "order id" so that one order map to exactly one address response. The DDOS vector will then be on the shoulder of the ecommerce website by preventing users to create too much orders. (they certainly already do) > 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 d= ealing with user support requests, so having signed invoices could help with that. This protocol can be expanded later for lightning trivially, where the call to the address source uri also returns a lightning payment request. (BOLT11= ) > 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. Conversion to fiat always need trust, so we must rule out anonymous parties. If you want to spread on several trusted party, this can be done transparently at the payment processor level, and does not requires change to the protocol. > 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 f= or 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 coi= ns to their own backend wallet and then forward it. Because BIP70/XPUB already solves the problem. (Which I already use in BTCPay) BIP70 is a pain in the ass to implement and does not provide any benefits, and it does not define a way for the exchange to communicate a rate attached to the bitcoin address, nor define a way to communicate to the payment processor the conditions under which they can bear volatility risk. I will revisit the BIP based on your feedback. Nicolas, On Wed, Dec 20, 2017 at 5:49 PM, Sjors Provoost wrote: > > > I think this could be quite useful, although I don=E2=80=99t know if it w= ill 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 base= d > 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, l= eaving > 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 exchange= s. > > 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 tha= t. > > 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 t= o > 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. Ob= viously > 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 softwar= e > to talk to a Bitcoin wallet that=E2=80=99s hosted somewhere else for simi= lar > reasons. Right now the best these plugins can do is hold on to an XPUB, a= nd > I=E2=80=99ve even seen solutions that just send the customers coins to th= eir 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: > > Hi everyone, > > As some of you know, I am working on a complete open source replacement o= f > Bitpay for allowing merchant to accept cryptocurrency payments while havi= ng > a way to sell automatically. > > 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. > > 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. > > Special thanks to anditto and kallewoof for reviewing. I am waiting for > your feedback: > > Github link: https://github.com/NicolasDorier/bips/blob/ > master/bip-xxx.mediawiki > > 
>   BIP: XXX
>   Layer: Applications
>   Title: Crypto Open Exchange Protocol (COX)
>   Author: Nicolas Dorier 
>   Comments-Summary: No comments yet.
>   Comments-URI: 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
>
> > =3D=3DAbstract=3D=3D > > A simple protocol for decoupling payment processor solutions from > exchanges. > > =3D=3DMotivation=3D=3D > > Cryptocurrency merchant adoption is mainly driven by availability, ease o= f > use and means of acceptance. > We call such solutions `Payment Processors`. > > Until now, payment processing solutions fall into one of the two followin= g > categories: > > # 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 o= n > his exchange account. > > The self-hosted solution has two issues: > > # 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, > > The centralized solution has two issues: > > # It locks-in the merchant to a particular payment processor whose > intentions might not be aligned (e.g. Bitpay who tried to redefine Bitcoi= n > as being a different chain, without merchant approval) > # It has to deal with local regulations (e.g. Bitpay does not provide fia= t > CAD to canadian merchants) > > The goal of this BIP is to specify a simple protocol which makes possible > decoupling of payment processors from exchanges. > > 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. > > Their customers can decide which payment processor solution they prefer, > while the exchanges give them a way to protect against cryptocurrency > volatility. > > =3D=3DSummary=3D=3D > > The merchant log in to its exchange website, go into "Address sources" > section of it, an click on "Create a new address source". > > 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...) > > The merchant receives an "address source URI" which they can input inside > the payment processor. > > 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) > > # 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 condition= s. > > > > =3D=3D=3DInteraction=3D=3D=3D > > * Manny (the "merchant") wants to accept Bitcoin payments on his > e-commerce website. > * Manny chooses the payment processor "PROCCO" which has a powerful plugi= n > 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 sourc= e. > * In the configuration screen of the address source, for each payment sen= t > 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) > * Manny copies the address source URI and goes inside "PROCCO" settings, > and configures his store to use this address source URI. > > 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. > > * 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 websit= e. > * MYCOIN, under its own policy (typically after 6 confirmations), credits > Manny's account of 0.01 BTC and simultaneously creates a market sell orde= r > of 0.007 BTC on behalf of Manny. > > =3D=3DSpecification=3D=3D > > The payment processor sends a POST request to the "address source URI", > the response from a Crypto Open Exchange Protocol exchange would be: > > If the exchange does not guarantee the rate: > > { > "depositAddress" : "13....abd", > "currencyCode" : "CAD", > "cryptoCurrencyCode" : "BTC", > "rate" : "15600", > # When the merchant account get credited on the exchange > "requiredConfirmations" : blockcount > } > > > If the exchange guarantee the rate: > > { > "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 > } > } > > > 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. > > =3D=3DNote on adoption=3D=3D > > While local exchanges have incentives to implement this simple protocol, > it is not strictly needed. > > An alternative is to develop an adapter server which expose Crypto Open > Exchange Protocol endpoint and connect to underlying exchange's API. > > The only downside is that the rate can't be guaranteed. > > =3D=3DCopyright=3D=3D > > This document is dual licensed as BSD 3-clause, and Creative Commons CC0 > 1.0 Universal. > > > Nicolas, > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --94eb2c0df368980c740560d55fed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for the feedback

>= ; I think this could be quite useful, although I don=E2=80=99t know if it w= ill get adopted.

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

Collaboration with the excha= nge is only needed if the exchange wants to provide a service for taking th= e risk of volatility.

>=C2=A0I have personally been integrating BitPay into a website for= payments in BTC and like what you are trying to do.=C2=A0 One of the bigge= st hurdle=E2=80=99s I see for merchants to adopt BitCoin today is the trans= action fee.

This BIP supports alternatives cu= rrencies.

>=C2=A0=C2=A0Can you refer = to the kind of best practices Stripe and PayPal recommend? Should some addi= tional shared-secret or cookie / macaroon based authentication be added?=C2= =A0

Yes, I must add guidelines (SSL and how t= o manage the addresses). I don't think authentication is needed as the = merchant is the only one having access to the source URI. This can be consi= dered as a shared secret.
Even if this secret leaks, no funds are in danger.

>=C2=A0Can you clarify if= this integration can run in a browser, or due to security / privacy constr= aints must be server-to-server?

Thanks, I nee= d to clarify the scope. But indeed, this is not meant to be used by a brows= er, as merchants will not host their payment processors on their mobile or = browser.

>=C2=A0Though 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.

Thanks, I thi= nk you are right I should add more recommendations for implementers.=

>=C2=A0W= hat 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 som= eone 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.

You are right, I must introduce a sort of "order id" s= o that one order map to exactly one address response.
The DDOS vector will then be on the shoulder o= f the ecommerce website by preventing users to create too much orders. (the= y certainly already do)
<= br>
>=C2=A0Can this be combined with an invoice mechanism= similar to Lightning, e.g. where the exchange sends a pre-image to the use= rs wallet (relayed via and retained by the web shop) upon receipt of the fu= nds, which they can then present to the merchant in case something went wro= ng. 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 signe= d invoices could help with that.

This protoco= l can be expanded later for lightning trivially, where the call to the addr= ess source uri also returns a lightning payment request. (BOLT11)

>=C2=A0Spe= aking of Bisq, it would be neat if merchants can rely on random peer to pee= r counterparties to convert to fiat, so their customer information and reve= nue figures aren=E2=80=99t in the hands of a single counter party. Obviousl= y 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, complia= nce and bookkeeping stuff.

Conversion to fiat= always need trust, so we must rule out anonymous parties. If you want to s= pread on several trusted party, this can be done transparently at the payme= nt processor level, and does not requires change to the protocol.

>=C2=A0Fin= ally, 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 r= easons. 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 thei= r own backend wallet and then forward it.

Because BIP70/XPUB already solves th= e problem. (Which I already use in BTCPay)
BIP70 is a pain in the= ass to implement and does not provide any benefits, and it does not define= a way for the exchange to communicate a rate attached to the bitcoin addre= ss, nor define a way to communicate to the payment processor the conditions= under which they can bear volatility risk.

I will= revisit the BIP based on your feedback.

Nicolas,<= /div>

On Wed= , Dec 20, 2017 at 5:49 PM, Sjors Provoost <sjors@sprovoost.nl> wrote:


I think this cou= ld be quite useful, although I don=E2=80=99t know if it will get adopted. I= f any such small local exchanges want to weigh in on this proposal, that wo= uld help. Same goes for shopping cart integrators, e.g. the folks writing W= ooCommerce and Shopify plugins.=C2=A0

Consider add= ing some requirements around the use of SSL and certificate pinning. Can yo= u refer to the kind of best practices Stripe and PayPal recommend? Should s= ome additional shared-secret or cookie / macaroon based authentication be a= dded?=C2=A0

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

Though it=E2=80=99s important to remai= n future-proof by being flexible, leaving the above details to individual i= mplementers 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? Otherwi= se someone could just crawl webshops to create an inventory of payment addr= esses. A new address every page reload could be a DDOS vector. It also woul= dn'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 Light= ning, e.g. where the exchange sends a pre-image to the users wallet (relaye= d via and retained by the web shop) upon receipt of the funds, which they c= an then present to the merchant in case something went wrong. Exchanges mig= ht be happy to support this protocol, but they don=E2=80=99t want the burde= n of dealing with user support requests, so having signed invoices could he= lp with that.

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

Speaking of Bisq, it would b= e neat if merchants can rely on random peer to peer counterparties to conve= rt to fiat, so their customer information and revenue figures aren=E2=80=99= t 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 hoste= d 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 se= nd the customers coins to their own backend wallet and then forward it.

Sjors

Op 20 dec. 2017, om 07:28 heeft Nicolas Dorier vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het vo= lgende geschreven:

Hi every= one,

As some of you know, I am working on a complete ope= n source replacement of Bitpay for allowing merchant to accept cryptocurren= cy payments while having a way to sell automatically.

<= div>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 p= ayment processor solution.

This also have positive= impact on scalability: Before, a merchant would receive the bitcoin from t= he customer then would send to the exchange, resulting in two transactions.=
With this specification, it would be one transaction.
=
Special thanks to anditto and kallewoof for reviewing. I am = waiting for your feedback:


<pre>
=C2=A0 BIP: XXX
=C2=A0 Layer: Applications
=C2=A0 Tit= le: Crypto Open Exchange Protocol (COX)
=C2=A0 Author: Nicolas Do= rier <nico= las.dorier@gmail.com>
=C2=A0 Comments-Summary: No comments= yet.
=C2=A0 Status: Draft
= =C2=A0 Type: Standards Track
=C2=A0 Created: 2017-12-20
=C2=A0 License: BSD-3-Clause
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CC0-1.0
</pre>

=3D=3DAbstrac= t=3D=3D

A simple protocol for decoupling payment p= rocessor solutions from exchanges.

=3D=3DMotivatio= n=3D=3D

Cryptocurrency merchant adoption is mainly= driven by availability, ease of use and means of acceptance.
We = call such solutions `Payment Processors`.

Until no= w, payment processing solutions fall into one of the two following categori= es:

# Self-hosted with the customer paying in cryp= tocurrency and the merchant receiving it directly.
# Centralized,= coupled with an exchange feature, with the customer paying in cryptocurren= cy to the merchant, and receiving fiat or cryptocurrency on his exchange ac= count.

The self-hosted solution has two issues:

# The merchant becomes vulnerable to the wild volati= lity of cryptocurrencies.
# It is wasteful of blockchain space, i= f the merchant does not pay suppliers in crypto, as they need a second tran= saction to change to his exchange,

The centralized= solution has two issues:

# It locks-in the mercha= nt to a particular payment processor whose intentions might not be aligned = (e.g. Bitpay who tried to redefine Bitcoin as being a different chain, with= out merchant approval)
# It has to deal with local regulations (e= .g. Bitpay does not provide fiat CAD to canadian merchants)

<= /div>
The goal of this BIP is to specify a simple protocol which makes = possible decoupling of payment processors from exchanges.

We believe this BIP will gather a lot of interest among local excha= nges which do not have the resources to develop their own payment solutions= .

Their customers can decide which payment process= or solution they prefer, while the exchanges give them a way to protect aga= inst cryptocurrency volatility.

=3D=3DSummary=3D= =3D

The merchant log in to its exchange website, g= o into "Address sources" section of it, an click on "Create = a new address source".

The address source cre= ation wizard asks him questions about what to do when crypto currency is se= nt to this the address source. (Cryptocurrency, Market sell order, limit or= der of past day average etc...)

The merchant recei= ves an "address source URI" which they can input inside the payme= nt processor.

An exchange compatible with the Cryp= to Open Exchange Protocol would reply to any HTTP POST request to this=C2= =A0 "address source URI" returning the following information (mor= e details in the Specification part)

# A deposit a= ddress for accepting a payment
# The current rate
# Opt= ional: If the exchange is willing to take the risk of rate fluctuation, unt= il when this rate is guaranteed and under which conditions.

<= /div>
<img src=3D"bip-xxx/overview.png"></img&g= t;

=3D=3D=3DInteraction=3D=3D=3D

* 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 exc= hange "MYCOIN" which supports the Crypto Open Exchange Protocol.<= /div>
* Manny connects to the exchange website, and creates a new addre= ss source.
* In the configuration screen of the address source, f= or each payment sent to this address source, Manny decides to keep 30% in B= itcoin and place a market sell order for the remaining 70% of the amount.
* "MYCOIN" creates the address source, and gives the &qu= ot;address source URI" to the merchant. (e.g. https://example.com/addresssources/abd29ddn92)
* Manny copies the address sourc= e URI and goes inside "PROCCO" settings, and configures his store= to use this address source URI.

Now a customer, C= arol, wants to order a brand new phone for 0.01 BTC on Manny's store an= d decides to pay in Bitcoin.

* The E-Commerce webs= ite plugin requests the creation of an invoice from PROCCO.=C2=A0
* PROCCO queries the "address source URI" and retrieves the rate= , the expiration of this rate and conditions.
* PROCCO can now sh= ow the Bitcoin Payment Checkout page.
* Carla pays.
* P= ROCCO marks the payment as paid and redirects to the e-commerce website.
* MYCOIN, under its own policy (typically after 6 confirmations), c= redits Manny's account of 0.01 BTC and simultaneously creates a market = sell order of 0.007 BTC on behalf of Manny.

=3D=3D= Specification=3D=3D

The payment processor sends a = POST request to the "address source URI", the response from a Cry= pto Open Exchange Protocol exchange would be:

If t= he exchange does not guarantee the rate:

=C2=A0 = =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "depositAddress" := "13....abd",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "currenc= yCode" : "CAD",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "= cryptoCurrencyCode" : "BTC",
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 "rate" : "15600",
=C2=A0 =C2=A0 =C2=A0= =C2=A0 # When the merchant account get credited on the exchange
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "requiredConfirmations" : blockcount<= /div>
=C2=A0 =C2=A0 }


If the ex= change guarantee the rate:

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "depositAddress" : "13....abd= ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "currencyCode" : &q= uot;CAD",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "cryptoCurrencyCo= de" : "BTC",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "rat= e" : "15600",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re= quiredConfirmations" : blockcount
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 "conditions" :=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # When the transaction = should be seen on the blockchain to guarantee the rate
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "receivedBefore" : timestamp,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # When the transaction sho= uld be confirmed on the blockchain to guarantee the rate
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "confirmedBefore" : timestamp<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }


The payment processor is responsible for giv= ing feedback to the customer if the fees of the received transaction are no= t enough to guarantee the rate.

=3D=3DNote on adop= tion=3D=3D

While local exchanges have incentives t= o implement this simple protocol, it is not strictly needed.

=
An alternative is to develop an adapter server which expose Cryp= to Open Exchange Protocol endpoint and connect to underlying exchange's= API.

The only downside is that the rate can't= be guaranteed.

=3D=3DCopyright=3D=3D
This document is dual licensed as BSD 3-clause, and Creative C= ommons CC0 1.0 Universal.


Nicolas,
_______________________________________________
bitcoin-dev mailing= list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


--94eb2c0df368980c740560d55fed--