public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Tom Zander <tomz@freedommail.ch>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Btc Ideas <btcideas@protonmail.com>
Subject: Re: [bitcoin-dev] Encouraging good miners
Date: Mon, 27 Mar 2017 13:01:41 -0700	[thread overview]
Message-ID: <b99eda2f-b638-e188-e678-f93bba147404@voskuil.org> (raw)
In-Reply-To: <7350662.8AQMRkRU5C@cherry>

-----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-----


  reply	other threads:[~2017-03-27 20:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 16:12 [bitcoin-dev] Encouraging good miners Btc Ideas
2017-03-27 16:29 ` Jameson Lopp
     [not found] ` <WM!6b16e14ff3d44b0c6c0030538191fb22c33a979bb09131ef246ffc477e216212e64cfae815c6af871886f74be6b38d7f!@mailhub-mx4.ncl.ac.uk>
     [not found]   ` <VI1PR0701MB2240F0890E5F19E53CF94B43B5330@VI1PR0701MB2240.eurprd07.prod.outlook.com>
     [not found]     ` <WM!1f99375705714ae4f8b1288ea47707c53f573e0597317337d41d22e28f801234a0d946b8ef05335cccb825f27bdd72da!@mailhub-mx2.ncl.ac.uk>
2017-03-27 16:29       ` Btc Ideas
2017-03-27 17:29 ` Tom Zander
2017-03-27 20:01   ` Eric Voskuil [this message]
2017-03-27 17:50 ` Stian Ellingsen
2017-03-28 14:38   ` Juan Garavaglia
2017-03-27 20:56 ` Antoine Le Calvez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b99eda2f-b638-e188-e678-f93bba147404@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=btcideas@protonmail.com \
    --cc=tomz@freedommail.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox