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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F2EEA25A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 14:25:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com
[209.85.161.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B278191
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 14:25:06 +0000 (UTC)
Received: by mail-yw0-f176.google.com with SMTP id b72so43936518ywa.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 07:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=q94EdLuNX4mhmYGVMSfIwqDFybYZ3mlFut74/X5lsVE=;
b=jwBNfE3FnQShZcpi4Eh4mI6+/fU/8LrzJc+ClEPKwrEJ2dCzJQlMH34ovPoUhNdxsd
yH885eVMLTqxIt9EVCHK413+DUG6rIyE8ryUs3/067fA3wSEgeKVHHoXi7DSDP0XWHZH
JvZ27WfpL8S9m1GhJ/frx2uO3eXu2e8VU36jcPVcNlAajIIs0fRAPxYn0ZFxq6xMdZQA
kPp5B+HdYLXLoGY2KVibeudjZ8Sdx/vgSfvszGxF/6xVYkNaZ4pe81dtmzmaoLpOUlq4
Nqgaq26DwDNCCei8p2YF+X+FaqdpplgkXFRs7yXLDjUXaDakyq96DQCuXGo6ubSEwUWV
tEbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=q94EdLuNX4mhmYGVMSfIwqDFybYZ3mlFut74/X5lsVE=;
b=JCSSZYXgJEL8bJq0SoH1djq5PfhMr5+7dLijgty7LyEmp/dz4GZtN6RoqWFhwD3OnE
bLLNSQVfw+dmkPcsdD0vauUEm+KgFQ5u2uey4EnZNRKzofVONN/vwlXzvdMoLecOVjfS
XRbWoQ7CA65GVj1pYNhv3IqMfW+d9fCzOv3Ti/8jGe85Fxmrep7Vg69WAeqBipjEzZJq
TJk2Ryf2yQQhn4MGkT5lWsKiEyFkfy5lytA9vnJ+SN7m+4ZXutHXa+/vISVd2Jjj3GsN
8SMtqxql81IIaC/lxPm8lhQ03DJ9nWNs0KK7zIvS5ANMBM4wUfXPKf1Bi9JaedGA19cd
vSwQ==
X-Gm-Message-State: ALyK8tKhDwbfveJiAvqtOXeiacHHYjQNDuKyGuCiU7N4PyJHCGI9hMSjMAdnugThi8S12ceJrB62AbQ4ooqYUg==
X-Received: by 10.13.227.196 with SMTP id m187mr15777134ywe.18.1466605505448;
Wed, 22 Jun 2016 07:25:05 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.72.68 with HTTP; Wed, 22 Jun 2016 07:25:03 -0700 (PDT)
In-Reply-To: <576A44F1.9050108@electrum.org>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
<576A44F1.9050108@electrum.org>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 22 Jun 2016 10:25:03 -0400
X-Google-Sender-Auth: vHSNkmbHxVmQJf9-xm-WHV0SqDE
Message-ID: <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c07cfc82d91130535deb475
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Wed, 22 Jun 2016 14:25:45 +0000
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
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: Wed, 22 Jun 2016 14:25:07 -0000
--94eb2c07cfc82d91130535deb475
Content-Type: text/plain; charset=UTF-8
> Only large merchants are able to maintain such an infrastructure; (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>
Payment protocol is for when you buy stuff from purse.io, not really needed
for face-to face transfers, end users, IMO.
> The same benefit can be achieved without the complexity of BIP70, by
> extending the Bitcoin URI scheme. The requestor is authenticated using
> DNSSEC, and the payment request is signed using an EC private key. A
> domain name and an EC signature are short enough to fit in a Bitcoin URI
> and to be shared by QR code or SMS text.
>
> bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz
>
I agree. A TXT record at that name could contain the pubkey.
> That extension is sufficient to provide authenticated requests, without
> requiring a https server. The signed data can be serialized from the
> URI, and DNSSEC verification succeeds without requesting extra data from
> the requestor. The only assumption is that the verifier is able to make
> DNS requests.
>
The problem is that there's no way for a merchant to *refuse *a payment
without a direct communication with the merchant's server. Verify first
/ clear later is the rule. Check stock, ensure you can deliver, and clear
the payment on the way out the door.
Also, as a merchant processing monthly subscriptions, you don't want the
first time you hear about a user's payment to be *after *it hits the
blockchain. You could add a refund address to deal with it after the
fact... stuff a refund address int OP_RETURN somehow?
bitcoin:address?amount=xx¤cy=ccc&message=yyy&name=john.example.com
&offset=3d&interval=1m&sig=zzz
... But what if the merchant simply goes out of business. No OP_RETURN
will help you here. You'll be posting transactions into a dead wallet.
You could have some way of posting a "ping" transaction, and then
monitoring for a valid response. But this is "spamming the blockchain for
communications".
No, I think BIP075 is fine. You just need to extend the *PaymentAck *with
a single field, instead of just having a memo.
next_payment_days : integer
The wallet, when it sees this field, re-initiates an invoice request after
the selected number of days, after presenting the user with the content of
the memo field which will presumably explain the subscription. Wallet
vendors can let users "auto approve" vendors as needed.
This is, I think, the absolute minimum needed to update BIP0070/0075 for
subscriptions.
--94eb2c07cfc82d91130535deb475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Only large merchants are able to maintain such an infrastructure; (even<br>
Coinbase recently failed at it, they forgot to update their<br>
certificate). For end users that is completely unpractical.<br></blockquote=
><div><br></div><div>Payment protocol is for when you buy stuff from <a hre=
f=3D"http://purse.io">purse.io</a>, not really needed for face-to face tran=
sfers, end users, IMO.<br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
The same benefit can be achieved without the complexity of BIP70, by<br>
extending the Bitcoin URI scheme. The requestor is authenticated using<br>
DNSSEC, and the payment request is signed using an EC private key. A<br>
domain name and an EC signature are short enough to fit in a Bitcoin URI<br=
>
and to be shared by QR code or SMS text.<br>
<br>
=C2=A0bitcoin:address?amount=3Dxx&message=3Dyyy&name=3D<a href=3D"h=
ttp://john.example.com" rel=3D"noreferrer" target=3D"_blank">john.example.c=
om</a>&sig=3Dzzz<br></blockquote><div><br></div><div>I agree.=C2=A0 A T=
XT record at that name could contain the pubkey.=C2=A0=C2=A0 <br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That extension is sufficient to provide authenticated requests, without<br>
requiring a https server. The signed data can be serialized from the<br>
URI, and DNSSEC verification succeeds without requesting extra data from<br=
>
the requestor. The only assumption is that the verifier is able to make<br>
DNS requests.<br></blockquote><div><br></div>The problem is that there'=
s no way for a merchant to <i>refuse </i>a payment without a direct communi=
cation with the merchant's server.=C2=A0=C2=A0=C2=A0 Verify first / cle=
ar later is the rule.=C2=A0=C2=A0 Check stock, ensure you can deliver, and =
clear the payment on the way out the door.=C2=A0=C2=A0 <br><br>Also, as a m=
erchant processing monthly subscriptions, you don't want the first time=
you hear about a user's payment to be <i>after </i>it hits the blockch=
ain.=C2=A0 You could add a refund address to deal with it after the fact...=
stuff a refund address int OP_RETURN somehow?<br><br></div><div class=3D"g=
mail_quote"><div>bitcoin:address?amount=3Dxx&currency=3Dccc&message=
=3Dyyy&name=3D<a href=3D"http://john.example.com" rel=3D"noreferrer" ta=
rget=3D"_blank">john.example.com</a>&offset=3D3d&interval=3D1m&=
sig=3Dzzz<br><br></div><div>... But what if the merchant simply goes out of=
business.=C2=A0 No OP_RETURN will help you here.=C2=A0=C2=A0 You'll be=
posting transactions into a dead wallet.=C2=A0 You could have some way of =
posting a "ping" transaction, and then monitoring for a valid res=
ponse.=C2=A0=C2=A0 But this is "spamming the blockchain for communicat=
ions".<br></div><br></div><div class=3D"gmail_quote">No, I think BIP07=
5 is fine.=C2=A0=C2=A0 You just need to extend the <i>PaymentAck </i>with a=
single field, instead of just having a memo.<br><br></div><div class=3D"gm=
ail_quote">next_payment_days : integer<br><br></div><div class=3D"gmail_quo=
te"></div><div class=3D"gmail_quote">The wallet, when it sees this field, r=
e-initiates an invoice request after the selected number of days, after pre=
senting the user with the content of the memo field which will presumably e=
xplain the subscription.=C2=A0=C2=A0 Wallet vendors can let users "aut=
o approve" vendors as needed.<br><br></div><div class=3D"gmail_quote">=
This is, I think, the absolute minimum needed to update BIP0070/0075 for su=
bscriptions.<br></div><div class=3D"gmail_quote"><div><br><br></div><div><b=
r></div><div><br><br></div><br></div><br></div></div>
--94eb2c07cfc82d91130535deb475--
|
