Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-11 📝 Original message:*> ... in this post I will ...
📅 Original date posted:2021-10-11
📝 Original message:*> ... 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211011/7c82c14f/attachment-0001.html>;
📝 Original message:*> ... 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211011/7c82c14f/attachment-0001.html>;