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
|
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 90D52724
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jun 2016 17:33:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com
[209.85.161.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BEF822C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jun 2016 17:33:44 +0000 (UTC)
Received: by mail-yw0-f177.google.com with SMTP id v77so24249790ywg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jun 2016 10:33:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=m8rL5R3jJyoiGQSCdUZtoN7Nc1RtuaSc/kjrcamtEyQ=;
b=CzSz9iuj0G752lFSdQzRTAQjowJqDcq05/P7YcUIAfeSXZTzhUIzqg5Eeil1T6nfuK
drLbeahIbLyHvxEfTCwE1sRYSmYkJr4HfT19gsxwyr8ys1PPwJMi6sdueAV/aCKTPeCy
s1l4Qcy5AiEuyO6Wlc3u7BnPy/yfdmR97s6GaD2pEnaZAe5lfhh3NC9SQvW9PtW+SeVT
Qv3+1Jg4JcVBWO3qYMWSI+VGknz1nESTwix5fadrQwimNy90V2tKSUIZCc8uL1P7cg0v
kpQUi5bp/AVWk7KvGTVuxCGrRg7UmfDm49grxZTOF/WzM9LOKZWVciuQZcj9vfsf5ffT
Ebpg==
X-Gm-Message-State: ALyK8tLQ5BxTAt/+4K+Ss3r209QaMt8c3UIXfHClTxHsLqi1oMpfgVIE1UbvHA+dco5IIFCSqq5cHqijbpvo9Q==
X-Received: by 10.129.91.69 with SMTP id p66mr9521100ywb.85.1466444023490;
Mon, 20 Jun 2016 10:33:43 -0700 (PDT)
MIME-Version: 1.0
From: Erik Aronesty <erik@q32.com>
Date: Mon, 20 Jun 2016 17:33:32 +0000
Message-ID: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114c8b081a6da90535b91bae
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Mon, 20 Jun 2016 17:36:41 +0000
Subject: [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: Mon, 20 Jun 2016 17:33:45 -0000
--001a114c8b081a6da90535b91bae
Content-Type: text/plain; charset=UTF-8
BIP 0070 has been a a moderate success, however, IMO:
- protocol buffers are inappropriate since ease of use and extensibility is
desired over the minor gains of efficiency in this protocol. Not too late
to support JSON messages as the standard going forward
- problematic reliance on merchant-supplied https (X509) as the sole form
of mechant identification. alternate schemes (dnssec/netki), pgp and
possibly keybase seem like good ideas. personally, i like keybase, since
there is no reliance on the existing domain-name system (you can sell with
a github id, for example)
- missing an optional client supplied identification
- lack of basic subscription support
*Proposed for subscriptions:*
- BIP0047 payment codes are recommended instead of wallet addresses when
establishing subscriptions. Or, merchants can specify replacement
addresses in ACK/NACK responses. UI confirms are *required *when there
are no replacement addresses or payment codes used.
- Wallets must confirm and store subscriptions, and are responsible for
initiating them at the specified interval.
- Intervals can *only *be from a preset list: weekly, biweekly, or 1,
2,3,4,6 or 12 months. Intervals missed by more than 3 days cause
suspension until the user re-verifies.
- Wallets *may *optionally ask the user whether they want to be notified
and confirm every interval - or not. Wallets that do not ask *must *notify
before initiating each payment. Interval confirmations should begin at *least
*1 day in advance of the next payment.
*Proposed in general:*
- JSON should be used instead of protocol buffers going forward. Easier to
use, explain extend.
- "Extendible" URI-like scheme to support multi-mode identity mechanisms on
both payment and subscription requests. Support for keybase://, netki://
and others as alternates to https://.
- Support for client as well as merchant multi-mode verification
- Ideally, the identity verification URI scheme is somewhat
orthogonal/independent of the payment request itself
Question:
Should this be a new BIP? I know netki's BIP75 is out there - but I think
it's too specific and too reliant on the domain name system.
Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
major protocols without any mention of payment URI's ... just a way of
sending and receiving identity verified messages in general?
I would be happy to implement plugins for identity protocols, if anyone
thinks this is a good idea.
Does anyone think https:// or keybase, or PGP or netki all by themselves,
is enough - or is it always better to have an extensible protocol?
- Erik Aronesty
--001a114c8b081a6da90535b91bae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div>BIP 0070 has been a a m=
oderate success, however, IMO:<br><br></div>-
protocol buffers are inappropriate since ease of use and extensibility is =
desired over the minor gains of
efficiency in this protocol.=C2=A0 Not too late to support JSON messages as=
the standard going forward<br><br></div>- problematic reliance on merchant=
-supplied https (X509) as the sole form of mechant identification.=C2=A0=C2=
=A0 alternate schemes (dnssec/netki), pgp and possibly keybase seem like go=
od ideas.=C2=A0=C2=A0 personally, i like keybase, since there is no relianc=
e on the existing domain-name system (you can sell with a github id, for ex=
ample)<br><br></div><div>- missing an optional client supplied identificati=
on<br></div><div><br></div>- lack of basic subscription support<br><br></di=
v><i>Proposed for subscriptions:</i><br><br></div><div></div></div>- BIP004=
7 payment codes are recommended instead of wallet addresses when establishi=
ng subscriptions.=C2=A0 Or, merchants can specify replacement addresses in =
ACK/NACK responses.=C2=A0=C2=A0 UI confirms are <i>required </i>when there =
are no replacement addresses or payment codes used.<br><br>- Wallets must c=
onfirm and store subscriptions, and are responsible for initiating them at =
the specified interval.=C2=A0=C2=A0 <br><br>- Intervals can <i>only </i>be =
from a preset list: weekly, biweekly, or 1, 2,3,4,6 or 12 months.=C2=A0=C2=
=A0 Intervals missed by more than 3 days cause suspension until the user re=
-verifies.<br><br>- Wallets <i>may </i>optionally ask the user whether they=
want to be notified and confirm every interval - or not.=C2=A0=C2=A0 Walle=
ts that do not ask <i>must </i>notify before initiating each payment.=C2=A0=
=C2=A0 Interval confirmations should begin at <i>least </i>1 day in advance=
of the next payment.<br><br></div><div><i>Proposed in general:<br></i><br>=
- JSON should be used instead of protocol buffers going forward.=C2=A0 Easi=
er to use, explain extend.<br>
<br></div><div>- "Extendible" URI-like scheme to support multi-mo=
de=20
identity mechanisms on both payment and subscription requests.=C2=A0=C2=A0 =
Support for keybase://, netki:// and others as alternates to https://.=C2=
=A0 <br><br></div><div>- Support for client as well as merchant multi-mode =
verification<br><br></div><div>- Ideally, the identity verification URI sch=
eme is somewhat orthogonal/independent of the payment request itself<br><br=
></div><div>Question: <br><br></div><div>Should this be a new BIP?=C2=A0 I =
know netki's BIP75 is out there - but I think it's too specific and=
too reliant on the domain name system.<br><br></div><div>Maybe an identity=
-protocol-agnostic BIP + solid implementation of a couple major protocols w=
ithout any mention of payment URI's ... just a way of sending and recei=
ving identity verified messages in general?<br><br></div><div>I would be ha=
ppy to implement plugins for identity protocols, if anyone thinks this is a=
good idea.<br><br></div><div>Does anyone think https:// or keybase, or PGP=
or netki all by themselves, is enough - or is it always better to have an =
extensible protocol?<br><br></div><div>- Erik Aronesty<br></div></div>
--001a114c8b081a6da90535b91bae--
|
