On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine <steven.p...@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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
