From: Gregory Maxwell <gmaxwell@gmail•com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate
Date: Mon, 5 Oct 2015 18:35:13 +0000 [thread overview]
Message-ID: <CAAS2fgQ3Qs=s7qwhxjwJa9cLJLMJg+LXjPQDCGUDMEjyrHqO_A@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 1) ignores him, which is against the established criteria that all technical
> objections coming from anyone must be addressed until that person agrees, so
> that a change can be uncontroversial. If the group moves forward with the
> change, then the "uncontroversial" criteria is violated and then credibility
> is lost. So a new governance model would be required for which the change is
> within the established rules.
>
> 2) respond to his technical objections one after the other, on never ending
> threads, bringing the project to a standstill.
I don't agree-- I think you've made the mistake of just accepting the
particular framing that Mike has provide; one that (no shock) only
supports his conclusions.
I am aware of no instance where an active contributor to core has made
the claim that no change to consensus can happen without 100% support
(and doubly so, 100% including people who are expressly trying to
disrupt the project by posing opposition which, as you note, is
largely unrelated to the merits of the proposals). Mike has lead you
to believe people have claimed this, but no one has-- it's a view
which is simple, clear, and completely not reflecting reality. Don't
fall for strawman arguments.
In this situation it is also a particularly strong apples/oranges comparison:
Soft forks can happen at any time at the whim of miners-- no
technology which we are aware of (beyond the technology of
centralization) is able to prevent them-- they are not necessarily
even detectable; on this basis they are categorically different than
hard forks.
Moreover, the space of soft-forks the contributors to Bitcoin Core
would ever consider is a tiny space of all possible soft-forks, and
are ones which cannot be rationally understood to meaningfully
undermine the properties provided by the rules enforced within the
software; again making them different from some other proposals and of
a lesser concern.
Finally, the behavior of the technology arising from the inherent
compatibility, radically lowers (in most of our experience and
opinion) the cost of deployment; again-- making them different. They
prevent a industry wide flag day, and tight release synchronization
which is harmful to decentralization promoting software diversity.
As I think I commented in one of my messages-- I respond to the
technical arguments not because I believe they are earnestly
motivated, but because they provide an avenue for learning for myself
and others. Even someone trying to disrupt the process and nothing
else can help us learn by acting as an adversary that causes us to
extend our minds and understanding. The process for CLTV has been
ongoing for something like a year and a half and has little risk of
being substantially disrupted at this point.
next prev parent reply other threads:[~2015-10-05 18:35 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 15:56 Sergio Demian Lerner
2015-10-05 16:39 ` NxtChg
2015-10-05 16:51 ` Luke Dashjr
2015-10-05 16:56 ` Mike Hearn
2015-10-05 17:01 ` Paul Sztorc
2015-10-05 17:33 ` Peter R
2015-10-05 17:56 ` NxtChg
2015-10-05 22:56 ` Btc Drak
2015-10-05 23:05 ` Milly Bitcoin
2015-10-05 17:35 ` Btc Drak
2015-10-06 18:23 ` Venzen Khaosan
2015-10-06 18:28 ` Venzen Khaosan
2015-10-06 19:34 ` naama.kates
2015-10-05 17:03 ` Btc Drak
2015-10-05 17:26 ` Tom Zander
2015-10-05 17:52 ` Btc Drak
2015-10-05 18:04 ` Gregory Maxwell
2015-10-05 18:33 ` Tom Zander
2015-10-05 18:50 ` NotMike Hearn
2015-10-05 17:33 ` s7r
2015-10-05 18:51 ` Tom Zander
2015-10-05 18:35 ` Gregory Maxwell [this message]
2015-10-05 19:13 ` Tom Zander
2015-10-05 19:41 ` Gregory Maxwell
2015-10-05 20:05 ` Steven Pine
2015-10-05 20:21 ` Milly Bitcoin
2015-10-06 7:17 ` cipher anthem
2015-10-06 7:20 ` Eric Lombrozo
2015-10-06 7:29 ` Marcel Jamin
2015-10-06 8:34 ` NotMike Hearn
2015-10-06 19:40 ` naama.kates
2015-10-05 20:28 ` Santino Napolitano
2015-10-05 20:35 ` Tom Zander
2015-10-05 20:54 ` Dave Scotese
2015-10-05 20:56 ` Gregory Maxwell
2015-10-05 21:08 ` Tom Zander
2015-10-05 21:16 ` Milly Bitcoin
2015-10-05 21:26 ` Gregory Maxwell
2015-10-06 7:14 ` Tom Zander
2015-10-05 21:27 ` Peter R
2015-10-05 21:30 ` Gregory Maxwell
2015-10-05 21:36 ` Milly Bitcoin
2015-10-05 21:37 ` Peter R
2015-10-06 1:37 ` Tom Harding
2015-10-06 3:20 ` Peter R
2015-10-06 3:39 ` Milly Bitcoin
2015-10-06 4:54 ` Luke Dashjr
2015-10-06 5:08 ` Milly Bitcoin
2015-10-06 5:49 ` Milly Bitcoin
2015-10-06 5:53 ` Luke Dashjr
2015-10-06 6:03 ` Milly Bitcoin
2015-10-06 22:14 ` phm
2015-10-06 5:07 ` NotMike Hearn
2015-10-06 5:33 ` Peter R
2015-10-05 19:36 ` Milly Bitcoin
2015-10-05 23:18 ` Eric Lombrozo
2015-10-06 17:28 ` Venzen Khaosan
2015-10-07 0:04 ` Sergio Demian Lerner
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='CAAS2fgQ3Qs=s7qwhxjwJa9cLJLMJg+LXjPQDCGUDMEjyrHqO_A@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sergio.d.lerner@gmail$(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