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