Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Sjors Provoost via bitcoin-dev]

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’t want to install an adaptor plugin if your shop is hosted 
on wordpress.com. PayPal and Stripe make sure their API keys can’t 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’t want the burden of dealing 
> > 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)

I didn’t 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’ve 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’t 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 (“computer says no").

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

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Nicolas Dorier via bitcoin-dev]

Thanks a lot for the feedback

> I think this could be quite useful, although I don’t know if it will 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’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’s 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 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’t think that’s 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’t want the burden of dealing
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’t in the hands of a single counter party.
Obviously that’s 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’s hosted somewhere else for
similar reasons. Right now the best these plugins can do is hold on to an
XPUB, and I’ve even seen solutions that just send the customers coins 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’t 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 

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Sjors Provoost via bitcoin-dev]

I think this could be quite useful, although I don’t 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’s 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’t think that’s 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’t 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. 
“Exchange” 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’t in the hands of a single counter party. Obviously that’s 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’s hosted somewhere else for similar reasons. 
Right now the best these plugins can do is hold on to an XPUB, and I’ve 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 
>  het volgende geschreven:
> 
> 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 

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Dan Libby via bitcoin-dev]

currencyCode and cryptoCurrencyCode seem to assume that merchants will
always want to sell for fiat.  But a merchant might want to sell for
another cryptocurrency instead.

Why not make it more generic, like buySymbol and sellSymbol?

> "currencyCode" : "CAD",
> "cryptoCurrencyCode" : "BTC",


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Nicolas Dorier via bitcoin-dev]

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