From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Mon, 1 Jun 2015 18:12:28 +0200 X-Google-Sender-Auth: _cXmnytj0ISPt2CaNQjjDWC5YxU Message-ID: From: Mike Hearn To: Adam Back 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. 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
Hi Adam,

I have more experience than Ga= vin of building consumer wallets, so I'll make an attempt to answer you= r questions.

<= 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
> their software to support something like this,

I don't think thats any particular concern

<= div>I am a wallet developer and I am telling you that it is.
=C2= =A0
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<= br> to do it.=C2=A0 Nothing breaks if they dont use it.

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

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 must=C2=A0be reliable and walle= ts must=C2=A0be 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 corre= ctly intuited that the community wasn't ready for it yet. I'm not s= ure much has changed.
=C2=A0
Because the mo= re complex one is safer, more flexible, more future
proof and better for decentralisation

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:


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.
=C2=A0
As a= n aside, a risk with using companies as a sounding board, is that
you can get a misleading sense of consensus.=C2=A0

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.
=C2=A0
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.

--e89a8f3ba2d5ab74d505177717e1--