summaryrefslogtreecommitdiff
path: root/58/eaef7f64235c22dc20c65dcfee7885e8d3a440
blob: e0c27d7f788a0cd8aa62a750927d7ca4189cf88a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elarch@gmail.com>) id 1WW5Xq-0001sc-Kb
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 14:56:38 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.178 as permitted sender)
	client-ip=209.85.217.178; envelope-from=elarch@gmail.com;
	helo=mail-lb0-f178.google.com; 
Received: from mail-lb0-f178.google.com ([209.85.217.178])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WW5Xp-0006tK-Pw
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 14:56:38 +0000
Received: by mail-lb0-f178.google.com with SMTP id s7so2515681lbd.23
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 04 Apr 2014 07:56:31 -0700 (PDT)
X-Received: by 10.112.137.193 with SMTP id qk1mr902622lbb.53.1396623390891;
	Fri, 04 Apr 2014 07:56:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.31.165 with HTTP; Fri, 4 Apr 2014 07:56:10 -0700 (PDT)
In-Reply-To: <CANEZrP15xWWq2jU5yKjG+9hp___OovtbH+vM5KkzFcaQ=koRow@mail.gmail.com>
References: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com>
	<CANEZrP0KVyp2Va7Wyy=t0qYkLNK9BDUaSzBfuzQss+=weLJ1Fw@mail.gmail.com>
	<CA+WZAEqYKv8T1OMCKhOJvf5FAy=WujJ=OhtsYP9aBf=4ZPNxmw@mail.gmail.com>
	<CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>
	<CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
	<CA+WZAEqREDkDvmhM7AY+Ju3fkm3uOGm39Ef9+SYoEr43ybbg2Q@mail.gmail.com>
	<CANEZrP15xWWq2jU5yKjG+9hp___OovtbH+vM5KkzFcaQ=koRow@mail.gmail.com>
From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com>
Date: Fri, 4 Apr 2014 16:56:10 +0200
Message-ID: <CA+WZAEpwBqucw7kOFrRn_TsnVGaY0-hm4Xv64_i7LweEzQ=oGw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e01182f961963c404f638b9f9
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: 1WW5Xp-0006tK-Pw
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 14:56:38 -0000

--089e01182f961963c404f638b9f9
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <mike@plan99.net> wrote:

>  My view on this is mainly about the UX and the fact everyone in
>> Bitcoinland has a wallet.
>>
>
> Well, yes, but we also have browsers too :)
>
>
Yes, but no one will ever install a plug in.
And all will update their wallets with the last version, including the auth
protocol.


> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people to use their phone as a second factor - *the simplest
> second factor possible* - was a huge uphill battle that most users just
> didn't care about. People like passwords. If you can find a way to make
> something that's better than a password but just as convenient, fantastic!
> But I don't think Bitcoin addresses are such a thing.
>

I perfectly understand all the objections, and they are very good points.

I have at least two wallets enthousiastic about the project so the protocol
will be implemented and it will give some room to experiment.
The BIP came from the idea we should formalize the standard so all wallets
could participate, and it felt more logical to come forward with it.

Maybe a better strategy would be to start "privately" with a few wallets
and services using the protocol, and to come back to the BIP there is
usability and traction.

Eric

--089e01182f961963c404f638b9f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div><div>My view on this is mainly about the UX and the fact everyone in B=
itcoinland has a wallet.<br></div></div></div></div></div></blockquote><div=
><br></div></div><div>Well, yes, but we also have browsers too :)=A0</div>


<div><br></div></div></div></div></blockquote><div><br></div><div>Yes, but =
no one will ever install a plug in.</div><div>And all will update their wal=
lets with the last version, including the auth protocol.</div><div>=A0</div=
>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div></div><div>I don&#39;t want to suggest the =
problem is unimportant - I&#39;d love it if the world could move beyond pas=
swords. But I have many scars from my time in the Google account swamps. We=
 had a big team, lots of resources and even just getting people to use thei=
r phone as a second factor - <i>the simplest second factor possible</i>=A0-=
 was a huge uphill battle that most users just didn&#39;t care about. Peopl=
e like passwords. If you can find a way to make something that&#39;s better=
 than a password but just as convenient, fantastic! But I don&#39;t think B=
itcoin addresses are such a thing.</div>


</div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I perfectly underst=
and all the objections, and they are very good points.</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">I have at least two wallet=
s enthousiastic about the project so the protocol will be implemented and i=
t will give some room to experiment.</div>

<div class=3D"gmail_extra">The BIP came from the idea we should formalize t=
he standard so all wallets could participate, and it felt more logical to c=
ome forward with it.</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">

Maybe a better strategy would be to start &quot;privately&quot; with a few =
wallets and services using the protocol, and to come back to the BIP there =
is usability and traction.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">

Eric</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
br></div></div>

--089e01182f961963c404f638b9f9--