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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5wZo-0001NL-1Q for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:43:24 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.181 as permitted sender) client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f181.google.com; Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5wZk-0003ez-A8 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 13:43:24 +0000 Received: by wicgi11 with SMTP id gi11so19138390wic.0 for ; Fri, 19 Jun 2015 06:43:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.209.130 with SMTP id mm2mr25060554wjc.64.1434721394294; Fri, 19 Jun 2015 06:43:14 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.28.14.196 with HTTP; Fri, 19 Jun 2015 06:43:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 15:43:14 +0200 X-Google-Sender-Auth: ve1CSrIWqAEaW0sj-9BC0TtAzqk Message-ID: From: Mike Hearn To: Dr Adam Back Content-Type: multipart/alternative; boundary=047d7b3a82e20f07b30518df1b2c 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: 1Z5wZk-0003ez-A8 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers 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: Fri, 19 Jun 2015 13:43:24 -0000 --047d7b3a82e20f07b30518df1b2c Content-Type: text/plain; charset=UTF-8 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. --047d7b3a82e20f07b30518df1b2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adam,

I am still confused about whether you ac= tually 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 p= osted? 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
<= div>
I think there's been some confusion here.
=
I, at least, have never argued that other systems can nev= er=C2=A0happen. Never is a long time, and I myself maintain a payment c= hannels implementation. These things have their place.

=
The argument is solely around the need to raise the block size now<= /b>=C2=A0and not allow the existing layer 1 to gum up and fall over.
<= div>
If Stroem or Lightning or other block chains or Coinbase= or secure hardware tokens or whatever take off and people start moving bit= coins 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 actua= lly 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 ha= ve all sorts of flaws that lead to it not gaining traction.
=C2= =A0
No offence but please=C2=A0find a way to graceful= ly stop and rejoin the constructive process.=C2=A0You can disagree on facto= rs and points and be collaborative others=C2=A0disagree frequently and have= done productive work cordially for years =C2=A0under 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 p= rocess exists. There is another thread to discuss the lack of such a proces= s.
=C2=A0
- Did you accept payment from com= panies to lobby for 20MB blocks?=C2=A0

Oh p= lease. Conspiracy theories, now, Adam? My position has been consistent for = years. I don't care whether the figure is 20 or something else (looks l= ike it'll be lucky 8 instead), but I have always been clear that the li= mit 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 inter= ested in Lighthouse. Luckily they have given me some leeway to do general B= itcoin development as well, which this business falls under. I would muc= h rather be working on Lighthouse than this, and so would they.

But seeing as you've gone there - let me flip this ar= ound. 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 pr= oducts:
  1. Sidechains, a very complex approach to avoid chan= ging 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 mus= t 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 t= hey should be using your companies products.

I kno= w that many of you guys had these views before joining Blockstream. I am no= t saying you are being paid to have views you didn't previously have. I= realise that birds of a feather flock together.=C2=A0

=
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.
=C2=A0
With respect to user rights= : all the polling done so far suggests users who are paying attention stron= gly support increasing the block size. For example:

Q: "Should the bitcoin block size be raised in the next two years&qu= ot;
A: 92% yes


Additionally, = many Bitcoin users have explicitly delegated handling the technical details= to someone else, like a payment processor or their wallet developers. Thos= e 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 force= s. Companies live for their users, and many of those companies were formed = by long time Bitcoin users.

And finally, the Bitco= in 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 contr= act 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 n= ever 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= 9;d be controversial and nothing would happen. But Satoshi never anticipate= d this bizarre attempt to turn the project into something else and so figur= ed he'd just remove it himself later. Too bad.

--047d7b3a82e20f07b30518df1b2c--