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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 06E74723
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 08:06:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 39CDB90
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 08:06:04 +0000 (UTC)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net
[217.70.183.197])
by slow1-d.mail.gandi.net (Postfix) with ESMTP id 3306048615A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 09:58:11 +0200 (CEST)
Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150])
by relay5-d.mail.gandi.net (Postfix) with ESMTP id 2894941C0AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 09:58:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197])
by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180])
(amavisd-new, port 10024) with ESMTP id Jh-pK6DRkCvx
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 09:58:05 +0200 (CEST)
X-Originating-IP: 193.251.45.132
Received: from [192.168.101.243] (LCaen-656-1-30-132.w193-251.abo.wanadoo.fr
[193.251.45.132]) (Authenticated sender: thomasv@electrum.org)
by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1572A41C09D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 09:57:55 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
From: Thomas Voegtlin <thomasv@electrum.org>
Message-ID: <576A44F1.9050108@electrum.org>
Date: Wed, 22 Jun 2016 09:57:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
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 08:06:05 -0000
IMO the moderate success of BIP70 is caused by its complexity. Since the
amount of data in a BIP70 payment request does not fit in a bitcoin:
URI, an https server is required to serve the requests.
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.
The main benefit of BIP70 is that the payment request is signed by the
requestor; this gives the sender a proof that they are sending to the
right person, and that the person actually requested the payment.
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
The URI scheme is extended with two fields:
name: DNS name containing a public key or bitcoin address
sig: signature
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.
I am willing to write a BIP if other wallet developers are interested.
Le 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :
> 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
