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&#39;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&#39;t know how.</div>
<div><br></div><div>c) Small word-choice nit: =A0I had to go lookup the mea=
ning of &quot;SHALL&quot; (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">&lt;<a href=3D"mailto:drak@zikula.org" target=3D"_bla=
nk">drak@zikula.org</a>&gt;</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">&lt;<a href=3D"mailto:genjix@riseup.net" target=3D"_blank">genjix@=
riseup.net</a>&gt;</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&#39;t have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, &amp; 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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349831&amp;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--