In principle, there is complete flexibility when it comes to the specific
consensus details of the hard fork. One common suggestion has been to phase in
a gradual blocksize increase beyond the initial 2MB cap included in Luke-Jr's
proposal (a la BIP103); this would certainly be a welcome inclusion in the
Omnibus Proposal, provided that is what we want. The reasoning behind
incorporating Luke-Jr's 2MB limit and discount-rebalancing was to satisfy the
conditions of the Scaling Agreement while ensuring maximum safety, minimum code
discrepancies, and minimum controversy among the community; these priorities
seem imperative, considering the extreme timeline constraints we are working
under and the goals of the proposal. To put it more simply, the intent of the
proposal was to serve as a template for the minimum viable fork that can
achieve true consensus. A gradual increase to a larger size cap, especially if
it were reasonably conservative, would be wholly in accordance with the Omnibus
Proposal if that is what it takes to achieve the cooperation between community,
industry, and developers in this critical moment of Bitcoin's history.
The purpose of the Omnibus Proposal is singlefold: to achieve the goals of the
Consensus 2017 Scaling Agreement in the most maximally-compatible way. We can
minimize disruption and loss potential all around by solving these problems in
a compatibility-oriented manner. It is possible to fulfill both the letter and
the spirit of the Scaling Agreement, to the complete satisfaction of all
involved, while preventing chain-split risks in the meantime.
There is no justification for incompatibility with existing deployment
approaches, when there is the possibility to work together towards our mutual
goals instead. The most rational option is to join forces and avoid any
chain-split potential for as long as possible. Under the Omnibus Proposal, once
SegWit is activated, the terms of the hard fork are locked in automatically,
set to activate 6 months later. The proposal guarantees that a successful
SegWit activation is followed by a hard fork. Beyond enforcing the hard fork
rules beginning at block height HardForkHeight, the Omnibus Proposal simply
represents compatibility with the existing SegWit-activation deployment
approaches.
By committing to this proposal, we can ensure unity, at least for now. There do
not appear to be any arguments to the contrary. Why squander this opportunity
for consensus and harmony? We can leverage the momentum of several disparate
movements, and perhaps enjoy some much-needed social solidarity. In a way,
everyone can get what they want, and through cooperation, we avoid the risk of
a costly fracture.
The Segwit2x Team has begun work on an implementation of the Consensus Scaling
Agreement, their operational timeline including the publication of a BIP on
June 16, 2017.[1] I call upon the developers and maintainers of this initiative
to consider and honor the Omnibus Proposal, extended or modified as needed, as
the guiding approach to your development effort. Almost every component of the
code exists, in some form or fashion, in the various constituent proposals'
reference implementations, most of which have already undergone a significant
degree of peer review.
We cannot afford to delay, nor to reimplement; the launch timeline is
aggressively optimistic as it is. The quickest and safest approach to achieving
the goals set forth at Consensus 2017 is to leverage the existing tools and
proposals for the job. We can solve our problems properly, cooperatively.
I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the other
wonderful, intelligent collaborators on this project step forward and support
the cooperative, compatibility-oriented approach of the Omnibus Proposal.
This is the best way to maximize value for everyone. We have a real opportunity
to collaborate and work together on the same team. The Omnibus Proposal,
designed in exact accordance with a powerful industry agreement and
incorporating the feedback and suggestions provided from within both the
developer community and the community-at-large, stands the best chance of
uniting everyone under a common front.
Please, for the love of Bitcoin, let us do our best to cooperate.
[1] https://imgur.com/a/a2oPs
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Local Time: May 29, 2017 6:49 PM
UTC Time: May 29, 2017 11:49 PM
From: opetru...@gmail.com
To: CalvinRechner <calvinrech...@protonmail.com>
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
>>if the community wishes to adopt (by unanimous consensus) a 2 MB block size
>>hardfork, this is probably the best way to do it right now... Legacy Bitcoin
>>transactions are given the witness discount, and a block size limit of 2 MB
>>is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results in
~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is increased to
2000000 bytes and Total Weight is increased to 8000000 bytes. With normal
usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind this
decision?
I'd love to be armed with a good answer should my colleagues ask me the same
obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
