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 218AC481 for ; Sun, 26 Mar 2017 20:44:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A3CFB136 for ; Sun, 26 Mar 2017 20:44:14 +0000 (UTC) Received: by mail-ot0-f171.google.com with SMTP id t8so14855634otf.3 for ; Sun, 26 Mar 2017 13:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GyLKpg0aM+mOXhT9tFGEiolrtjI9ZZyaJ4cud3tkOSw=; b=VqQUKFHVHTkGqFi1C7CbdhKAoMcZ28lmHl+GoXD9rEn3kFKa7XcdKyDlLsn5udHtrb xoA1bTxlnBe5Z2unSR8TNL/ijd7nBmUtyW0iya38dbzYCqhUiN3kzITwcvemSVTss2oJ spbOqqIv6XN4itPH+OWPohJwOo+AKzSDXTKoDFYQ9qcD0EsJbnpsIMSumJ3wASPGPu6q Np2wMmLRO9TiYhumhBcQtAsu1MKer8iGlN+r9vLAM9p1VCjWyIbkmO62x6vb91xzIEe5 9aZFGHbjFdFPps4cxaRep1gAA0BFDSS7eVf07JGf3UvZ57QZA+OtWZi9aLlZyuESO/Tu +zqQ== 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=GyLKpg0aM+mOXhT9tFGEiolrtjI9ZZyaJ4cud3tkOSw=; b=Qv0n4imiTwzpwKpdV1R/oOOhNcxzU7n8RuSDk9MsQkFkIpfB+r4WEgknr5SkpINGqU tMEAsrFDWNcfmfXMT8ewBS0J7RbcFYbDAtRbwoMTe95Y7NQ825bW5rqsowrrK+eUCtOz HODZdxoF7MOoeK0Vq/fgoqJ4CuTgofnHJ3NbtWsNZsFDtxTYcUbDRh9Q92rp8wejrn/a 1khWpu75oo0xJ/jF2FYO1cBKIaD+ewBk+vZRvRi4r97eNVriLBrn3RIlGwQYJBMVLcj7 DDifQubjiR5z8yYB/gY9iZzYDPL538/zVtXqDOn9tJUJS930ueUE0Dg40Bbeo61i6f7S m8MA== X-Gm-Message-State: AFeK/H1GSefwgFNEC68rvQyK9xEWicyN08/dtX4XXJcD6YrRYPBeaK3sDmIhroyExvk04iPw4V4KQldaJ1sesQ== X-Received: by 10.157.45.163 with SMTP id g32mr10671656otb.274.1490561054010; Sun, 26 Mar 2017 13:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.36.111 with HTTP; Sun, 26 Mar 2017 13:44:12 -0700 (PDT) In-Reply-To: References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info> <35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com> <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com> <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com> From: Bryan Bishop Date: Sun, 26 Mar 2017 15:44:12 -0500 Message-ID: To: Trevin Hofmann , Bryan Bishop Content-Type: multipart/alternative; boundary=94eb2c04fb4a23f58f054ba84a95 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? 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: Sun, 26 Mar 2017 20:44:15 -0000 --94eb2c04fb4a23f58f054ba84a95 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann wrote: > He stated that "any invalid blocks they produce" will be orphaned. This is > not false. If non-upgraded miners do not produce blocks that are invalid > per the new rules, their blocks will not be orphaned. This is consistent > with Peter's comment. It's the other part of the statement- the "wakeup call to upgrade" from producing invalid blocks? They aren't producing invalid blocks. Additionally, if they want to be even more sure about this, they can run the so-called "border nodes". No wakeup calls needed.... the point of a soft-fork is to reduce incompatibility. - Bryan http://heybryan.org/ 1 512 203 0507 --94eb2c04fb4a23f58f054ba84a95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 26, 2017 at 3:37 PM, Trevin Hofmann <trevinhofmann@gmail.c= om> wrote:
He stated that &= quot;any invalid blocks they produce" will be orphaned. This is not fa= lse. If non-upgraded miners do not produce blocks that are invalid per the = new rules, their blocks will not be orphaned. This is consistent with Peter= 's comment.

It's the other part of the statem= ent- the "wakeup call to upgrade" from producing invalid blocks? = They aren't producing invalid blocks. Additionally, if they want to be = even more sure about this, they can run the so-called "border nodes&qu= ot;. No wakeup calls needed.... the point of a soft-fork is to reduce incom= patibility.

- Bryan
http://heybryan.org/
1 512 203 0507
--94eb2c04fb4a23f58f054ba84a95--