📅 Original date posted:2017-03-27
📝 Original message:-----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-----
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:57:57
in reply to nevent1q…vnr5
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 17:57:57Event JSON
{
"id": "384076abcd16214ffbaa2dbbd51fd3a1c88b067d6a72b2327bf7c749ee05dfc5",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160677,
"kind": 1,
"tags": [
[
"e",
"0b651f3e0fe605dabc34e0fbd7da6709387ad2d1e58e6388b09dadf95f56afe5",
"",
"root"
],
[
"e",
"93f589455e14ced861531d003452323661bb91c47629f50831de5dab344b696b",
"",
"reply"
],
[
"p",
"dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7"
]
],
"content": "📅 Original date posted:2017-03-27\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn 03/27/2017 10:29 AM, Tom Zander via bitcoin-dev wrote:\n\u003e For some time now the relation between block size and propagation\n\u003e speed has been decoupled. Using xthin/compact blocks miners only\n\u003e send a tiny version of a block which then causes the receiving node\n\u003e to re-create it using the memory pool. Immediately getting double\n\u003e benefits by including pre-verified transactions from the memory\n\u003e pool you avoid the old problem of having to validate them again\n\u003e when a block was mined.\n\u003e \n\u003e As such there is no downside to a miner creating a bigger block, as\n\u003e long as all the transactions they include are actually in the\n\u003e mempool.\n\nAll transactions being publicly available is not something that can be\nassumed.\n\nWith no opportunity cost for a miner to generate withheld\ntransactions, a larger miner still maintains the economic advantage of\nlatency as a function of block size. Fast relay works to reduce\nlatency in relation to the opportunity cost created by the space\nconstraint. IOW, the more fees a miner must give up to mine withheld\ntransactions, the greater the economic disadvantage of doing so. So\nthere is a \"downside\" (i.e. centralization pressure) up to the point\nwhere the advantage gained from withholding transactions turns negative.\n\nThe rational competing miner must presume that a block is valid upon\nconfirming the announcement's PoW. He then has the choice of mining on\ntop of the (partially-visible) block, or ignoring it until it can be\nfully populated. The former *eliminates fee opportunity*, since the\nnext block must remain free of all public fee-generating transactions\nuntil all of the preceding block's transactions are visible. The\nlatter increases orphaning probability, since it implies mining on the\nweak chain, which *increases total reward loss*.\n\nOne can conclude that no matter how much space is created, it will\nalways be filled by a rational miner, as a competitive necessity,\ngiven the centralizing effect of latency. Making blocks big enough to\ninclude low cost transactions nullifies the benefits of fast relay\ntechniques based on your above assumption, since a rational miner will\nsimply substitute withheld transactions.\n\ne\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (GNU/Linux)\n\niQEcBAEBCAAGBQJY2W+bAAoJEDzYwH8LXOFOzkwH+wUulsdvUcfEHMspolfDjTD+\nf4egP1FDoOFgXzaGJ+Bq1AjWP+CDYup9msYhp1NTk6xRnG4uGvaEA3DFYGbAzLut\nINtkpCi38O1QGtDJaxmkJHXLoWJPS6VudcDEoam4W6qSKgHFB+ZRnIN4T7jnGMLI\nrp/cGdom9wE/pcq/fvF/fonGfVWf/YP2YjBzJzaJy+zOYPTH2rNcnYBCHFPs4/KX\n9Gu7tDw9WNxM5idnd0TiidublQhYui6xo7ZbZpmXQePcHQoQO5XqaO6yWwiWRWaU\nmqXhalASOtP6xnPzj6FfAHYS7qA7JCaDfwT8UIzt9xv9XsPrhQ/r6Sfgfhvbm2k=\n=b9sf\n-----END PGP SIGNATURE-----",
"sig": "3cb4060ed1f2c64e014868288345bfa9c3b9f50afbdab7d70c1678bf7f7a3fefece00bbe95dd96bd4bbf9dd1774316d06dbc0ae40d8bb9e1d89ed85739ec098d"
}