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-----
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=btcideas@protonmail$(echo .)com \
--cc=tomz@freedommail$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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