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 93F50982 for ; Mon, 10 Jul 2017 18:38:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BFDFE4 for ; Mon, 10 Jul 2017 18:38:10 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id 191so52202616vko.2 for ; Mon, 10 Jul 2017 11:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PfRWVaFBT9qggLzF98JANuY/nxoEgRMh7QZ84ayPYZE=; b=NmrJGGQX+fcB7Bwa5HEyTXDJTS8q9c+2JjxUudk2cxx3+7e4F1t4XvXpiqbtI0Sy8s FfegVbDzSYQvnTQVLgKjQ9HS9FoUtUAdZcXxmFRiBN4mMmHaO0Km94yvb6iDYazdbsIE DdYou/QHk1Un1u5wFx6DCnsrTYK3yoWmpZ6oIXy6k46pN6X0/MovTPKrTgsrITWqOsW2 NPvbB6bAvEF6gosLiZpJCk76vPHoxkC8tbubOZgAO8q7+sX6XETd3W9pIgu9Ycuf5ICH SrSVUEIEmtJ2m8W/WFC8evMCZEEXvYoPLo++o6I+3t4NLhTV0cO/86WlSM3SjMW1rlTh 8Z8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PfRWVaFBT9qggLzF98JANuY/nxoEgRMh7QZ84ayPYZE=; b=D5KOogMXigNpOQO3Co/QCJz3wkPpHWrB/1LkOV6nibsBAmKO0dDMhCMMLOIWvz/L/s yamHCEZGe4qNN3GPFmbe1H2hQsu5PQxVgarRbvXR7AXPOjLNlBJ6gscknLiX/r4Fl7HP KIv3kOpvaUuFcEUa11qNDSkzQwk8yNyOy3m5ViOOmEPW9eT2gNXhhUQkiTx4t0cLr2yw Jw6xM1NZsJv1XGlXS8iiVNafPwsj7KD0coQzq5mYo/Y8fzsNZDbFc3t7hEzOOZ0qdPCH 0kK0CY+mQzcEZXdfHz6sre1d/Jvs0UypTacsAPt1EJwEa1RAFoRX7/6C8Xj/ziK5YWXY a0ng== X-Gm-Message-State: AIVw1115E2FNfHGUd6lZxdrC8+n0elP2w50qcnpSCI2U1OBqhgrARWez O9TwAqCZYl5gKFZPpWS9qAbOhW3xqnVc X-Received: by 10.31.52.13 with SMTP id b13mr7801795vka.153.1499711889048; Mon, 10 Jul 2017 11:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.52.85 with HTTP; Mon, 10 Jul 2017 11:38:08 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Mon, 10 Jul 2017 20:38:08 +0200 Message-ID: To: Sergio Demian Lerner Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 11 Jul 2017 15:32:32 +0000 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] A Segwit2x BIP 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: Mon, 10 Jul 2017 18:38:10 -0000 On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev wrote: > Regarding the timeline, its certainly rather short, but also is the UASF BIP > 148 ultimatum. This is correct. If you are trying to imply that makes the short timeline here right, you are falling for a "tu quoque" fallacy. > More than 80% of the miners and many users are willing to go in the Segwit2x > direction. There's no logical reason I can think of (and I've heard many attempts at explaining it) for miners to consider segwit bad for Bitcoin but segwitx2 harmless. But I don't see 80% hashrate support for bip141, so your claim doesn't seem accurate for the segwit part, let alone the more controversial hardfork part. I read some people controlling mining pools that control 80% of the hashrate signed a paper saying they would "support segwit immediately". Either what I read wasn't true, or the signed paper is just a proof of the signing pool operators word being something we cannot trust. So where does this 80% figure come from? How can we trust the source? > I want a Bitcoin united. But maybe a split of Bitcoin, each side with its > own vision, is not so bad. It would be unfortunate to split the network into 2 coins only because of lack of patience for deploying non-urgent consensus changes like a size increase or disagreements about the right time schedule. I think anything less than 1 year after release of tested code by some implementation would be irresponsible for any hardfork, even a very simple one.