Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A7EAF9C for ; Fri, 21 Aug 2015 16:52:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53820AB for ; Fri, 21 Aug 2015 16:52:46 +0000 (UTC) Received: by pawq9 with SMTP id q9so56327188paw.3 for ; Fri, 21 Aug 2015 09:52:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=R/Gm46cZhiyRWuNSiJOGPghxcz5zvvHIfrreiN2LjZc=; b=dN3/uTml6rlKEIpfyFdWbDhI+r+vAKFIG5UmFjF0PpHK9MjJiZ9+VSGIsdWUL0Q26p Gnh0gGjqkVDn1qtzus+23zK9uayUX8oy6Lc46fQlZ8tAbMiShWHuq7UsLzXe5m7Iu96K 2Ibj4DUVfwDEvwg38//8reoDxIF/w4s7AvPGbMSGv7Li3E/3v1xdtrljW6Dh7L7hwmO2 37S34jT5PjCS+00bfyG4wSky2DZoeRjdlM54z68EBcGyo+t0E26enZtTNevjp1CdJpaT ausf7JchFaHyJHj99ofNzfIA2STIoaW8drV76rlj6xdDExyPBdA4kjo4tHbAUjK8CgSn JfaA== X-Gm-Message-State: ALoCoQlACc0OGg3iaDEna4+VSnWIbjjl7kCnTgLNMKpJHPR2OEVLTIfQEn3nQGUZO5F36hz8S11R X-Received: by 10.68.117.142 with SMTP id ke14mr19149245pbb.93.1440175965849; Fri, 21 Aug 2015 09:52:45 -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 ew13sm8428299pac.25.2015.08.21.09.52.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2015 09:52:44 -0700 (PDT) To: Peter Todd References: <55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> <20150821003751.GA19230@muck> From: Tom Harding X-Enigmail-Draft-Status: N1110 Message-ID: <55D7575B.6030505@thinlink.com> Date: Fri, 21 Aug 2015 09:52:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150821003751.GA19230@muck> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 16:52:46 -0000 On 8/20/2015 5:37 PM, Peter Todd wrote: > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: >> I found that small miners were not at all disadvantaged by large blocks. >> > > You used 20% as the size of the large miner, with all the small miners > having good connectivity with each other. > > That is *not* the scenario we're worried about. The math behind the > issue is that the a miner needs to get their blocks to at least 33% of > hashing power, but more than that is unnecessary and only helps their > competition; you simulated 20%, which is under that threshold. Equally, > why are you assuming the small miner group is well connected to each > other? > > You probably didn't get any replies because your experiment is obviously > wrong and misguided, and we're all busy. > I gave the small miners collectively the same hashrate as the large miners in the original test. I made them well-connected because everyone was well-connected intra-partition in the original test. I just varied one thing: the size of the miners. This is a principle of experiment design, in science. Next you'll probably claim that second-order and cross-term effects dominate. Maybe you can find the time to prove it.