From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WW5em-0002NQ-1t for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 15:03:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.175 as permitted sender) client-ip=209.85.217.175; envelope-from=elarch@gmail.com; helo=mail-lb0-f175.google.com; Received: from mail-lb0-f175.google.com ([209.85.217.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WW5ek-0005aY-Sx for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 15:03:48 +0000 Received: by mail-lb0-f175.google.com with SMTP id w7so2588053lbi.34 for ; Fri, 04 Apr 2014 08:03:40 -0700 (PDT) X-Received: by 10.152.36.73 with SMTP id o9mr8955321laj.30.1396623820262; Fri, 04 Apr 2014 08:03:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.31.165 with HTTP; Fri, 4 Apr 2014 08:03:20 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= Date: Fri, 4 Apr 2014 17:03:20 +0200 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=089e0160adf8b1134804f638d23b X-Spam-Score: -0.6 (/) 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 (elarch[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WW5ek-0005aY-Sx Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address 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: Fri, 04 Apr 2014 15:03:48 -0000 --089e0160adf8b1134804f638d23b Content-Type: text/plain; charset=ISO-8859-1 > > > Why do you need it? Because you don't want to implement a login system? > Very, very few websites are the sort of place where they'd want to > authenticate with only a Bitcoin address. If for no other reason than > they'd have no way to email you, and if you lost your wallet, you'd lose > all your associated data. > Well, the major difference is that you could sign up effortlessy to a service, and associate your email later. If more people sign up to more services, it's a good thing for the ecosystem. > > >> Without such a standard protocol, you could never envision a pure Bitcoin >> physical locker rental, or booking an hotel room via Bitcoin and opening >> the door through the paying address. >> > > In future there often won't be a simple paying address. For instance, if > my coins are in a multi-sig relationship with a risk analysis service, > there will be two keys for each input and an arbitrary number of inputs. So > does that mean the risk analysis service gets to open my locker? Why? > > What if I do a shared spend/CoinJoin type tx? Now anyone who took part in > the shared tx with me can get into my hotel room too? > > In a perfect world, you would pay your locker with a "normal" transaction. The same way you shouldn't play satoshi dice from a shared wallet. But your point is totaly valid, and I don't have answer to that except that I'd love to have a Bitcoin authenticated locker in our Bitcoin co working office. > > > These are the kinds of problems that crop up when you mix together two > different things: the act of paying, and the act of identifying yourself. > You're assuming that replacing a password people can remember with a > physical token (their phone) which can be stolen or lost, would be seen as > an upgrade. Given a choice between two physical lockers, one of which lets > me open it with a password and one of which insists on a cryptographic > token, I'm going to go for the former because the chances of me losing my > phone is much higher than me forgetting my password. > > All the tools you need already exist in the form of client certificates, > with the advantage that web servers and web browsers already support them. > The biggest pain point with them is backup and cross-device sync, which of > course wallets suffer from too! > Bitcoin users are normaly already paying some effort to securise and backup their wallets / keys. So it's just about leveraging that. I would myself pick a crypto locker, because I'm the kind of guy who Facebook connects and I follow the easiest path, even if it has long term costs :) Eric --089e0160adf8b1134804f638d23b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Why do you need it? Because you don&#= 39;t want to implement a login system? Very, very few websites are the sort= of place where they'd want to authenticate with only a Bitcoin address= . If for no other reason than they'd have no way to email you, and if y= ou lost your wallet, you'd lose all your associated data.

Well, t= he major difference is that you could sign up effortlessy to a service, and= associate your email later.
If more people sign up to more servi= ces, it's a good thing for the ecosystem.
=A0
=
=A0
=
Without such a standard protoc= ol, you could never envision a pure Bitcoin physical locker rental, or book= ing an hotel room via Bitcoin and opening the door through the paying addre= ss.

In future there often won'= t be a simple paying address. For instance, if my coins are in a multi-sig = relationship with a risk analysis service, there will be two keys for each = input and an arbitrary number of inputs. So does that mean the risk analysi= s service gets to open my locker? Why?
=A0
What if I do a s= hared spend/CoinJoin type tx? Now anyone who took part in the shared tx wit= h me can get into my hotel room too?



In a perfect world, you wou= ld pay your locker with a "normal" transaction.
The sam= e way you shouldn't play satoshi dice from a shared wallet.

But your point is totaly valid, and I don't have answer = to that except that I'd love to have a Bitcoin authenticated locker in = our Bitcoin co working office.
=A0


These are the kinds of problems that cro= p up when you mix together two different things: the act of paying, and the= act of identifying yourself. You're assuming that replacing a password= people can remember with a physical token (their phone) which can be stole= n or lost, would be seen as an upgrade. Given a choice between two physical= lockers, one of which lets me open it with a password and one of which ins= ists on a cryptographic token, I'm going to go for the former because t= he chances of me losing my phone is much higher than me forgetting my passw= ord.

All the tools you need already exist in the form of cli= ent certificates, with the advantage that web servers and web browsers alre= ady support them. The biggest pain point with them is backup and cross-devi= ce sync, which of course wallets suffer from too!


Bitcoin users are normaly already paying some effort to s= ecurise and backup their wallets / keys. So it's just about leveraging = that.

I would mys= elf pick a crypto locker, because I'm the kind of guy who Facebook conn= ects and I follow the easiest path, even if it has long term costs :)

Eric
<= /div> --089e0160adf8b1134804f638d23b--