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 --]
prev 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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