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 6CD34481 for ; Sun, 26 Mar 2017 21:42:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA0B72A6 for ; Sun, 26 Mar 2017 21:42:49 +0000 (UTC) Received: by mail-yw0-f170.google.com with SMTP id d191so20119921ywe.2 for ; Sun, 26 Mar 2017 14:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thinlink-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=gmc6OxV/EflPHCxxtnj5pDWQ0fxGZkeERI4BQOq89To=; b=g48nbZwM/d4tLH4No8aZ8AHWZDXzFl/SzxeoJp2EofEGb4Nj30mtqTUL2d02tFud63 SlwB2thEc9bBomOIX8VecG+Bth7fntB5BmU+JBfVV/LKaOey9T7G+ZN1QTXMu95gVeZP AJv80Wnrkl7uJ/jSNuXLWf9HfeDqAAVxeL8s69KKRHRI0TCDAxRcpK9rx7VTD4FKROHb 2w+EgBRY/Sld4ZpV88rCXXtirPxM8YLfwMkqMHCwBhcxYQpA9/GOuVHyWrWxNJq/Wtse EUZtiYcTPzbEKcHUZoRmsCupmbv+bCK7aSmhhiMLE5yP2WGXza0AfMwLyCXT0s3CgO9k A8FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=gmc6OxV/EflPHCxxtnj5pDWQ0fxGZkeERI4BQOq89To=; b=qKBpTazpPzHcTz4laoe7iC/ag+xxTbgma8L2RLs/s5K7rI6QWmT1ZoOjQpInAZ8RdU OAEK+H6aPMbGsSCoxIgT4B03/dhRymGi1Vx1r+uWUlj8d+9uEj19KLnX3+qobnqTZG5K n/YsPSOK/hjZ9gxrfOgLARPwEGCI70PCqhTB/v0zGbHV91y3AeCKvQ5u6cQY5WU3BZkS GXML1L+ZtarTsYIoIshz2PSdsvexL1SKvtxP1w7EguS3aKp9IxqSptORHzGjKxJal5v5 qadVM+n3EtuMv+GaBVk7g7IODPKah4vAljs2uEbHUDQjGfYjbZX2TvuWpMGrXbVQXiZ+ uD1Q== X-Gm-Message-State: AFeK/H3RC1vPJcuUj6jAUrcCI1oNY+yt3GPfttCHrbIE0hujwepWejWeJO+uRcL/8cJzORj0 X-Received: by 10.129.155.210 with SMTP id s201mr14606388ywg.321.1490564568755; Sun, 26 Mar 2017 14:42:48 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id p1sm3574986ywh.77.2017.03.26.14.42.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 14:42:47 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org 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: Tom Harding Message-ID: Date: Sun, 26 Mar 2017 14:42:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BF56F33F4CF6D1E14E7267E" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 21:49:48 +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 21:42:50 -0000 This is a multi-part message in MIME format. --------------5BF56F33F4CF6D1E14E7267E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev > > 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. > A reasonable miner automatically checks every transaction seen, to see if it might be valid with his own outputs substituted. --------------5BF56F33F4CF6D1E14E7267E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev 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.


A reasonable miner automatically checks every transaction seen, to see if it might be valid with his own outputs substituted.

--------------5BF56F33F4CF6D1E14E7267E--