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 8D84840C for ; Sun, 26 Mar 2017 20:37:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D83625D for ; Sun, 26 Mar 2017 20:37:29 +0000 (UTC) Received: by mail-pg0-f50.google.com with SMTP id 21so19940199pgg.1 for ; Sun, 26 Mar 2017 13:37:29 -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; bh=u5HpRVQ1EOqvu/y8pM4YMRp54Jpn9u9kJImueHRUSqY=; b=Olkhx0hEpxHilr3eQCfq5diDFRtzvaWm7tfKPH28vx5Dxpvkecfh+cLnPSUjlL6UnO /zhr3mDAAZbw5hRsdMBYgSkF+nU2vkaIg3Ho4awpGsAnUKtC2Qw9Ew5hIwzN1rGnutLt FnFEkJIXN3xQyOBWBzoIJNo0ba9GtHFzV3X7yL5GeTlEwRy0y6RbLEJMPOhCovH77iVX jpNTdM1TbamQos0GA+RdG0JU5muxpOBPEQJai5vHYAxFWK97RzMUVO2XpQIBpQmZjySa Qu4zLvhgbA3ljgBOaws33ZqYf3QpRn9rdUOMf22iXC7mhzUjTkr5KYExDwohWr+lKoay 22Mg== 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; bh=u5HpRVQ1EOqvu/y8pM4YMRp54Jpn9u9kJImueHRUSqY=; b=NYe7ymbyQW+yB6pJ7UgvOYNrcpuhQtPK0bTMdsYBGpmkpQhlhl8PjV/EwGcQgEMHWP HhPuG7s4hsGyVy0Ke5+MGgf+7dSQ7V9mB+baEuzJj1G6bRqiABxY4j/86pTkCusqbUX7 GmuYTV6A4Jnsiy92c/w4QgqLNpEAHshEdyY9RhynX6a8sT9awQOz2LKk2IsSXriEv0f0 KONM660kkA2AMBCEZM8M5XGSMIiaoC0TArOMzX4JKNOxA7TqAhrcvCsnJqOzfG+uJ9qK Z7tt5SwlSjzOoEn8P4yJ33BOHmPMc8Cb/aG4TJyu33P/XN4EXcT7Hl9UgFi5aLERJtrf iH7g== X-Gm-Message-State: AFeK/H11L4zQQ444pAdKtCM9aFqSy7RMHX/3Mln3Dp9ZhwuHyJAybjcsNp/X+47PmaI8zjrMll2rDbfWz/+jVQ== X-Received: by 10.84.225.146 with SMTP id u18mr340113plj.86.1490560648649; Sun, 26 Mar 2017 13:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.143 with HTTP; Sun, 26 Mar 2017 13:37:28 -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: Trevin Hofmann Date: Sun, 26 Mar 2017 15:37:28 -0500 Message-ID: To: Bryan Bishop , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=f403045ec540faa0ad054ba8315a X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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 X-Mailman-Approved-At: Sun, 26 Mar 2017 20:48:21 +0000 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:37:29 -0000 --f403045ec540faa0ad054ba8315a Content-Type: text/plain; charset=UTF-8 >> With a tightening of the rule set, a hash power minority that has not upgraded will not produce a minority branch; instead they will simply have any invalid blocks they produce orphaned, serving as a wake-up call t>o upgrade. > False. With bip9-based soft-fork-based activation of segwit, miner blocks will not be orphaned unless they are intentionally segwit-invalid (which they currently are not). If you have told miners otherwise, let me know. 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. -Trevin On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> With a tightening of the rule set, a hash power minority that has not >> upgraded will not produce a minority branch; instead they will simply have >> any invalid blocks they produce orphaned, serving as a wake-up call to >> upgrade. >> > > False. With bip9-based soft-fork-based activation of segwit, miner blocks > will not be orphaned unless they are intentionally segwit-invalid (which > they currently are not). If you have told miners otherwise, let me know. > > - Bryan > http://heybryan.org/ > 1 512 203 0507 <(512)%20203-0507> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045ec540faa0ad054ba8315a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-size:12.8px">>> With a tightening of the rule set,= a hash power minority that has not upgraded will not produce a minority br= anch; instead they will simply have any invalid blocks they produce orphane= d, serving as a wake-up call t>o upgrade.

> False. With bip9-based soft-fo= rk-based activation of segwit, miner blocks will not be orphaned unless the= y are intentionally segwit-invalid (which they currently are not). If you h= ave told miners otherwise, let me know.

He stated that "any inv= alid 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, t= heir blocks will not be orphaned. This is consistent with Peter's comme= nt.

-Trevin

On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:
On Sun, Mar 26, 2017 at = 2:05 PM, Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
With a tightening of= the rule set, a hash power minority that has not upgraded will not produce= a minority branch; instead they will simply have any invalid blocks they p= roduce orphaned, serving as a wake-up call to upgrade.

False. With bip9-based soft-fork= -based activation of segwit, miner blocks will not be orphaned unless they = are intentionally segwit-invalid (which they currently are not). If you hav= e told miners otherwise, let me know.

- Bryan
http://heyb= ryan.org/
1 512 203 0507

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--f403045ec540faa0ad054ba8315a--