From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WW4aB-0000l4-8e for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 13:54:59 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.169 as permitted sender) client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f169.google.com; Received: from mail-ob0-f169.google.com ([209.85.214.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WW4aA-0003Eg-9t for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 13:54:59 +0000 Received: by mail-ob0-f169.google.com with SMTP id va2so3566562obc.0 for ; Fri, 04 Apr 2014 06:54:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.62.146 with SMTP id y18mr19543034oer.24.1396619693016; Fri, 04 Apr 2014 06:54:53 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Fri, 4 Apr 2014 06:54:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 15:54:52 +0200 X-Google-Sender-Auth: uqdG13EAT4LSOnxQsJRhZ-SR5iY Message-ID: From: Mike Hearn To: =?UTF-8?Q?Eric_Larchev=C3=AAque?= Content-Type: multipart/alternative; boundary=047d7b6769e8b04e0d04f637dc91 X-Spam-Score: -0.5 (/) 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.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation 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: 1WW4aA-0003Eg-9t 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 13:54:59 -0000 --047d7b6769e8b04e0d04f637dc91 Content-Type: text/plain; charset=UTF-8 > > 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? > Oh, if these seem too abstract, also consider bitbanks. In an ideal world nobody would outsource running of their Bitcoin wallet, but sadly people do, so then they don't control the private keys at all. The goal of writing a BIP seems to be to get lots of different wallet authors to write lots of code for you - but I *am* a wallet author, and I don't think that's the right way to get traction with a new scheme. For instance the TREZOR guys would have to support your new protocol otherwise if I paid my hotel bill with my TREZOR I couldn't open the door when I got there! But they probably have better things to be doing right now. The key difference between just generating a client certificate and using a Bitcoin address is that the client certificate is something that is used *specifically* for identification. It leaves no trace in the block chain, so no weird privacy issues, it doesn't matter how you manage your wallet, and you don't have to persuade lots of people to support your idea because it was already done >10 years ago and basically every browser/web server supports it. Some reasons client certs aren't more widely used boil down to: 1. People like passwords. In particular they like forgetting them and then having friendly people assist them to get it back. Client certs can support this use case, but only if apps are checking the identity in them and not the key. 2. The UI for managing client certs in browsers is pretty horrible. There's little incentive to improve it because of (1). 3. Cross-device sync doesn't work very well. Apple are starting to tackle this with their iCloud Keychain Sync service but then of course, Apple has all your keys and you may well just sign in to things with your Apple account (if it were to be supported). Cross-device sync where the server *doesn't* get your keys is supported by Chrome for passwords, but not client certs, because (1) None of the above issues have any obvious fix lurking within Bitcoin. --047d7b6769e8b04e0d04f637dc91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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?

Oh, if these seem too abstract, also consi= der bitbanks. In an ideal world nobody would outsource running of their Bit= coin wallet, but sadly people do, so then they don't control the privat= e keys at all.

The goal of writing a BIP seems to be to get lots of di= fferent wallet authors to write lots of code for you - but I am=C2= =A0a wallet author, and I don't think that's the right way to get t= raction with a new scheme. For instance the TREZOR guys would have to suppo= rt your new protocol otherwise if I paid my hotel bill with my TREZOR I cou= ldn't open the door when I got there! But they probably have better thi= ngs to be doing right now.

The key difference between just generating a client cer= tificate and using a Bitcoin address is that the client certificate is some= thing that is used specifically=C2=A0for identification. It leaves n= o trace in the block chain, so no weird privacy issues, it doesn't matt= er how you manage your wallet, and you don't have to persuade lots of p= eople to support your idea because it was already done >10 years ago and= basically every browser/web server supports it.

Some reasons client certs aren't more widely used b= oil down to:
  1. People like passwords. In particular they li= ke forgetting them and then having friendly people assist them to get it ba= ck. Client certs can support this use case, but only if apps are checking t= he identity in them and not the key.
  2. The UI for managing client certs in browsers is pretty horrible. There&= #39;s little incentive to improve it because of (1).
  3. Cross-devi= ce sync doesn't work very well. Apple are starting to tackle this with = their iCloud Keychain Sync service but then of course, Apple has all your k= eys and you may well just sign in to things with your Apple account (if it = were to be supported). Cross-device sync where the server doesn't=C2=A0get your keys is supported by Chrome for passwords, but not client c= erts, because (1)
None of the above issues have any obvious fix lurking within Bitc= oin.
--047d7b6769e8b04e0d04f637dc91--