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 6A603125B for ; Sat, 29 Aug 2015 20:59:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8ABED106 for ; Sat, 29 Aug 2015 20:59:29 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so45184141lbb.1 for ; Sat, 29 Aug 2015 13:59:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kz2nzwBcRJM//EIgdMrAMEGAn52wirVFPmCqOrPMu3c=; b=Q6Q0vdJksTqsqiOOBxkk6Sc96ZluWrLHVzX1r/FO7mJglsBimwe1646SArEIWT1MWO 2aaBMrkziAeA6r2Qe137AiL86/wLOcaX6Y3uwEDRhUFbHxgwotYE7IwJAGOYB87gD0j3 ctjJXYJJ25t19XnjA8oAZ/3WiuGJJpZZBa00rzauDRLvCSqske3ZE5T9LUpFZIUmkIzI +SvTJIlfoy8jgOP0L3cq7fMSjCUd90KN04axMmyhWbs5i50/ByKngCcJg3L9kBeXl9KQ wvf8U8mJI9Y5jKVM1so8sxiAM4Ttk+vOTMVy5joPagISLxB7Ndsehsdx1/rTaT8eLdMq y2/A== X-Gm-Message-State: ALoCoQkfM/ZwvLl4GNM9eq8SvNqWhmZLsTRzNDmQmWq4+s+Wf+xon7uAlXdgCj5Yyko+Jmewjs7B MIME-Version: 1.0 X-Received: by 10.152.21.196 with SMTP id x4mr7091713lae.117.1440881967908; Sat, 29 Aug 2015 13:59:27 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Sat, 29 Aug 2015 13:59:27 -0700 (PDT) In-Reply-To: References: <55E145EF.3060801@gmail.com> Date: Sat, 29 Aug 2015 22:59:27 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Jameson Lopp Content-Type: text/plain; charset=UTF-8 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 Subject: Re: [bitcoin-dev] Variable Block Size Proposal 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: Sat, 29 Aug 2015 20:59:30 -0000 On Sat, Aug 29, 2015 at 4:22 PM, Jameson Lopp via bitcoin-dev wrote: > I don't think you'll find much support for introducing a mandatory minimum > block size. It's quite wasteful to "pad" blocks with transactions that the > miner is just sending back to themself. If you want to solve the block > propagation issue, I'd recommend instead working on O(1) block propagation. O(1) propagation can never be achieved without a centralized topology. No matter how efficient of an IBLT (or similar) we implement, O(1) can only be achieved for transmitting a block between 2 nodes. The propagation time of a block across the whole network (or even to the miner's sub-network) will always depend on the concrete network topology. That's not to say that transmitting a block between to peers in constant time wouldn't greatly help with mining centralization concerns related the maximum block size, but I'm concerned about this incorrect "O(1) block propagation" meme keeps spreading. Even with ansibles [1] and safe zk-SNARKS [2] for constant time block validation (somehow removing the trusted setup), both of which are science fiction right now you need to verify the snark proof for every node receiving and relaying the block. At that point block propagation would be meaningless as a miner-centralization concern for not raising the maximum block size though: the minimum CPU costs for being able to mine profitably would be the next concern or "bottleneck". I completely agree with the minimum block size being inappropriate though. I don't even believe that the stated goals of the size minimum can be accomplished with it. [1] https://en.wikipedia.org/wiki/Ansible [2] https://eprint.iacr.org/2013/879.pdf