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
|
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 618D692
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 17:09:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com
[209.85.161.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7826921B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 17:09:43 +0000 (UTC)
Received: by mail-yw0-f180.google.com with SMTP id v77so19818945ywg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2016 10:09:43 -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=G+uBrEnCfjS/dzjVlhL9/xQ/chTTc60+sz2tIPC4aoM=;
b=g+abeNx52co21ZAMheVWxh468X2Tqa5zvtVtUMSwfqrvyAOPtL4bzy7jxCa7vIbEqV
GegTv4ch51hciQoMq0+SsKru6ZCxVR+jzx12OhwOYFV0NzBRlk0j1g8jR2DbXeJ9IN13
B+BO5JV5+FZ4DD769kELCIrNaT5he8pZjK6kO2o7QCDo0/P4mt3RlyHeFf/HffTZ6s3A
uA7oDfMrMVRD+dpUWz4r40k7rxTtalZuswbXNGjkBny2JbNE2oCXbz2JZ73zFiQJdigb
0ukN6rT6jSvay5W1mwWTDE86QbWScW5tsq/ySajhjSOjy6J+92vCWqF+OxmzALcMbLju
IC9w==
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=G+uBrEnCfjS/dzjVlhL9/xQ/chTTc60+sz2tIPC4aoM=;
b=m69IF+1NIrfTtm1+fcnuM8MA40/uN9jP5SPqBOoQ5uiE5tGsIwJLtAHzhj+bQORXDh
Ag5kVEyazajehuZtu3BpUaFp2hB8VIHHQjQ1BN+ryXEKs/6yqrVGQGlhsNcW+fyoKMrH
XDfzGOhpVe3miEUf50rXizu6uVjaT7oCJw0rIHmxkY8lmVuogVBYr6vLdbxcSPCUPzhX
PfmmAkBmntRKGCD3pe/YqU3aHQJklVhFoiGb6tDB5DsGSt8GQMJ/xBGNUdHcDxMitKPC
4a7cSNdH5W6V0fXQmDTtovI1igKya7h51jvlED1RRcqaTqWCxHp1SxmXWJXM2JlpzepU
uGnQ==
X-Gm-Message-State: ALyK8tJQt7e7Bzwirwr1nAYBI207HYncVQBbhhddnChyb2GASqnfouGaFos6xgOVPtLakIVLx+3DqugRyxWRDA==
X-Received: by 10.37.198.133 with SMTP id k127mr12398085ybf.53.1466528982436;
Tue, 21 Jun 2016 10:09:42 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.72.68 with HTTP; Tue, 21 Jun 2016 10:09:41 -0700 (PDT)
In-Reply-To: <nkb27k$5bi$1@ger.gmane.org>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
<nkb27k$5bi$1@ger.gmane.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 21 Jun 2016 13:09:41 -0400
X-Google-Sender-Auth: 7yukxDmitipgMJ0kBINolHaw65A
Message-ID: <CAJowKgKA4UphM7O7i53WtLGV7_b-ve+o=nuWv6K7nw6LOcQFkQ@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c08bc360d13aa0535cce385
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: Tue, 21 Jun 2016 17:18:33 +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: Tue, 21 Jun 2016 17:09:44 -0000
--94eb2c08bc360d13aa0535cce385
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.)
>
I like protobuf, personally, for C++ stuff. I just imagined it would be
harder on mobile, or in some languages, to implement. I'll focus on the
scheduling issue. Really, that's the only thing I want hashed out.
>
> 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.
>
>
I think the intervals should *not* be flexible, even at the protocol level,
to prevent attacks designed to confuse users - plus for shorter intervals,
you need payment channels anyway. Also, I think the spec should be rigid
with respect to response times, retry periods, etc.... to encourage
consistency among wallet vendors. Not sure how anyone else feels about
that. I suspect the netki guys should have opinions, since they are
working on similar UI-stuff.
Should UI standards go somewhere else - not in a BIP? I do think there
need to be UI standards. Something with RFC-style should/must/will/wont
language, like "Wallet software *must* show unconfirmed transactions as
distinct from confirmed", and "Wallet software *should *show some visual
indication of other levels of confirmation" .... stuff like that.
--94eb2c08bc360d13aa0535cce385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jun 21, 2016 at 5:43 AM, Andreas Schildbach via bi=
tcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<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-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Protobuf vs. JSON was a de=
liberate decision. Afaik Protobuf was chosen<br>
because of its strong types, less vulnerability to malleability and very<br=
>
good platform support. Having coded both, I can say Protobuf is not more<br=
>
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be<br=
>
based on Protobuf, but that's another story.)<br></blockquote><div><br>=
<div>I like protobuf, personally, for C++ stuff.=C2=A0 I just imagined it=
=20
would be harder on mobile, or in some languages, to implement.=C2=A0=C2=A0 =
I'll=20
focus on the scheduling issue.=C2=A0 Really, that's the only thing I wa=
nt=20
hashed out.=C2=A0=C2=A0 <br></div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
<br>
Yes, all extensions to BIP70 should go into new BIPs. Note the plural<br>
here: if you have orthogonal ideas I strongly suggest one BIP per idea<br>
so they can be discussed and implemented (or rejected) separately.<br>
<span class=3D""><br></span></blockquote><div><br>I think the intervals sho=
uld *not* be
flexible, even at the protocol level, to prevent attacks designed to=20
confuse users=C2=A0 - plus for shorter intervals, you need payment channels=
=20
anyway.=C2=A0 Also, I think the spec should be rigid with respect to respon=
se
times, retry periods, etc.... to encourage consistency among wallet=20
vendors.=C2=A0=C2=A0 Not sure how anyone else feels about that.=C2=A0 I sus=
pect the netki guys should have opinions, since they are working on similar=
UI-stuff.<br><br>Should UI standards go somewhere else - not in a BIP?=C2=
=A0 I do=20
think there need to be UI standards.=C2=A0 Something with RFC-style=20
should/must/will/wont language, like "Wallet software <i>must</i> show=
unconfirmed transactions as distinct from confirmed", and "Walle=
t software <i>should </i>show some visual indication of other levels of con=
firmation" ....=C2=A0 stuff like that.=C2=A0 <br></div></div><br></div=
></div>
--94eb2c08bc360d13aa0535cce385--
|
