path: root/af/c646b0c48dede5212a0401e284406592c58616

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Xn91U-00041F-5F
	for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Nov 2014 16:38:00 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.42 as permitted sender)
	client-ip=209.85.215.42; envelope-from=mh.in.england@gmail.com;
	helo=mail-la0-f42.google.com; 
Received: from mail-la0-f42.google.com ([209.85.215.42])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Xn91S-0004JO-5G
	for bitcoin-development@lists.sourceforge.net;
	Sat, 08 Nov 2014 16:38:00 +0000
Received: by mail-la0-f42.google.com with SMTP id gq15so5906071lab.15
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 08 Nov 2014 08:37:51 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.157.194 with SMTP id wo2mr18299812lbb.55.1415464671727; 
	Sat, 08 Nov 2014 08:37:51 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.25.91.147 with HTTP; Sat, 8 Nov 2014 08:37:51 -0800 (PST)
Received: by 10.25.91.147 with HTTP; Sat, 8 Nov 2014 08:37:51 -0800 (PST)
In-Reply-To: <CAJHLa0Or1RW0k+FP+hu-GTv+DdZZ=P=ptO1qr=qAHVMQok2w1Q@mail.gmail.com>
References: <CANEZrP3Pk3O3uFJtDkO9BfVogbaiWt1SmMrP02fRBpt3TtMrtg@mail.gmail.com>
	<CAJHLa0Or1RW0k+FP+hu-GTv+DdZZ=P=ptO1qr=qAHVMQok2w1Q@mail.gmail.com>
Date: Sat, 8 Nov 2014 17:37:51 +0100
X-Google-Sender-Auth: Z0mSzYrh1lkImjeJ7x-8uaE_cVE
Message-ID: <CANEZrP3TDZWDSeEQe9jCGfOphkUMPyFpVbF-z_y1=09PVa4FkQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=001a11c33f5ef358ab05075b8c22
X-Spam-Score: -0.2 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
	[URIs: bitpay.com]
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Xn91S-0004JO-5G
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Update on mobile 2-factor wallets
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: Sat, 08 Nov 2014 16:38:00 -0000

--001a11c33f5ef358ab05075b8c22
Content-Type: text/plain; charset=UTF-8

Yes. I think one of the next things we need is a library that produces nice
and attractive PDFs of "wallet certificates" so it's easy to print out a
paper backup.

But the whole field of secure key escrow needs more research. Banking gives
people the very nice property that you can lose literally everything except
your face and still retain access to your money, so people feel very safe
with that. Matching that experience doesn't seem possible at the moment, so
being your own bank will continue to seem much riskier than just using a
real one.
On 8 Nov 2014 17:21, "Jeff Garzik" <jgarzik@bitpay.com> wrote:

