MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
	<f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 11 Jul 2017 21:31:29 +0000
Message-ID: <CAAS2fgSEZDmgGBxB-ZNqC0NpWQCJSL9xnbaNQFud=sW0Fdgu8w@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
Precedence: list

On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.

A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr.  Next time you seek to represent someone you might want to
try talking to them!

> I am philosophically against hard forks, but HFs were in the end
> of the previous roadmap so I felt it should stay. And, I felt that if I

I think the project is not philosophically against hardforks, at least
not in an absolute sense.

Part of the reason they were discussed in the capacity document was to
make it clear that I wasn't, and to invite other project members to
expose disagreement (though I'd mostly checked in advance...)

But these recently proposed ultra-hasty highly contentious changes,
that seem to be being suggested on shorter and shorter timeframes; I
do think the project is actually opposed to those in a very strong
sense.

But if you were instead to talk about things like fixing timewarp,
recovering header bits, etc. It would clearly be the other way.

At least at the moment computers and bandwidth are improving; I don't
think any regular developers are opposed to hardforks that change
capacity well tech improvements and protocol improvements have made it
obviously not much of a trade-off.

Personally, I wish the project had previously adopted a license that
requires derived works to not accept any block the derived-from work
wouldn't accept for at least two years, or otherwise the derivative
has to be clearly labeled not-bitcoin. :P

In any case, I think it's safe to say that people's opinions on
hardforks are complicated. And all the smoke right now with unusually
poorly executed proposals probably clouds clear thinking.