📅 Original date posted:2015-08-10
📝 Original message:On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.
I don't understand this. All problems that result from propagation delay
are literally doubled by doing so. Centralization pressure results from the
ratio between propagation time and interblock time. Efficient propagation
algorithms like the relay network make this presumably grow sublinear with
larger blocks, but changing the interblock time affects it exactly
proportionally.
All problems that result from propagation delay are literally doubled by
doing this. Doubling the block size has a smaller effect. You may argue
that these centralization effects are small, but reducing the interblock
time has a stronger effect on them than the block size.
Also, you seem to consider SPV mining a good thing? It requires trust
between miners that know eachother, and fundamentally breaks the security
assumption of SPV clients... and if the propagation/interblock ratio was
lower, SPV mining would have less effect. I'd say it is exactly a result of
the centralization pressure we're trying to avoid.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/f50a4a75/attachment-0001.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:46:18
in reply to nevent1q…3fv5
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:46:18Event JSON
{
"id": "e6120037dee67b2d03fd169c3207892467ffb4bdf40c4f8793bd66a13d6b727e",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152778,
"kind": 1,
"tags": [
[
"e",
"82fc211df219167c45c4f9e69a80d3141b5a52b634c5bb5ed1fc08722ad342cd",
"",
"root"
],
[
"e",
"23479d9fecb088fadf7ccfd8d3c992fc8381faa72916a177ce667b00e43e9eb3",
"",
"reply"
],
[
"p",
"3b13ba0c54ee795e830f91a69b77d5495cb173de5bc0c93f4ddea05affee0c2f"
]
],
"content": "📅 Original date posted:2015-08-10\n📝 Original message:On Aug 7, 2015 11:19 PM, \"Sergio Demian Lerner via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e b. Reduce the block rate to a half (average 5 minute blocks)\n\u003e\n\u003e Suppose this is a one time hard fork. There no drastic technical problems\nwith any of them: \"SPV\" mining and the relay network has shown that block\npropagation is not an issue for such as small change. Mining centralization\nwon't radically change for a 2x adjustment.\n\nI don't understand this. All problems that result from propagation delay\nare literally doubled by doing so. Centralization pressure results from the\nratio between propagation time and interblock time. Efficient propagation\nalgorithms like the relay network make this presumably grow sublinear with\nlarger blocks, but changing the interblock time affects it exactly\nproportionally.\n\nAll problems that result from propagation delay are literally doubled by\ndoing this. Doubling the block size has a smaller effect. You may argue\nthat these centralization effects are small, but reducing the interblock\ntime has a stronger effect on them than the block size.\n\nAlso, you seem to consider SPV mining a good thing? It requires trust\nbetween miners that know eachother, and fundamentally breaks the security\nassumption of SPV clients... and if the propagation/interblock ratio was\nlower, SPV mining would have less effect. I'd say it is exactly a result of\nthe centralization pressure we're trying to avoid.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/f50a4a75/attachment-0001.html\u003e",
"sig": "edb3a0dbfc495ff6f37c01e957fe3dcb69f1f743d484c71ec6bc3eb0c2c125509b05d75fc4c2d451e932c61058f2b5ccfd50956e2838a3f50e76c323d6f760bd"
}