From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2DACD89E for ; Wed, 20 Dec 2017 06:28:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B27D187 for ; Wed, 20 Dec 2017 06:28:29 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id f9so7661056wmh.0 for ; Tue, 19 Dec 2017 22:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=C77abGYzhRvkpsxRnSuWhN7XwTnRp8UxNMt7i7hMHdM=; b=WC9nA/pOU4KcyXdteX3CxTjJMAkUVuwxEeotHIMh/xO7gk/CTWU9TXZAY3LPTvMpYr aXXS65r2Wh0IUUSMzvBl7emYzBogMEvDmj1B9hcJ+V2+GcqhHVVy1LmvrQTcBUndkHQG CHRH9u0ZSqq+DWxz1DbFrZUF8XiDyaGVEEGoh4KisvGvGGJOKi4JjBlzQeyte4tIOlMm iMLlLn7DAmcRMZUpK+qm0Mf7xsOLmEXZ3MkvJWxdIjnwRkT663mttaUrBElwNaMi8Zev GhB6npbL35qi12VvNj8xK4iSlbs78Cagw4lrnvuLwy4KgQJO9ZqDOlQs24T43EOSSMAV bDAw== 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:from:date:message-id:subject :to; bh=C77abGYzhRvkpsxRnSuWhN7XwTnRp8UxNMt7i7hMHdM=; b=oVyZtQzY26kIReNb5y8fatsJ9A1uu/0dqJFL7DjMOFdlD73icWnaZgjZbnpGSF43Jb +3yxyMYv2Zpk/FsVsxnWmm+KqyLh6BcX8+sBctjH5mvxrpL1dzdyMgBCod1eA6u9t3S2 M65R2MaIQFzvreo0MHcNHAGvmbXt70Byu1Ee4k4a1FZutfEIJycIOg7C5DPj1/lY2Wa6 kg7AKjq1IIdlnB/UoEPR0NJJrvE9oO87G3OvzL6fkYC0JljD9C/eKViXp5cqoZ4FvOPH fJlyj/JCPwS7YVhp6e3QxdU02Ollot231mSwdBRgQvFaaX1s47dkVFZJL83zktiqGhcd CS8w== X-Gm-Message-State: AKGB3mIuF3NkmkBete58OkoNHOVxJTwlxtJDdQOmhVUiAuTfaYRcO//S pNxfLgrCxjpHIJk9ASwJidQaodY1bN6AI4Ir3tqG2hIo X-Google-Smtp-Source: ACJfBovS7+1StZyrzgptSUnvTjcKrJ5K0k5LdOHYbYyWYNwCl7TKSjvI5r0W/+0SmLojUFolIvr6EtXmeqBMJ1iZWt4= X-Received: by 10.80.182.217 with SMTP id f25mr4035416ede.104.1513751307965; Tue, 19 Dec 2017 22:28:27 -0800 (PST) MIME-Version: 1.0 Sender: slashene@gmail.com Received: by 10.80.172.79 with HTTP; Tue, 19 Dec 2017 22:28:07 -0800 (PST) From: Nicolas Dorier Date: Wed, 20 Dec 2017 15:28:07 +0900 X-Google-Sender-Auth: WNyAxkAoOwfuY7oDBbcYq3mVq4U Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary="f403045c0c6efd59ba0560bfb068" 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 Subject: [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: Wed, 20 Dec 2017 06:28:31 -0000 --f403045c0c6efd59ba0560bfb068 Content-Type: text/plain; charset="UTF-8" Hi everyone, 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. 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
==Abstract== A simple protocol for decoupling payment processor solutions from exchanges. ==Motivation== Cryptocurrency merchant adoption is mainly driven by availability, ease of use and means of acceptance. We call such solutions `Payment Processors`. Until now, payment processing solutions fall into one of the two following 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 on 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 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) 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. ==Summary== 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 conditions. ===Interaction=== * 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) * 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 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. ==Specification== 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. ==Note on adoption== 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. ==Copyright== This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal. Nicolas, --f403045c0c6efd59ba0560bfb068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

As some of you know, I am = working on a complete open source replacement of Bitpay for allowing mercha= nt to accept cryptocurrency payments while having a way to sell automatical= ly.

A crucial, missing part, is fiat conversion. A= nd I figured out a simple protocol that exchanges (or adapters) can impleme= nt to allow any merchant to cash out BTC in fiat while giving them the free= dom to choose their own payment processor solution.

