public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <greg@xiph.org>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
Date: Tue, 20 Jun 2017 21:49:50 +0000	[thread overview]
Message-ID: <CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>

On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Because a large percentage of miners are indifferent, right now miners have
> to choose between BIP148 and Segwit2x if they want to activate Segwit.

Miners can simply continuing signaling segwit, which will leave them
at least soft-fork compatible with BIP148 and BIP91 (and god knows
what "segwit2x" is since they keep changing the actual definition and
do not have a specification; but last I saw the near-term behavior the
same as BIP91 but with a radically reduced activation window, so the
story would be the same there in the near term).

Ironically, it looks like most of the segwit2x signaling miners are
faking it (because they're not signaling segwit which it requires).
It'll be unfortunate if some aren't faking it and start orphaning
their own blocks because they are failing to signal segwit.

I don't think the rejection of segwit2x from Bitcoin's developers
could be any more resolute than what we've already seen:
https://en.bitcoin.it/wiki/Segwit_support

On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think it is very naïve to assume that any shift would be temporary.
> We have a hard enough time getting miners to proactively upgrade to
> recent versions of the reference bitcoin daemon. If miners interpret
> the situation as being forced to run non-reference software in order
> to prevent a chain split because a lack of support from Bitcoin Core,
> that could be a one-way street.

I think this is somewhat naive and sounds a lot like the repeat of the
previously debunked "XT" and "Classic" hysteria.

There is a reason that segwit2x is pretty much unanimously rejected by
the technical community.  And just like with XT/Classic/Unlimited
you'll continue to see a strong correlation with people who are
unwilling and unable to keep updating the software at an acceptable
level of quality-- esp. because the very founding on their fork is
predicated on discarding those properties.

If miners want to go off and create an altcoin-- welp, thats something
they can always do,  and nothing about that will force anyone to go
along with it.

As far as prevent a chain split goes, all those things
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
don't think that holds.


  parent reply	other threads:[~2017-06-20 21:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-20 15:44 [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated Erik Aronesty
2017-06-20 16:49 ` Hampus Sjöberg
2017-06-20 17:22   ` Mark Friedenbach
2017-06-20 21:49 ` Gregory Maxwell [this message]
2017-06-20 22:15   ` Hampus Sjöberg
2017-06-20 22:29     ` Jacob Eliosoff
2017-06-20 22:48       ` Mark Friedenbach
2017-06-20 22:57         ` Jacob Eliosoff
2017-06-20 23:01           ` Jacob Eliosoff
2017-06-21  1:36           ` Erik Aronesty
2017-06-21  2:11             ` Mark Friedenbach
2017-06-21  4:05               ` Jacob Eliosoff
2017-06-27 15:42                 ` Sergio Demian Lerner
2017-06-27 16:31                   ` Jorge Timón
2017-06-27 19:26                     ` Erik Aronesty
2017-06-20 22:34     ` Gregory Maxwell
2017-06-20 22:53       ` Hampus Sjöberg
2017-06-20 19:49 Ryan J Martin

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=CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com \
    --to=greg@xiph.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.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