From: CalvinRechner <calvinrechner@protonmail•com>
To: Oliver Petruzel <opetruzel@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Date: Tue, 30 May 2017 18:20:25 -0400 [thread overview]
Message-ID: <-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com> (raw)
In-Reply-To: <CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5702 bytes --]
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: opetruzel@gmail•com
To: CalvinRechner <calvinrechner@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
[-- Attachment #2: Type: text/html, Size: 8179 bytes --]
next prev parent reply other threads:[~2017-05-30 22:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-29 1:18 CalvinRechner
2017-05-29 10:19 ` James Hilliard
2017-05-29 22:52 ` Erik Aronesty
2017-05-29 23:49 ` Oliver Petruzel
2017-05-30 15:51 ` Erik Aronesty
2017-05-30 22:20 ` CalvinRechner [this message]
2017-06-02 20:13 ` Jared Lee Richardson
2017-06-02 21:57 ` Sergio Demian Lerner
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='-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com' \
--to=calvinrechner@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=opetruzel@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