public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Eric Larchevêque" <elarch@gmail.com>
To: Mike Hearn <mike@plan99.net>
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 17:03:20 +0200	[thread overview]
Message-ID: <CA+WZAErj0KJ0ptHF+EVFxhpkPzUw32t6ztYgwNh=fVL0Wu3vmQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>

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

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

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

      parent reply	other threads:[~2014-04-04 15:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 12:15 [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address 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
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 [this message]

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='CA+WZAErj0KJ0ptHF+EVFxhpkPzUw32t6ztYgwNh=fVL0Wu3vmQ@mail.gmail.com' \
    --to=elarch@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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