Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3847BB7B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 27 Mar 2017 20:01:20 +0000 (UTC)
Received: by mail-pg0-f52.google.com with SMTP id g2so49783997pge.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Btc Ideas <btcideas@protonmail.com>
References: <uQBxE-Qbd-osime4uulMZZHdF_D7usA2EKsPjkTyXCHM0OakN2Wdoeriyrc73yWp5c5ULQNkIsRXAM64cCom7ecPvdwmatOyc9Kh1sTDpl4=@protonmail.com>
	<7350662.8AQMRkRU5C@cherry>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <b99eda2f-b638-e188-e678-f93bba147404@voskuil.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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-----