This also have positive impact on scalability: Before, a merchant would r= eceive the bitcoin from the customer then would send to the exchange, resul= ting in two transactions.
With this specification, it would be on= e transaction.

Special thanks to anditto and kalle= woof for reviewing. I am waiting for your feedback:

Github link:=C2=A0https://github.com/NicolasDorier/bips/blob/master/= bip-xxx.mediawiki

<pre>
= =C2=A0 BIP: XXX
=C2=A0 Layer: Applications
=C2=A0 Title= : Crypto Open Exchange Protocol (COX)
=C2=A0 Author: Nicolas Dori= er <nicolas.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=3DAbstract=3D=3D

A simpl= e protocol for decoupling payment processor solutions from exchanges.
=

=3D=3DMotivation=3D=3D

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

Until now, payment processing solutions fall int= o one of the two following categories:

# Self-host= ed 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 o= r cryptocurrency on his exchange account.

The self= -hosted solution has two issues:

# The merchant be= comes 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 who= se intentions might not be aligned (e.g. Bitpay who tried to redefine Bitco= in as being a different chain, without merchant approval)
# It ha= s to deal with local regulations (e.g. Bitpay does not provide fiat CAD to = canadian merchants)

The goal of this BIP is to spe= cify a simple protocol which makes possible decoupling of payment processor= s 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 custome= rs can decide which payment processor solution they prefer, while the excha= nges 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. (Cryptocurr= ency, Market sell order, limit order of past day average etc...)
=
The merchant receives an "address source URI" whic= h they can input inside the payment processor.

An = exchange compatible with the Crypto Open Exchange Protocol would reply to a= ny HTTP POST request to this=C2=A0 "address source URI" returning= the following information (more details in the Specification part)

# A deposit address for accepting a payment
# T= he current rate
# Optional: If the exchange is willing to take th= e risk of rate fluctuation, until when this rate is guaranteed and under wh= ich conditions.

<img src=3D"bip-xxx/overvi= ew.png"></img>

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

* Manny (the "merchant") wants= to accept Bitcoin payments on his e-commerce website.
* Manny ch= ooses the payment processor "PROCCO" which has a powerful plugin = for his e-commerce website.
* Manny is based in Canada and alread= y has an account on the exchange "MYCOIN" which supports the Cryp= to Open Exchange Protocol.
* Manny connects to the exchange websi= te, and creates a new address source.
* In the configuration scre= en of the address source, for each payment sent to this address source, Man= ny decides to keep 30% in Bitcoin and place a market sell order for the rem= aining 70% of the amount.
* "MYCOIN" creates the addres= s source, and gives the "address source URI" to the merchant. (e.= g. https://exampl= e.com/addresssources/abd29ddn92)
* Manny copies the address s= ource URI and goes inside "PROCCO" settings, and configures his s= tore to use this address source URI.

Now a custome= r, Carol, wants to order a brand new phone for 0.01 BTC on Manny's stor= e and decides to pay in Bitcoin.

* The E-Commerce = website 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 no= w 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 mar= ket sell order of 0.007 BTC on behalf of Manny.

= =3D=3DSpecification=3D=3D

The payment processor se= nds 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:

=C2= =A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "depositAddress&quo= t; : "13....abd",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "cur= rencyCode" : "CAD",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;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" : block= count
=C2=A0 =C2=A0 }


If = the exchange 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"= ; : "CAD",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "cryptoCurr= encyCode" : "BTC",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;rate" : "15600",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;requiredConfirmations" : blockcount
=C2=A0 =C2=A0 =C2=A0= =C2=A0 "conditions" :=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # When the transa= ction should be seen on the blockchain to guarantee the rate
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "receivedBefore" : timesta= mp,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # When the transact= ion should be confirmed on the blockchain to guarantee the rate
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "confirmedBefore" : tim= estamp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }


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 incen= tives to implement this simple protocol, it is not strictly needed.

An alternative is to develop an adapter server which expo= se Crypto Open Exchange Protocol endpoint and connect to underlying exchang= e's API.

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

=3D=3DCopyright=3D=3D
=

This document is dual licensed as BSD 3-clause, and Cre= ative Commons CC0 1.0 Universal.

=
Nicolas,
--f403045c0c6efd59ba0560bfb068--