public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: "Eric Larchevêque" <elarch@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address
Date: Fri, 4 Apr 2014 15:54:52 +0200	[thread overview]
Message-ID: <CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]

  parent reply	other threads:[~2014-04-04 13:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 12:15 Eric Larchevêque
2014-04-04 13:08 ` Mike Hearn
2014-04-04 13:22   ` Eric Larchevêque
2014-04-04 13:32     ` Gavin Andresen
2014-04-04 13:47       ` Eric Larchevêque
2014-04-07 20:08       ` Troy Benjegerdes
2014-04-07 21:55         ` Ricardo Filipe
2014-04-07 22:00           ` Eric Martindale
2014-04-04 13:43     ` Mike Hearn
2014-04-04 13:47       ` Jeff Garzik
2014-04-04 13:54       ` Mike Hearn [this message]
2014-04-04 14:42         ` Eric Larchevêque
2014-04-04 14:51           ` Mike Hearn
2014-04-04 14:56             ` Eric Larchevêque
2014-04-08  3:28               ` Jeff Garzik
2014-04-08  8:13                 ` Mike Hearn
2014-04-08 15:19                   ` Jeff Garzik
2014-04-22  6:34                     ` Jan Møller
2014-04-22  8:57                       ` Eric Larchevêque
2014-04-04 15:00             ` slush
2014-04-04 14:56           ` slush
2014-04-04 15:09             ` Eric Larchevêque
2014-04-04 15:28               ` slush
2014-04-04 15:37               ` Mike Hearn
2014-04-04 15:42                 ` slush
2014-04-04 16:00                 ` Eric Larchevêque
2014-04-04 15:03       ` Eric Larchevêque

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com' \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=elarch@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox