From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Date: Mon, 11 Oct 2021 19:53:39 +0000 [thread overview]
Message-ID: <uX7nCIoeTnpXkL-x8qJiSS1OYy-J-YhvTP7hdsljoUUDpa6c8pC34NapUWhCxYSYMY4ciwLzABVUVQwiihggvCqQhH5sfwImDIKzXl61M80=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com>
Good morning Jeremy,
> 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.
The Internet has the maxim "be strict in what you provide, lenient in what you accept", which allows for slight incompatibilities between software to generally be papered over (xref the mountains of Javascript code that shim in various new ECMAScript features fairly reliably in a wide variety of browsers).
Bitcoin, as a consensus system, requires being paranoiacally strict on what transactions and blocks you accept.
Thus, the general engineering norm of separating concerns, of great application to "lenient in what you accept" systems, may not apply quite as well to "hell no I am not accepting that block" Bitcoin.
Bitcoin as well, as a resistance against state moneys, is inherently political, and it possible that the only way out is through: we may need to resist this horse-trading by other means than separating concerns, including political will to reject capitulation despite bundling.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-10-11 19:53 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
2021-10-11 19:53 ` ZmnSCPxj [this message]
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='uX7nCIoeTnpXkL-x8qJiSS1OYy-J-YhvTP7hdsljoUUDpa6c8pC34NapUWhCxYSYMY4ciwLzABVUVQwiihggvCqQhH5sfwImDIKzXl61M80=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/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