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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DAB64258
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 20:44:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9AAFC10F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 20:44:52 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id CC47538A17C3;
Tue, 21 Jun 2016 20:44:39 +0000 (UTC)
X-Hashcash: 1:25:160621:bitcoin-dev@lists.linuxfoundation.org::cJl5FwPdYoQb6Z0w:/zPj
X-Hashcash: 1:25:160621:erik@q32.com::q93NJTwLzY2mBJEC:1+h9
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Erik Aronesty <erik@q32.com>
Date: Tue, 21 Jun 2016 20:44:37 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.16; x86_64; ; )
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
In-Reply-To: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201606212044.38931.luke@dashjr.org>
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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: Tue, 21 Jun 2016 20:44:54 -0000
On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> 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
IMO JSON is too prone to gratuitous inefficiency (both at network and CPU
level), parser bugs, etc. Even the best C implementation (jansson) has serious
issues with Number handling.
A few years ago, I looked into binary alternatives to JSON and concluded they
all had problems, while it seems more than reasonable to do even dynamic
parsing of protobuf messages. So to conclude, I prefer to stick to protobuf
unless a clearly superior protocol turns up.
> - 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)
X509 is entrenched, so it should remain supported. PGP might make sense for
people already using it (it provides no real security for un-WoT-networked
users), but unforunately, few people use it. Correct me if I'm wrong, but IIRC
Keybase uses blockchain spam, so definitely not something to be encouraged if
so. Namecoin seems like a more than reasonable decentralised solution, but
will probably take some real work to implement (not that this is avoidable for
a general-usage decentralised solution).
> - missing an optional client supplied identification
What do you mean by this? There's the memo field at least.
> - 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.
I'd discourage anything using BIP 47 due to its serious design flaws.
No reason a regular BIP 32 pub seed can't be used instead.
What do you mean by "replacement addresses" and "UI confirms" here?
> - 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.
Disagree with hard-coding intervals, or mandating specific policies from the
service providers.
> - 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.
This is wallet policy, but maybe makes sense as a "best practices" BIP.
> *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
|
