From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DCD58A80 for ; Tue, 20 Jun 2017 21:49:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5FF2AE5 for ; Tue, 20 Jun 2017 21:49:51 +0000 (UTC) Received: by mail-ua0-f170.google.com with SMTP id z22so285448uah.1 for ; Tue, 20 Jun 2017 14:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=T3UdLPzY7EzHLYG+3a6zB2Jx+IiY9wy2m6C4scld5Ok=; b=iyOWn86XkIvGRj6IaQ8rjYmpAiRgBrSMDytF6GSm2gM+rixJO2Ex5hY4nP2y3kZqEx +AlO6JEN2GJvd2DVEw2hW5cfRxEaJ76d7AvXQoVcrC5kS1z1zBffRFkWmUpyHjqd7maF mRr0dvSyvuMxnSl4Aozo3QpBz4I5M7Qc7cVC0xnEWY1s0CbQgBEzJZymUtQNAeIIfPs7 aiGXDMBFrvzVPW9kbrJNOU8J6DQ0Dn42zcMlN9QpGLo8gPAr5N80V7sBeCu+DrM6/gtH EU/ObtYzzybPXxrCzp/yABT4fdQVo4ucTo3sIoGZhjEhXIVhIcgo3a0sVkozxBgsXPGK tR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=T3UdLPzY7EzHLYG+3a6zB2Jx+IiY9wy2m6C4scld5Ok=; b=Cg0/4AHNW2PCh97b5HVRXkCHRsya6sDS9fgq0kiq4kSvHjD4wFEsFKs9Vgqz+WodUu muSWklYkCQ7gJs9BFnijv0C3b8lVOQtNAgKHZs3HwT7lA+euatg9ky087+06OoXOw7Eo ZTGkDQBrBTi6nMipuHHNYbwKM5LffhHScopCTJxLIi0mBTXUj+1vCwVTDe2c83rAj1qM 4yST8a/BIvTrezKPlaZ4pF4zo0akz2BN1HPET7geHpIsGBfOWKYVKPjzqPDIfgT23zMX 8yKmb5bToRVgYUnxnDppWlje2fNTJbQZ9bw/SB1az/ZwZopSJNR9hi6Y5bWj4Ba6wHPJ XqIw== X-Gm-Message-State: AKS2vOxyLVKNKOGb1M1EqtSrG4a8kFpXi99ML5cJq58gftBfd+wfKx9z jIFfmrLQ4flZRe7OPNogTJgw528yZQ== X-Received: by 10.176.17.26 with SMTP id e26mr7069551uab.94.1497995390410; Tue, 20 Jun 2017 14:49:50 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.13.7 with HTTP; Tue, 20 Jun 2017 14:49:50 -0700 (PDT) In-Reply-To: References: From: Gregory Maxwell Date: Tue, 20 Jun 2017 21:49:50 +0000 X-Google-Sender-Auth: HVUg-3-jQav4yEhseGkCovqlFZ4 Message-ID: To: Erik Aronesty Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:49:52 -0000 On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev wrote: > Because a large percentage of miners are indifferent, right now miners ha= ve > 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 wrote: > I think it is very na=C3=AFve 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.