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 2A997941 for ; Thu, 21 Dec 2017 09:04:49 +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 18C1F149 for ; Thu, 21 Dec 2017 09:04:48 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4109320CD2; Thu, 21 Dec 2017 04:04:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 21 Dec 2017 04:04:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= cc: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=TmCAtN1GQHAcX3im9D7t+PoWHz4UIL+40l8xKq8z7UU=; b=Pke705mT 4aYzr4V6/ccbLSuQeC7/U9jDyxiCkMzhdaLltTVHwJPuMBsFyIYUhkJTPQGMQEz6 N5Abn1nMPxkT3SpOVbsBiA3ukiUZbyS8UdXTqolE/jO8XgvBA480QvJm0I7mHNqv 31+Ou2g8uzeFLb1KY7mmGWzkSQ89Hqp+mKMCezt7xsOYfccuZUdV51fMSu2gzJvA dI/QsXbEevabyhHyizr+lz+RIKulAwFNdv/s/RZlp6Pr4GjLB+n8Smc9wsfgS2S8 pEE1Naorj0x7yqnFRWAnBSAUovwsiLuQ836JxeZOcPDnbTsUMRmJ5keDpYt7stbR tPUQNoBlKHwpiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=TmCAtN1GQHAcX3im9D7t+PoWHz4UI L+40l8xKq8z7UU=; b=ouifJ2NcnqysFJmnWnO8vt40FSVurt3hx+OGLvi48tki4 A8U6SRW1KfsZ2uM5twawgj0fKfklAVqxMqNvH6ujITGMJMMprRQXI6rUwfuipUyp JK5RMuuv44ZLtpKbppH7CEY+JJKPT856X8dZx9ekZZOSsqVQy52iLsBKYcoEA7/q 0J1fy84liF4dFU8MD8SkYTdaizTVuxowut1UfYq9Qq8+Q+uG1UdLoRGico5UzvaE nA4eLNYDPURCR/tQqdwI6UeeDahPiYfi1lGY1VTX/ZkEAUawXt8rl8aDnoMu8xbE sNhvHlA7Xkd2AlJ6De5UyOus9KnbQz2h4me3n9psw== X-ME-Sender: 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 578057E558; Thu, 21 Dec 2017 04:04:46 -0500 (EST) From: Sjors Provoost Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 21 Dec 2017 10:04:44 +0100 In-Reply-To: To: Nicolas Dorier , Bitcoin Dev References: 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 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: Thu, 21 Dec 2017 14:26:38 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 09:04:49 -0000 --Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95 Content-Type: multipart/alternative; boundary="Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3" --Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t want to install an = adaptor plugin if your shop is hosted on wordpress.com. PayPal and = Stripe make sure their API keys can=E2=80=99t 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=E2=80=99t want the = burden of dealing with user support requests, so having signed invoices = could help with that. >=20 > 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=E2=80=99t 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=E2=80=99ve= 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=E2=80=99t 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 (=E2=80=9Ccomputer says no"). So you=E2=80=99d want some sort of signed message as part of the = protocol that says =E2=80=9Cif this transaction ID confirms, this order = ID is paid for=E2=80=9D. Although this specific example wouldn=E2=80=99t= play well with RBF. So maybe =E2=80=9Cif the confirmed balance of this = address is >=3D X, this order ID is paid for=E2=80=9D, but then the = exchange can=E2=80=99t sweep it. So maybe instead you need a callback = from the exchange to just tell you when it=E2=80=99s (expected to be) = confirmed. BitPay offers merchants various risk settings for this, so = that might be worth looking into. Sjors --Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99t want to install an adaptor = plugin if your shop is hosted on wordpress.com. PayPal and Stripe make sure their API keys = can=E2=80=99t 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=E2=80=99t 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=E2=80=99t 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=E2=80=99ve 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=E2=80=99t 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 (=E2=80=9Ccomputer = says no").

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

Sjors
= --Apple-Mail=_B03BDB93-2194-4205-B450-9DFC427B24E3-- --Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95 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/+b28wwEAkFAlo7eSwACgkQV/+b28ww EAlITRAAsvtVX0nm1NZwseKSfdwm6XAmcJMUHTvVfVlNoShfyTbcvb3SkrV9MbLu qJZZzrNrOGdP5ZoA+8V+GfXl86Cnr5bse8L8ELinBOr6RVLtU4V3Nvvz8meduAGU gAUIG6/XhDL4bf/zKVHKfZprG/UrJkOwzTwE8i0kYJ2z2iELTv9doDAdoGH0tqWo 9VSHtBIpmm3UPMqOj1naSzn2OwCtzUAdZcqwY7So42FOGzlAlgFAgHN+l/Yx43MT LqWh5foP2OPMj13LgsbN32oNX99NfptVwOGPYSwiZlX6mDs5HGeQJ3a16cw9Fppm BuI7DZ1zVdT+anNdpVQzQbci6qlSdBASfz68GI022kFAVDwMluAbG12WqtKAYl0m 6CY7kt2oWL8uEhmHRfK5OIgKlWbYc3zEhkXg/+0sn1mCyI92PxZv59N/ELpDd528 ZNlQhm1tJLpBvVI1LVR0WXdye97thitZxNlVbWDWNWL6c2SvprVUizgqBZqAe8Ik T9tQGMnRipa39TuzogprmbUPzVBTXullC8LDnyImQdqgsFlUgRF7K+ZCuJ8Pk+vk 1OhTklFLF0knwQR/Hgj/iRB24WZo/Gz+2TbWrJeXzP9PqNGckA7Z1UaFIC5RQnzn nTqINVyU36orMjKS5eKohrXOfD2BbZPemrXvRoXhHXnyPor+BRU= =wpIj -----END PGP SIGNATURE----- --Apple-Mail=_D8940536-48E3-41F1-9A69-B299BF711E95--