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 3847BB7B for ; Mon, 27 Mar 2017 20:01:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com [74.125.83.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C78EA1E6 for ; Mon, 27 Mar 2017 20:01:20 +0000 (UTC) Received: by mail-pg0-f52.google.com with SMTP id g2so49783997pge.3 for ; Mon, 27 Mar 2017 13:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=YKI/8nKg0k99IFdmVGpELAvPnaRJLF4LMUdoW8paJkk=; b=l+UYRtg+YV+syV9/zSFSJ0Ku4vYP33+cEUmXazneZEfW0AsfSDOvAWRo5zkfyuODac c6GvBe180NdN1xriRgicwmL/QXlGtHZFNYMMn7t4f2509L9T2A959YGHZ9uDBAr3O7xS KveqTU6Jof1hQiiX23Whs2fSIZLMJhiBRdrFR2HNsM3hOAK5gBKdIMXVOCgSbMx5zFOy FlT9EcsDAO6I4pgNdXIENoWfqcWIInME3WU/GvaH2EvEsSeudmj6pyL6B6hD+Bpgpw5H cfyQX07HuWLqsAdMlR+8wi9Yl0LucDaxWoyjkxDPTppgoHKJsLXyGeuHKF1AsNrnuLMf aIpA== 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:content-transfer-encoding; bh=YKI/8nKg0k99IFdmVGpELAvPnaRJLF4LMUdoW8paJkk=; b=uQXgV6WAbuInaassPIF0+X2+SbjQyAKeCnttjLaQLw1bsCW3wrFz2cUx9A0q7sHWCz aqF2N3GiOGW9n3ZRucAeCCQp5CuU0q/oNeDwb1KZ6FYxKv+waj0WrIX5LUaf2ij+uydq KA4h/WFe6/JFFUcf0BF3kNIRuJxMKDnXFu5z71UjueXxGMR756ro59+i6ZX/liUqERof UMI/NvUGw4fJh3Q8pP+jMPDGCDlasz+bs/I4o16ALZecZELU+jh/YwIJfEkFOPm2QQJl AA98iEknw5RGSEPAlcWqouU+kYjClro216LvWBtActySlyYpLMCVY2ek2QD9YFOzRfQz VdiA== X-Gm-Message-State: AFeK/H2RRXscP16EFhX1OprewpfOXNxrm/Jt3J1jZboIteAzmmz7XHbDp8a2BNsECDVHeQ== X-Received: by 10.99.109.67 with SMTP id i64mr20641677pgc.56.1490644880295; Mon, 27 Mar 2017 13:01:20 -0700 (PDT) Received: from ?IPv6:2601:600:9000:d69e:8c11:8163:4024:ef42? ([2601:600:9000:d69e:8c11:8163:4024:ef42]) by smtp.gmail.com with ESMTPSA id g5sm2822468pfe.12.2017.03.27.13.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 13:01:19 -0700 (PDT) To: Tom Zander , Bitcoin Protocol Discussion , Btc Ideas References: <7350662.8AQMRkRU5C@cherry> From: Eric Voskuil X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 27 Mar 2017 13:01:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <7350662.8AQMRkRU5C@cherry> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 X-Mailman-Approved-At: Mon, 27 Mar 2017 20:03:18 +0000 Subject: Re: [bitcoin-dev] Encouraging good miners 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: Mon, 27 Mar 2017 20:01:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote: > For some time now the relation between block size and propagation > speed has been decoupled. Using xthin/compact blocks miners only > send a tiny version of a block which then causes the receiving node > to re-create it using the memory pool. Immediately getting double > benefits by including pre-verified transactions from the memory > pool you avoid the old problem of having to validate them again > when a block was mined. > > As such there is no downside to a miner creating a bigger block, as > long as all the transactions they include are actually in the > mempool. All transactions being publicly available is not something that can be assumed. With no opportunity cost for a miner to generate withheld transactions, a larger miner still maintains the economic advantage of latency as a function of block size. Fast relay works to reduce latency in relation to the opportunity cost created by the space constraint. IOW, the more fees a miner must give up to mine withheld transactions, the greater the economic disadvantage of doing so. So there is a "downside" (i.e. centralization pressure) up to the point where the advantage gained from withholding transactions turns negative. The rational competing miner must presume that a block is valid upon confirming the announcement's PoW. He then has the choice of mining on top of the (partially-visible) block, or ignoring it until it can be fully populated. The former *eliminates fee opportunity*, since the next block must remain free of all public fee-generating transactions until all of the preceding block's transactions are visible. The latter increases orphaning probability, since it implies mining on the weak chain, which *increases total reward loss*. One can conclude that no matter how much space is created, it will always be filled by a rational miner, as a competitive necessity, given the centralizing effect of latency. Making blocks big enough to include low cost transactions nullifies the benefits of fast relay techniques based on your above assumption, since a rational miner will simply substitute withheld transactions. e -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJY2W+bAAoJEDzYwH8LXOFOzkwH+wUulsdvUcfEHMspolfDjTD+ f4egP1FDoOFgXzaGJ+Bq1AjWP+CDYup9msYhp1NTk6xRnG4uGvaEA3DFYGbAzLut INtkpCi38O1QGtDJaxmkJHXLoWJPS6VudcDEoam4W6qSKgHFB+ZRnIN4T7jnGMLI rp/cGdom9wE/pcq/fvF/fonGfVWf/YP2YjBzJzaJy+zOYPTH2rNcnYBCHFPs4/KX 9Gu7tDw9WNxM5idnd0TiidublQhYui6xo7ZbZpmXQePcHQoQO5XqaO6yWwiWRWaU mqXhalASOtP6xnPzj6FfAHYS7qA7JCaDfwT8UIzt9xv9XsPrhQ/r6Sfgfhvbm2k= =b9sf -----END PGP SIGNATURE-----