From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension blocks)
Date: Mon, 1 Jun 2015 18:12:28 +0200 [thread overview]
Message-ID: <CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4642 bytes --]
next prev parent reply other threads:[~2015-06-01 16:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 15:40 [Bitcoin-development] soft-fork block size increase (extension blocks) Adam Back
2015-06-01 16:12 ` Mike Hearn [this message]
2015-06-01 17:21 ` Adam Back
2015-06-01 18:01 ` Mike Hearn
2015-06-01 18:39 ` [Bitcoin-development] soft-fork block size increase (extensionblocks) Raystonn .
2015-06-02 0:42 ` [Bitcoin-development] soft-fork block size increase (extension blocks) Tom Harding
2015-06-17 16:17 ` Richard Moore
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='CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com' \
--to=mike@plan99.net \
--cc=adam@cypherspace.org \
--cc=bitcoin-development@lists.sourceforge.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