> Overall, super duper awesome.  :)  Tweeted this post.
>
> I do have a concern about 2-of-2 arrangements.  To me, this screams
> "twice as fragile" if not done properly; and I've seen a few naive
> implementations in the field that seemed quite fragile.
>
> 2FA/2-of-2 does solve the common problem of single device compromise.
> It also makes funds unspendable if -either- device's keys become lost.
>
>
>
> On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn <mike@plan99.net> wrote:
> > Here is a summary of current developments in the space of decentralised
> > 2-factor Bitcoin wallets. I figured some people here might find it
> > interesting.
> >
> > There has been very nice progress in the last month or two. Decentralised
> > 2FA wallets run on a desktop/laptop and have a (currently always Android)
> > smartphone app to go with them. Compromise of the wallet requires
> compromise
> > of both devices.
> >
> > Alon Muroch and Chris Pacia have made huge progress on "Bitcoin
> > Authenticator", their (HD) wallet app. The desktop side runs on
> > Win/Mac/Linux and the mobile side runs on Android. Sending money from the
> > desktop triggers a push notification to the mobile side, which presents
> the
> > transaction for confirmation. Additionally the desktop wallet has a
> variety
> > of other features like OneName integration. It's currently in alpha, but
> I
> > suspect it will be quite popular once released due to its focus on UI and
> > the simple mobile security model. I've tried it out and it worked fine.
> >
> > https://www.bitcoinauthenticator.org/
> > https://github.com/cpacia/BitcoinAuthenticator/commits/master
> (mobile)
> > https://github.com/negedzuregal/BitcoinAuthWallet   (desktop)
> >
> > Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor
> > functionality. However, this has various downsides that are well known:
> > less support for the address type and larger transactions that waste
> block
> > chain space + result in higher fees.
> >
> > To solve this problem Christopher Mann and Daniel Loebenberger from Uni
> Bonn
> > have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and
> > Reiter to ECDSA, and implemented their own desktop/Android wallet app
> pair
> > showing that it works and has good enough performance. This means that
> P2SH
> > / CHECKMULTISIG is no longer required for the two factor auth case, and
> thus
> > it's as cheap as using regular addresses.
> >
> > https://github.com/ChristopherMann/2FactorWallet
> > https://eprint.iacr.org/2014/629.pdf
> >
> > Their protocol uses an interesting combination of ECDSA, Paillier
> > homomorphic encryption and some zero knowledge proofs to build a working
> > solution for the 2-of-2 case only. Their app bootstraps from a QR code
> that
> > includes a TLS public key and IP address of the desktop: the mobile app
> then
> > connects to it directly, renders the transaction and performs the
> protocol
> > when the user confirms. The protocol is online, so both devices must be
> > physically present.
> >
> > Their code is liberally licensed and looks easy to integrate with Alon
> and
> > Chris' more user focused work, as both projects are built with Android
> and
> > the latest bitcoinj. If someone is interested, merging
> Christopher/Daniel's
> > code into the bitcoinj multisig framework would be a useful project, and
> > would make it easier for wallet devs to benefit from this work. I can
> write
> > a design doc to follow if needed.
> >
> > Currently, neither of these projects implement support for BIP70, so the
> > screen you see when signing the transaction is hardly user friendly or
> > secure: you just have to trust that the destination address you're
> paying to
> > isn't tampered with. Support for sending a full payment request between
> > devices is the clear next step once these wallets have obtained a
> reasonable
> > user base and are stable.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>

--001a11c33f5ef358ab05075b8c22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Yes. I think one of the next things we need is a library tha=
t produces nice and attractive PDFs of &quot;wallet certificates&quot; so i=
t&#39;s easy to print out a paper backup. </p>
<p dir=3D"ltr">But the whole field of secure key escrow needs more research=
. Banking gives people the very nice property that you can lose literally e=
verything except your face and still retain access to your money, so people=
 feel very safe with that. Matching that experience doesn&#39;t seem possib=
le at the moment, so being your own bank will continue to seem much riskier=
 than just using a real one.</p>
<div class=3D"gmail_quote">On 8 Nov 2014 17:21, &quot;Jeff Garzik&quot; &lt=
;<a href=3D"mailto:jgarzik@bitpay.com">jgarzik@bitpay.com</a>&gt; wrote:<br=
 type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Overall, super duper a=
