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 ) 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 ; 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: References: <20131219131706.GA21179@savin> <538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net> Date: Thu, 19 Dec 2013 09:23:18 -0800 Message-ID: From: Mike Belshe To: Drak 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 , Bitcoin Dev , Amir Taaki 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On 19 December 2013 16:04, Amir Taaki 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
Hey Peter -

I think this is a super lis= t. =A0 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 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:
=A0 =A0 1) wallets SHOULD use multi-factor authentication before autho= rizing access to a wallet (e.g. view balances, addresses, transactions, etc= )
=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]

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:
=A0 =A0 - Wallets SHOULD NOT cre= ate two keys on a single host or device
=A0 =A0 - Wallets SHOULD provide a way to import external public keys = which can be used as part of a P2SH address

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.

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


Thanks,
mike








On Thu, Dec 19, 2013 at 8:32 AM, D= rak <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-fo= r-git-commit-td2582986.html

Yeah, it ma= kes 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<= br> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami= cs Pro!
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--bcaec52d581debb6c104ede66ae7--