Date: Mon, 11 Oct 2021 19:53:39 +0000
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <uX7nCIoeTnpXkL-x8qJiSS1OYy-J-YhvTP7hdsljoUUDpa6c8pC34NapUWhCxYSYMY4ciwLzABVUVQwiihggvCqQhH5sfwImDIKzXl61M80=@protonmail.com>
In-Reply-To: <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com>
References: <LmX3Gnfkf1T0Eb_wUXxPe8c0Tf2DNipfIqufkRS6oOPhttr4iZIOWtjUL_7QkcWEHr8eFvehHooaM140ZBKLwi98F5NwyQKSyEhAPZDK1YQ=@protonmail.com>
 <CAD5xwhj3JCxH1=5Tj+hgiSxLWchLgT584X0YutKVeuibnpwmtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Precedence: list

Good morning Jeremy,

> This also has strong precedent in other important technical bodies, e.g. =
from=C2=A0https://datatracker.ietf.org/doc/html/rfc7282=C2=A0On Consensus a=
nd Humming in the IETF.
>
>   Even worse is the "horse-trading" sort of compromise: "I object to
> =C2=A0 =C2=A0your proposal for such-and-so reasons.=C2=A0 You object to m=
y proposal for
> =C2=A0 =C2=A0this-and-that reason.=C2=A0 Neither of us agree.=C2=A0 If yo=
u stop objecting to
> =C2=A0 =C2=A0my proposal, I'll stop objecting to your proposal and we'll =
put them
> =C2=A0 =C2=A0both in." =C2=A0That again results in an "agreement" of sort=
s, but instead
> =C2=A0 =C2=A0of just one outstanding unaddressed issue, this sort of comp=
romise
>   results in two, again ignoring them for the sake of expedience.
>
> =C2=A0 =C2=A0These sorts of "capitulation" or "horse-trading" compromises=
 have no
> =C2=A0 =C2=A0place in consensus decision making.=C2=A0 In each case, a ch=
air who looks
> =C2=A0 =C2=A0for "agreement" might find it in these examples because it a=
ppears
> =C2=A0 =C2=A0that people have "agreed".=C2=A0 But answering technical dis=
agreements is
> =C2=A0 =C2=A0what is needed to achieve consensus, sometimes even when the=
 people=C2=A0
>
>   who stated the disagreements no longer wish to discuss them.
>
> If you would like to advocate bitcoin development run counter to that, yo=
u 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 bro=
wsers).

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 applica=
tion to "lenient in what you accept" systems, may not apply quite as well t=
o "hell no I am not accepting that block" Bitcoin.

Bitcoin as well, as a resistance against state moneys, is inherently politi=
cal, and it possible that the only way out is through: we may need to resis=
t this horse-trading by other means than separating concerns, including pol=
itical will to reject capitulation despite bundling.

Regards,
ZmnSCPxj