1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2A997941
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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: <xms:L3k7Wt8kYaeUvxSlm-orvLuZupNEOiXEqsDvcFc9tvl9dPJUkV634g>
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 <sjors@sprovoost.nl>
Message-Id: <F4631D31-54E2-43EF-B6BA-69B7371F1E6D@sprovoost.nl>
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: <CA+1nnr=oCWwibecFGXpOJbtWnQ1b9=+Qx0nQcKoJRgdxyWZVrg@mail.gmail.com>
To: Nicolas Dorier <nicolas.dorier@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CA+1nnr=-6UkJT=TWjDHhZtXsic8p0fzQ=Yk1tSqkhL+NuvqCQw@mail.gmail.com>
<A2014DA0-F6F8-470F-A167-E66723281269@sprovoost.nl>
<CA+1nnr=oCWwibecFGXpOJbtWnQ1b9=+Qx0nQcKoJRgdxyWZVrg@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><div>Just to clarify two points:</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D"">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.</blockquote><br =
class=3D""></div><div>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.</div><div><br class=3D""></div><div>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 <a href=3D"http://wordpress.com" =
class=3D"">wordpress.com</a>. PayPal and Stripe make sure their API keys =
can=E2=80=99t do too much damage in case the merchant shop hosting is =
compromised.</div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D""><span style=3D"font-size:12.8px" =
class=3D"">> </span><span style=3D"font-size:12.8px" =
class=3D"">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.</span></div><div =
class=3D""><span style=3D"font-size:12.8px" class=3D""><br =
class=3D""></span></div><div class=3D""><span style=3D"font-size:12.8px" =
class=3D"">This protocol can be expanded later for lightning trivially, =
where the call to the address source uri also returns a lightning =
payment request. (BOLT11)</span></div></div></div></blockquote><div><br =
class=3D""></div><div>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").</div><div><br class=3D""></div><div>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. </div><div><br =
class=3D""></div><div>Sjors</div></div></body></html>=
--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--
|
