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--