MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CAAjy6kBHo9adDSVSn6mDqm07q8c+8FN_eOyOz8GS=sLzoj+02Q@mail.gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<CAAjy6kAi6L9=4tgtay3m3YUk8SLs3NxD0JXp78TWmJXVMNfASQ@mail.gmail.com>
	<CAAS2fgSekez6+o+9VU3rPSAyxuA+tzVfiyJJcx-_a8h0_Uq4fw@mail.gmail.com>
	<CAAjy6kBHo9adDSVSn6mDqm07q8c+8FN_eOyOz8GS=sLzoj+02Q@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Sat, 15 Apr 2017 04:47:43 +0000
Message-ID: <CAAS2fgTwfn0RzjxVe1R5FL842y2x-GK9LvcpxWuFpSmi2zy-Qg@mail.gmail.com>
To: Steven Pine <steven.pine@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine <steven.pine@gmail.com> wrote:
> but segwit does
> have a 'time out' as defined in BIP 9 with the date of November 15th?

There is a technical requirement that BIP 9 bit allocations must have
a timeout so that a bit is not forever burned if a proposal is ever
abandoned (e.g. because something better came along before it
activated).  This isn't a timeout for the proposal, but for the bit
assignment.  If a proposal hasn't activated but there is still
interest it will just get a new bit (and can alternate back and forth
between a pair). This is a timeout of the bit, not the proposal.

It has to be setup this way because there is no real way to
communicate abandonment to old software, so a timeout must be set in
advance.

> Does core plan

"Core" doesn't plan on much of anything beyond the immediate pipeline
of activities, similar to other large open source collaboration, or
open standards development organizations. It isn't a company.
Individuals have plans about their own work which they may collaborate
in one place or another.

But allocating a new bit is how BIP9 works.

> meaning was every census change has gone through a core defined process (not
> counting the changes that occurred before there were BIPs and such), isn't

What is a "core defined process"?  BIP _itself_ was created by someone
who, AFAICT, has never made a commit to Bitcoin Core.  Numbers are
currently assigned, a nearly judgement-less administrative task, by
someone that authors competing fork of the software (Knots).

> it would seem like the first time census occurred outside core

Yet it was proposed on this list, had a BIP defined... if it got
eventually used it would presumably end up in the Bitcoin Core project
eventually... so what exactly is your definition of outside? Above you
seemed to be saying a BIP was not outside, but here you are saying
something documented as a BIP is outside?

If your preference is to not insult then it may be advisable to not
disregard distinctions which you do not understand as semantics. :) I
am not prone to arguing over semantics-- the continually binning in
almost all public collaboration as the work of some centralized entity
is really harmful to our community. The distinction is real, and not
semantics.

> To be clear, the fast and reckless part for you is the mechanism by which
> segwit could possibly be made active? Do you envision a means of segwit
> being made consensus that does not have 95% mining support?

Sure, and I said so directly in my message.  I believe I was
adequately clear that my complaint about BIP148 is specifically that
it has forced orphaning of passive participants which can be easily
avoided but at the expense of actually needed users to adopt the
change.

For clarity, it could be summarized as: I would not classify BIP148 as
a user activated soft-fork but instead as "user enforced miner
soft-fork activation". The consequence of this is that it likely
cannot achieve low disruptiveness-- this limitation would be excusable
if we weren't aware of any alternative, but in this case we are and
the only relative downside of it is that users will need to upgrade
for it-- which should not be a problem in principle if we believe a
UASF is really user activated.