public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate
Date: Mon, 5 Oct 2015 16:51:57 +0000	[thread overview]
Message-ID: <201510051651.58728.luke@dashjr.org> (raw)
In-Reply-To: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>

On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev 
wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
> 
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
> 
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
> 
> 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.
> 
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.

This discussion is *necessarily* about soft/hard fork technicalities, as 
there is no governance in Bitcoin beyond the *nature* of the consensus 
protocol. The "established criteria" you mention is merely the nature of 
hardforks. It is completely inapplicable and has never been the necessary 
case for softforks, which can be enforced by merely a miner majority.

Luke


  parent reply	other threads:[~2015-10-05 16:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 15:56 [bitcoin-dev] This thread is not about the soft/hard fork technical debate Sergio Demian Lerner
2015-10-05 16:39 ` NxtChg
2015-10-05 16:51 ` Luke Dashjr [this message]
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
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=201510051651.58728.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=sergio.d.lerner@gmail.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