From: Mike Hearn <mike@plan99•net>
To: Dr Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Fri, 19 Jun 2015 15:43:14 +0200 [thread overview]
Message-ID: <CANEZrP2iGUnU+BKzYOzNZJUPNOU_5d4oU8JRgGLS1iPtz-uRWA@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTFx6DF0Re+pCwB1AjYo6eYuKtX1cqUpo=wXmHSOsN74dQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]
Hi Adam,
I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this "layer 2" you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will support
Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but
does/soon will have some code associated with it.
But if we do no R&D on layer2, and insist that clients can never
> change to become layer2 aware, and layer2 is too hard etc
>
I think there's been some confusion here.
I, at least, have never argued that other systems can *never* happen. Never
is a long time, and I myself maintain a payment channels implementation.
These things have their place.
The argument is solely around the need to raise the block size *now* and
not allow the existing layer 1 to gum up and fall over.
If Stroem or Lightning or other block chains or Coinbase or secure hardware
tokens or whatever take off and people start moving bitcoins around that
way - fine. If they're choosing it of their own free will I have no issue
with that, nor does anyone else, I suspect.
However you don't seem fully confident that people actually will choose
whatever is being cooked up as "layer 2", if left to their own devices.
Indeed it's impossible for anyone to know that, as no "layer 2" actually
exists. Any such implementation could have all sorts of flaws that lead to
it not gaining traction.
> No offence but please find a way to gracefully stop and rejoin the
> constructive process. You can disagree on factors and points and be
> collaborative others disagree frequently and have done productive work
> cordially for years under the BIP process.
As you know from the discussion with myself and Gavin a few days ago on
IRC, neither of us believe any such constructive process exists. There is
another thread to discuss the lack of such a process.
> - Did you accept payment from companies to lobby for 20MB blocks?
Oh please. Conspiracy theories, now, Adam? My position has been consistent
for years. I don't care whether the figure is 20 or something else (looks
like it'll be lucky 8 instead), but I have always been clear that the limit
must rise.
But for the avoidance of doubt: the answer is no.
Gavin is paid by MIT. The MIT deal gives Gavin complete independence.
I am currently self employed and most of income comes from a client that is
actually interested in Lighthouse. Luckily they have given me some leeway
to do general Bitcoin development as well, which this business falls under.
I would *much* rather be working on Lighthouse than this, and so would they.
But seeing as you've gone there - let me flip this around. Blockstream has
a very serious conflict of interest in this situation. I am by no means the
first to observe this. You are building two major products:
1. Sidechains, a very complex approach to avoid changing the Bitcoin
consensus rules to add new features.
2. Lightning, a so-called "layer two" system for transaction routing
No surprise, the position of Blockstream employees is that hard forks must
never happen and that everyone's ordinary transactions should go via some
new network that doesn't yet exist.
The problem is that rather than letting the market decide between ordinary
Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin
protocol because you don't trust people to spontaneously realise that they
should be using your companies products.
I know that many of you guys had these views before joining Blockstream. I
am not saying you are being paid to have views you didn't previously have.
I realise that birds of a feather flock together.
Regardless, that conflict of interest DOES exist, whether you like it or
not, because if you succeed in running Bitcoin out of capacity your own
company stands to benefit from selling consulting and services around your
preferred solutions.
With respect to user rights: all the polling done so far suggests users who
are paying attention strongly support increasing the block size. For
example:
Q: "Should the bitcoin block size be raised in the next two years"
A: 92% yes
http://www.poll-maker.com/results329839xee274Cb0-12#tab-2
Additionally, many Bitcoin users have explicitly delegated handling the
technical details to someone else, like a payment processor or their wallet
developers. Those people are nearly all sure that the block size limit
should rise too.
So please don't engage in idle speculation about "users vs companies". They
aren't some kind of opposing forces. Companies live for their users, and
many of those companies were formed by long time Bitcoin users.
And finally, the Bitcoin social contract is not defined by whatever random
state the code was in at the time Gavin decided to focus on research. Both
Gavin and I have been working on Bitcoin longer than you, Gregory or Peter
Todd. The social contract was and still is defined by the project's
founding vision - written down in words.
Heck, if Satoshi had spent another hour or two on his original size limiter
patch this entire dispute would never have happened. He'd have put in some
kind of automatic timeout or limit riser because the plan was to remove it
all along, and then it'd be you guys arguing for putting a limit in place,
Gavin would object, it'd be controversial and nothing would happen. But
Satoshi never anticipated this bizarre attempt to turn the project into
something else and so figured he'd just remove it himself later. Too bad.
[-- Attachment #2: Type: text/html, Size: 7071 bytes --]
next prev parent reply other threads:[~2015-06-19 13:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 9:22 Dr Adam Back
2015-06-19 10:45 ` Dr Adam Back
2015-06-19 11:35 ` Bryan Bishop
2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 12:02 ` Eric Lombrozo
2015-06-19 12:48 ` Marcel Jamin
2015-06-19 12:49 ` Eric Lombrozo
2015-06-19 13:43 ` Mike Hearn [this message]
2015-06-20 2:59 ` Tom Harding
2015-06-19 16:05 ` Milly Bitcoin
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=CANEZrP2iGUnU+BKzYOzNZJUPNOU_5d4oU8JRgGLS1iPtz-uRWA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.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