wesome.=C2=A0 :)=C2=A0 Tweeted this post.<br>
<br>
I do have a concern about 2-of-2 arrangements.=C2=A0 To me, this screams<br=
>
&quot;twice as fragile&quot; if not done properly; and I&#39;ve seen a few =
naive<br>
implementations in the field that seemed quite fragile.<br>
<br>
2FA/2-of-2 does solve the common problem of single device compromise.<br>
It also makes funds unspendable if -either- device&#39;s keys become lost.<=
br>
<br>
<br>
<br>
On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn &lt;<a href=3D"mailto:mike@plan9=
9.net">mike@plan99.net</a>&gt; wrote:<br>
&gt; Here is a summary of current developments in the space of decentralise=
d<br>
&gt; 2-factor Bitcoin wallets. I figured some people here might find it<br>
&gt; interesting.<br>
&gt;<br>
&gt; There has been very nice progress in the last month or two. Decentrali=
sed<br>
&gt; 2FA wallets run on a desktop/laptop and have a (currently always Andro=
id)<br>
&gt; smartphone app to go with them. Compromise of the wallet requires comp=
romise<br>
&gt; of both devices.<br>
&gt;<br>
&gt; Alon Muroch and Chris Pacia have made huge progress on &quot;Bitcoin<b=
r>
&gt; Authenticator&quot;, their (HD) wallet app. The desktop side runs on<b=
r>
&gt; Win/Mac/Linux and the mobile side runs on Android. Sending money from =
the<br>
&gt; desktop triggers a push notification to the mobile side, which present=
s the<br>
&gt; transaction for confirmation. Additionally the desktop wallet has a va=
riety<br>
&gt; of other features like OneName integration. It&#39;s currently in alph=
a, but I<br>
&gt; suspect it will be quite popular once released due to its focus on UI =
and<br>
&gt; the simple mobile security model. I&#39;ve tried it out and it worked =
fine.<br>
&gt;<br>
&gt; <a href=3D"https://www.bitcoinauthenticator.org/" target=3D"_blank">ht=
tps://www.bitcoinauthenticator.org/</a><br>
&gt; <a href=3D"https://github.com/cpacia/BitcoinAuthenticator/commits/mast=
er" target=3D"_blank">https://github.com/cpacia/BitcoinAuthenticator/commit=
s/master</a>=C2=A0 =C2=A0 (mobile)<br>
&gt; <a href=3D"https://github.com/negedzuregal/BitcoinAuthWallet" target=
=3D"_blank">https://github.com/negedzuregal/BitcoinAuthWallet</a>=C2=A0 =C2=
=A0(desktop)<br>
&gt;<br>
&gt; Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor<=
br>
&gt; functionality. However, this has various downsides that are well known=
:<br>
&gt; less support for the address type and larger transactions that waste b=
lock<br>
&gt; chain space + result in higher fees.<br>
&gt;<br>
&gt; To solve this problem Christopher Mann and Daniel Loebenberger from Un=
i Bonn<br>
&gt; have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and=
<br>
&gt; Reiter to ECDSA, and implemented their own desktop/Android wallet app =
pair<br>
&gt; showing that it works and has good enough performance. This means that=
 P2SH<br>
&gt; / CHECKMULTISIG is no longer required for the two factor auth case, an=
d thus<br>
&gt; it&#39;s as cheap as using regular addresses.<br>
&gt;<br>
&gt; <a href=3D"https://github.com/ChristopherMann/2FactorWallet" target=3D=
"_blank">https://github.com/ChristopherMann/2FactorWallet</a><br>
&gt; <a href=3D"https://eprint.iacr.org/2014/629.pdf" target=3D"_blank">htt=
ps://eprint.iacr.org/2014/629.pdf</a><br>
&gt;<br>
&gt; Their protocol uses an interesting combination of ECDSA, Paillier<br>
&gt; homomorphic encryption and some zero knowledge proofs to build a worki=
ng<br>
&gt; solution for the 2-of-2 case only. Their app bootstraps from a QR code=
 that<br>
&gt; includes a TLS public key and IP address of the desktop: the mobile ap=
p then<br>
&gt; connects to it directly, renders the transaction and performs the prot=
ocol<br>
&gt; when the user confirms. The protocol is online, so both devices must b=
e<br>
&gt; physically present.<br>
&gt;<br>
&gt; Their code is liberally licensed and looks easy to integrate with Alon=
 and<br>
&gt; Chris&#39; more user focused work, as both projects are built with And=
roid and<br>
&gt; the latest bitcoinj. If someone is interested, merging Christopher/Dan=
iel&#39;s<br>
&gt; code into the bitcoinj multisig framework would be a useful project, a=
nd<br>
&gt; would make it easier for wallet devs to benefit from this work. I can =
write<br>
&gt; a design doc to follow if needed.<br>
&gt;<br>
&gt; Currently, neither of these projects implement support for BIP70, so t=
he<br>
&gt; screen you see when signing the transaction is hardly user friendly or=
<br>
&gt; secure: you just have to trust that the destination address you&#39;re=
 paying to<br>
&gt; isn&#39;t tampered with. Support for sending a full payment request be=
tween<br>
&gt; devices is the clear next step once these wallets have obtained a reas=
onable<br>
&gt; user base and are stable.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
<br>
<br>
--<br>
Jeff Garzik<br>
Bitcoin core developer and open source evangelist<br>
BitPay, Inc.=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://bitpay.com/" target=3D"=
_blank">https://bitpay.com/</a><br>
</blockquote></div>

--001a11c33f5ef358ab05075b8c22--