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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mike@belshe.com>) id 1VthJn-0006FA-07
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Dec 2013 17:23:27 +0000
X-ACL-Warn:
Received: from mail-bk0-f48.google.com ([209.85.214.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VthJl-0005Qc-IZ
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Dec 2013 17:23:26 +0000
Received: by mail-bk0-f48.google.com with SMTP id r7so815417bkg.35
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Dec 2013 09:23:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=8o83wVA3cqumoPGoC202fTqc5AFazgLYDxYXwHsjkaI=;
b=F4znk1/vWsugd80+uy8NS8ERHtjM+rCcJ2PlEaBo50TK2oO1tMaNRXK2gkQlfRcLzX
70zEuF4ud1zlvinqyocUD7D2QUA1UOWCcxuQJ5egYfFimOCWg4fcFh2bMOc6aSlZuwzZ
aR08c+9VzjUrJ8nVBaxh3VuEJYv5JiqpdWzbrfoCRMFnwA+jHkvbCgy6EWURIdy07IEE
W+v69265+fNsY4AiWyuldnB6Tmx/HTo2km128es3h/P94r31YmGHToLstLWYwv9SKNKB
zN6IItSNX0mx4xneDStcTdctPaiqdhEybybIcuyKlj+aCvc1iSkI5sZ8AoHra9+n4KgS
lo/Q==
X-Gm-Message-State: ALoCoQmMsH1il5ZFcF1rJ8Jvm2kKox7WvrS++I03VdeiU3D+OXNVoWAH5lI/FR4UzoooYcFhclmY
MIME-Version: 1.0
X-Received: by 10.204.165.134 with SMTP id i6mr25321bky.78.1387473798910; Thu,
19 Dec 2013 09:23:18 -0800 (PST)
Received: by 10.204.227.12 with HTTP; Thu, 19 Dec 2013 09:23:18 -0800 (PST)
In-Reply-To: <CANAnSg312feKyW-LtRu+n99ODn4KDTja__Wp7bRz+k=5ox3yHg@mail.gmail.com>
References: <20131219131706.GA21179@savin>
<dde469d7ce77a748fb4c279334deb643.squirrel@fruiteater.riseup.net>
<538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net>
<CANAnSg312feKyW-LtRu+n99ODn4KDTja__Wp7bRz+k=5ox3yHg@mail.gmail.com>
Date: Thu, 19 Dec 2013 09:23:18 -0800
Message-ID: <CABaLYCtWXURDiKHvXfbAu2z-TzZQWA1Z42a0EhP3hKHyEv9ZyA@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Drak <drak@zikula.org>
Content-Type: multipart/alternative; boundary=bcaec52d581debb6c104ede66ae7
X-Spam-Score: 2.3 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
1.3 URI_HEX URI: URI hostname has long hexadecimal sequence
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VthJl-0005Qc-IZ
Cc: System undo crew <unsystem@lists.dyne.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Amir Taaki <genjix@riseup.net>
Subject: Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 17:23:27 -0000
--bcaec52d581debb6c104ede66ae7
Content-Type: text/plain; charset=ISO-8859-1
Hey Peter -
I think this is a super list. A couple of thoughts:
a) In the section on multi-sig and multi-factor, I think we can split these
apart. Multi-factor user authentication is very valuable and not the same
as multi-factor signing, which is a second level of complexity. The
multi-factor auth can be off-blockchain, e.g. authenticating with SMS
message to your phone or Google Authenticator challenge. Given the state
of malware today, I personally would propose two requirements:
1) wallets SHOULD use multi-factor authentication before authorizing
access to a wallet (e.g. view balances, addresses, transactions, etc)
2) wallets MUST use multi-factor auth before signing a transaction.
[note: I recognize that MUST might be too aggressive right now, but I
wouldn't use a wallet without it. this can also be impractical for
server-side wallets]
b) Multi-factor signing (e.g. P2SH) may be too early to really define. But
here are some issues which have come up from my own personal development
experience:
- Wallets SHOULD NOT create two keys on a single host or device
- Wallets SHOULD provide a way to import external public keys which can
be used as part of a P2SH address
Slightly off topic: For P2SH, address creation requires the public key,
not the public hash of an address. For me, this has made it difficult to
import keys created through out-of-band sources. Most wallets/key
generators/etc only provide the address and not the public key, and this is
a hinderance to easy P2SH creation off host. It would be great if there
were a way to address this, but I don't know how.
c) Small word-choice nit: I had to go lookup the meaning of "SHALL" (I now
know it is the same as MUST). I think most RFCs just use MUST these days.
Thanks,
mike
On Thu, Dec 19, 2013 at 8:32 AM, Drak <drak@zikula.org> wrote:
> On 19 December 2013 16:04, Amir Taaki <genjix@riseup.net> wrote:
>
>> About signing each commit, Linus advises against it:
>>
>> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
>
>
> Yeah, it makes no sense after reading it. Nice catch.
>
> However, his recommendation for signing tags with `git tag -s` should
> probably be incorporated into the spec as a MUST.
>
> Drak
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--bcaec52d581debb6c104ede66ae7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Peter -<div><br></div><div>I think this is a super lis=
t. =A0 A couple of thoughts:</div><div><br></div><div>a) In the section on =
multi-sig and multi-factor, I think we can split these apart. Multi-factor =
user authentication is very valuable and not the same as multi-factor signi=
ng, which is a second level of complexity. =A0 The multi-factor auth can be=
off-blockchain, e.g. authenticating with SMS message to your phone or Goog=
le Authenticator challenge. =A0Given the state of malware today, I personal=
ly would propose two requirements:</div>
<div>=A0 =A0 1) wallets SHOULD use multi-factor authentication before autho=
rizing access to a wallet (e.g. view balances, addresses, transactions, etc=
)</div><div>=A0 =A0 2) wallets MUST use multi-factor auth before signing a =
transaction. =A0 [note: I recognize that MUST might be too aggressive right=
now, but I wouldn't use a wallet without it. =A0this can also be impra=
ctical for server-side wallets]</div>
<div><br></div><div>b) Multi-factor signing (e.g. P2SH) may be too early to=
really define. =A0But here are some issues which have come up from my own =
personal development experience:</div><div>=A0 =A0 - Wallets SHOULD NOT cre=
ate two keys on a single host or device</div>
<div>=A0 =A0 - Wallets SHOULD provide a way to import external public keys =
which can be used as part of a P2SH address</div><div><br></div><div>Slight=
ly off topic: =A0For P2SH, address creation requires the public key, not th=
e public hash of an address. =A0For me, this has made it difficult to impor=
t keys created through out-of-band sources. =A0Most wallets/key generators/=
etc only provide the address and not the public key, and this is a hinderan=
ce to easy P2SH creation off host. =A0It would be great if there were a way=
to address this, but I don't know how.</div>
<div><br></div><div>c) Small word-choice nit: =A0I had to go lookup the mea=
ning of "SHALL" (I now know it is the same as MUST). =A0I think m=
ost RFCs just use MUST these days. =A0<br></div><div><br></div><div><br></d=
iv>
<div>Thanks,</div><div>mike</div><div><br></div><div><br></div><div><br></d=
iv><div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_e=
xtra"><br><br><div class=3D"gmail_quote">On Thu, Dec 19, 2013 at 8:32 AM, D=
rak <span dir=3D"ltr"><<a href=3D"mailto:drak@zikula.org" target=3D"_bla=
nk">drak@zikula.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">On 19 December 2013 16:04, Amir Taaki <span dir=
=3D"ltr"><<a href=3D"mailto:genjix@riseup.net" target=3D"_blank">genjix@=
riseup.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
About signing each commit, Linus advises against it:<br>
<br>
<a href=3D"http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td258=
2986.html" target=3D"_blank">http://git.661346.n2.nabble.com/GPG-signing-fo=
r-git-commit-td2582986.html</a></blockquote><div><br></div><div>Yeah, it ma=
kes no sense after reading it. Nice catch.</div>
<div><br></div><div>However, his recommendation for signing tags with `git =
tag -s` should probably be incorporated into the spec as a MUST.</div><span=
class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Drak</div><di=
v>
<br></div><div><br></div></font></span></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Rapidly troubleshoot problems before they affect your business. Most IT<br>
organizations don't have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami=
cs Pro!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--bcaec52d581debb6c104ede66ae7--
|
