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
|
Return-Path: <gcbd-bitcoin-development-2@m.gmane.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 58B4E92
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 09:43:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A917E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 09:43:51 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development-2@m.gmane.org>)
id 1bFIDZ-0005LQ-M3 for bitcoin-dev@lists.linuxfoundation.org;
Tue, 21 Jun 2016 11:43:37 +0200
Received: from x55b428dc.dyn.telefonica.de ([85.180.40.220])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 11:43:37 +0200
Received: from andreas by x55b428dc.dyn.telefonica.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 11:43:37 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 21 Jun 2016 11:43:15 +0200
Message-ID: <nkb27k$5bi$1@ger.gmane.org>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: x55b428dc.dyn.telefonica.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.8.0
In-Reply-To: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
RCVD_IN_DNSWL_LOW,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 09:43:52 -0000
Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on Protobuf, but that's another story.)
Yes, all extensions to BIP70 should go into new BIPs. Note the plural
here: if you have orthogonal ideas I strongly suggest one BIP per idea
so they can be discussed and implemented (or rejected) separately.
On 06/20/2016 07:33 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
>
> - 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
>
|
