From: Gregory Maxwell <greg@xiph•org>
To: Steven Pine <steven.pine@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Date: Sat, 15 Apr 2017 04:47:43 +0000 [thread overview]
Message-ID: <CAAS2fgTwfn0RzjxVe1R5FL842y2x-GK9LvcpxWuFpSmi2zy-Qg@mail.gmail.com> (raw)
In-Reply-To: <CAAjy6kBHo9adDSVSn6mDqm07q8c+8FN_eOyOz8GS=sLzoj+02Q@mail.gmail.com>
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.
next prev parent reply other threads:[~2017-04-15 4:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-14 7:56 Gregory Maxwell
2017-04-14 16:50 ` praxeology_guy
2017-04-14 17:36 ` Chris Stewart
2017-04-14 18:33 ` praxeology_guy
2017-04-14 19:12 ` Tom Zander
2017-04-14 19:20 ` Tom Zander
2017-04-14 19:33 ` James Hilliard
2017-04-14 20:34 ` Tom Zander
2017-04-14 20:51 ` James Hilliard
2017-04-14 20:58 ` Tom Zander
2017-04-14 21:10 ` James Hilliard
2017-04-14 21:12 ` Gregory Maxwell
2017-04-14 20:59 ` Gregory Maxwell
2017-04-15 2:01 ` Steven Pine
2017-04-15 3:05 ` Chris Stewart
2017-04-15 3:29 ` Gregory Maxwell
2017-04-15 4:10 ` Steven Pine
2017-04-15 4:47 ` Gregory Maxwell [this message]
2017-04-15 6:28 ` Cameron Garnham
2017-04-15 7:04 ` Gregory Maxwell
2017-04-15 7:46 ` Chris Acheson
2017-04-15 13:23 ` Natanael
2017-04-15 13:54 ` Greg Sanders
2017-04-15 8:05 ` Cameron Garnham
2017-04-20 18:39 ` shaolinfry
2017-04-25 18:28 ` Gregory Maxwell
2017-04-25 18:46 ` Luke Dashjr
2017-05-02 16:54 ` Erik Aronesty
2017-05-22 19:23 ` Suhas Daftuar
2017-05-23 4:03 ` Steven Pine
2017-05-23 6:30 ` Karl Johan Alm
2017-05-23 12:55 ` Luke Dashjr
2017-05-23 13:20 ` Jorge Timón
2017-05-23 9:47 ` Hampus Sjöberg
2017-04-14 10:52 Chris Acheson
2017-04-15 13:42 Mark Friedenbach
2017-04-15 14:54 ` Ryan Grant
2017-04-15 18:50 ` Gregory Maxwell
2017-04-19 16:17 ` Erik Aronesty
2017-04-20 14:23 ` Alphonse Pace
2017-04-20 15:48 ` Erik Aronesty
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=CAAS2fgTwfn0RzjxVe1R5FL842y2x-GK9LvcpxWuFpSmi2zy-Qg@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=steven.pine@gmail$(echo .)com \
/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