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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YzSKK-00064m-OR
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 16:12:36 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.180 as permitted sender)
client-ip=209.85.212.180; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f180.google.com;
Received: from mail-wi0-f180.google.com ([209.85.212.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzSKJ-0004gt-7X
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 16:12:36 +0000
Received: by wifw1 with SMTP id w1so111832965wif.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 09:12:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.89.234 with SMTP id br10mr22184241wib.86.1433175149211;
Mon, 01 Jun 2015 09:12:29 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Mon, 1 Jun 2015 09:12:28 -0700 (PDT)
In-Reply-To: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>
References: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>
Date: Mon, 1 Jun 2015 18:12:28 +0200
X-Google-Sender-Auth: _cXmnytj0ISPt2CaNQjjDWC5YxU
Message-ID: <CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=e89a8f3ba2d5ab74d505177717e1
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
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: 1YzSKJ-0004gt-7X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension
blocks)
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: Mon, 01 Jun 2015 16:12:36 -0000
--e89a8f3ba2d5ab74d505177717e1
Content-Type: text/plain; charset=UTF-8
Hi Adam,
I have more experience than Gavin of building consumer wallets, so I'll
make an attempt to answer your questions.
> Then ask the various wallet developer how long it would take them to
> update
> > their software to support something like this,
>
> I don't think thats any particular concern
I am a wallet developer and I am telling you that it is.
> Businesses who are keen to
> have more transactions, would make it their problem to implement in
> their wallet, or ask the wallet vendor/maintainer they're working with
> to do it. Nothing breaks if they dont use it.
I don't see how this is the case. If an exchange supports extension blocks
and I withdraw from that to a wallet that doesn't, the money will never
arrive from my perspective. Yet the exchange will claim they sent it and
they will wash their hands of the matter. Disaster.
I am not a UX guy
>
But I am. I've designed both consumer and engineering UI's at Google, and
also more recently for Lighthouse.
Attempting to explain to a user why they sent money that didn't show up on
the other end is a non starter. It's bad enough when things take a long
time to confirm or bugs cause propagation failures. Doing it
deliberately is not going to work. Payments *must* be reliable and wallets
*must* be compatible with each other.
This is one reason why a Lightning style approach also isn't going to work
any time soon. For example, it would require people to abandon Bitcoin
addresses. I pushed for that before, around the P2SH time, and Gavin
correctly intuited that the community wasn't ready for it yet. I'm not sure
much has changed.
> Because the more complex one is safer, more flexible, more future
> proof and better for decentralisation
I disagree with all of those points. I find Lightning/Stroem etc to be more
dangerous, less flexible, and worse for decentralisation. I explain why
here:
https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
You mentioned decentralisation metrics. Gregory's post is ignoring one of
the most important decentralisation metrics, which is number of wallets
made by independent developers. That has got dramatically better over time.
It would get worse if wallets became more complex very suddenly.
> As an aside, a risk with using companies as a sounding board, is that
> you can get a misleading sense of consensus.
From what I can tell Blockstream employees are just ignoring those
companies entirely, which will give you a radically more distorted view of
the consensus. As companies providing services to our community have
serious economic weight, it stands to reason that their opinions would
matter a great deal. Yet on this mailing list I see zero effort to even
recognise their concerns, let alone care about them.
<https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
Anyway, let me repeat again to make it clear - as someone who has spent
five years writing SPV wallets, I am not on board with extension blocks or
any other Rube Goldberg contraption that exists purely to work around
theoretical objections by Blockstream employees+Peter Todd, which is what
this feels like to me.
--e89a8f3ba2d5ab74d505177717e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Adam,<div><br></div><div>I have more experience than Ga=
vin of building consumer wallets, so I'll make an attempt to answer you=
r questions.<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">> Then ask the various wallet developer how long it woul=
d take them to update<br>
> their software to support something like this,<br>
<br>
I don't think thats any particular concern</blockquote><div><br></div><=
div>I am a wallet developer and I am telling you that it is.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">Businesses who are keen to<br>
have more transactions, would make it their problem to implement in<br>
their wallet, or ask the wallet vendor/maintainer they're working with<=
br>
to do it.=C2=A0 Nothing breaks if they dont use it.</blockquote><div><br></=
div><div>I don't see how this is the case. If an exchange supports exte=
nsion blocks and I withdraw from that to a wallet that doesn't, the mon=
ey will never arrive from my perspective. Yet the exchange will claim they =
sent it and they will wash their hands of the matter. Disaster.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">I am not a UX guy<br></blockquote><div><br></div>=
<div>But I am. I've designed both consumer and engineering UI's at =
Google, and also more recently for Lighthouse.</div><div><br></div><div>Att=
empting to explain to a user why they sent money that didn't show up on=
the other end is a non starter. It's bad enough when things take a lon=
g time to confirm or bugs cause propagation failures. Doing it deliberately=
=C2=A0is not going to work. Payments <i>must</i>=C2=A0be reliable and walle=
ts <i>must</i>=C2=A0be compatible with each other.</div><div><br></div><div=
>This is one reason why a Lightning style approach also isn't going to =
work any time soon. For example, it would require people to abandon Bitcoin=
addresses. I pushed for that before, around the P2SH time, and Gavin corre=
ctly intuited that the community wasn't ready for it yet. I'm not s=
ure much has changed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Because the mo=
re complex one is safer, more flexible, more future<br>
proof and better for decentralisation</blockquote><div><br></div><div>I dis=
agree with all of those points. I find Lightning/Stroem etc to be more dang=
erous, less flexible, and worse for decentralisation. I explain why here:</=
div><div><br></div><div><a href=3D"https://medium.com/@octskyward/the-capac=
ity-cliff-586d1bf7715e">https://medium.com/@octskyward/the-capacity-cliff-5=
86d1bf7715e</a></div><div><br></div><div>You mentioned decentralisation met=
rics. Gregory's post is ignoring one of the most important decentralisa=
tion metrics, which is number of wallets made by independent developers. Th=
at has got dramatically better over time. It would get worse if wallets bec=
ame more complex very suddenly.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As a=
n aside, a risk with using companies as a sounding board, is that<br>
you can get a misleading sense of consensus.=C2=A0</blockquote><div><br></d=
iv><div>From what I can tell Blockstream employees are just ignoring those =
companies entirely, which will give you a radically more distorted view of =
the consensus. As companies providing services to our community have seriou=
s economic weight, it stands to reason that their opinions would matter a g=
reat deal. Yet on this mailing list I see zero effort to even recognise the=
ir concerns, let alone care about them.</div><div>=C2=A0<a href=3D"https://=
lists.sourceforge.net/lists/listinfo/bitcoin-development" target=3D"_blank"=
></a><br>
</div><div>Anyway, let me repeat again to make it clear - as someone who ha=
s spent five years writing SPV wallets, I am not on board with extension bl=
ocks or any other Rube Goldberg contraption that exists purely to work arou=
nd theoretical objections by Blockstream employees+Peter Todd, which is wha=
t this feels like to me.</div><div><br></div></div></div></div></div>
--e89a8f3ba2d5ab74d505177717e1--
|
