public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [bitcoin-dev] On the regularity of soft forks 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.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=michaelfolkson@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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