From: Jeremy <jlrubin@mit•edu>
To: Michael Folkson <michaelfolkson@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Date: Mon, 11 Oct 2021 12:12:58 -0700 [thread overview]
Message-ID: <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com> (raw)
In-Reply-To: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]
*> ... in this post I will argue against frequent soft forks with a single
or minimal*
*> set of features and instead argue for infrequent soft forks with batches*
*> of features.*
I think this type of development has been discussed in the past and has
been rejected.
from: Matt Corallo's post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
*Matt: Follow the will of the community, irrespective of individuals
orunreasoned objection, but without ever overruling any
reasonableobjection. Recent history also includes "objection" to soft forks
in theform of "this is bad because it doesn't fix a different problem I
wantfixed ASAP". I don't think anyone would argue this qualifies as
areasonable objection to a change, and we should be in a place, as
acommunity (never as developers or purely one group), to ignore
suchobjections and make forward progress in spite of them. We don't
makegood engineering decisions by "bundling" unrelated features together to*
*enable political football and compromise.*
*AJ: - improvements: changes might not make everyone better off, but we*
* don't want changes to screw anyone over either -- pareto improvements
in economics, "first, do no harm", etc. (if we get this right, there's no
need to make compromises and bundle multiple flawed proposals so that
everyone's an equal mix of happy and*
* miserable)*
I think Matt and AJ's PoV is widely reflected in the community that
bundling changes leads to the inclusion of suboptimal features.
This also has strong precedent in other important technical bodies, e.g.
from https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming
in the IETF.
Even worse is the "horse-trading" sort of compromise: "I object to
your proposal for such-and-so reasons. You object to my proposal for
this-and-that reason. Neither of us agree. If you stop objecting to
my proposal, I'll stop objecting to your proposal and we'll put them
both in." That again results in an "agreement" of sorts, but instead
of just one outstanding unaddressed issue, this sort of compromise
results in two, again ignoring them for the sake of expedience.
These sorts of "capitulation" or "horse-trading" compromises have no
place in consensus decision making. In each case, a chair who looks
for "agreement" might find it in these examples because it appears
that people have "agreed". But answering technical disagreements is
what is needed to achieve consensus, sometimes even when the people
who stated the disagreements no longer wish to discuss them.
If you would like to advocate bitcoin development run counter to that,
you should provide a much stronger refutation of these engineering
norms.
[-- Attachment #2: Type: text/html, Size: 6743 bytes --]
next prev parent reply other threads:[~2021-10-11 19:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 12:24 Michael Folkson
2021-10-11 19:12 ` Jeremy [this message]
2021-10-11 19:53 ` ZmnSCPxj
2021-10-14 23:52 ` Anthony Towns
2021-10-15 0:43 ` micaroni
2021-10-16 11:02 ` Michael Folkson
2021-12-31 3:10 ` Keagan McClelland
2021-10-11 16:03 Prayank
2021-10-12 19:04 ` Jorge Timón
2022-01-01 15:45 vjudeu
2022-01-18 16:00 ` Billy Tetrud
2022-01-18 17:22 Prayank
2022-01-19 2:26 ` Billy Tetrud
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='CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com' \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@protonmail$(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