Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-04 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>The paper is nicely done, but I'm concerned that there's a real problem
>with equation 4. The orphan rate is not just a function of time; it's
>also a function of the block maker's proportion of the network hash
>rate. Fundamentally a block maker (pool or aggregation of pools) does
>not orphan its own blocks. In a degenerate case a 100% pool has no
>orphaned blocks. Consider that a 1% miner must assume a greater risk
>from orphaning than, say, a pool with 25%, or worse 40% of the hash
>rate.
>
>I suspect this may well change some of the conclusions as larger block
>makers will definitely be able to create larger blocks than their
>smaller counterparts.
Quite correct; this paper is fatally flawed and at best rehashes what we already know happens in the "spherical cow" case, without making it clear that it refers to a completely unrealistic setup. It'd be interested to know who actually wrote it - "Peter R" is obviously a pseudonym and the paper goes into sufficient detail that it makes you wonder why the author didn't see the flaws in it.
For those wishing to do actual research, esp. people such as profs mentoring students, keep in mind that in Bitcoin situations where large miners have an advantage over small miners are security exploits, with severity proportional to the difference in profitability. A good example of the type of analysis required is the well known selfish mining paper, which shows how a miner adopting a "selfish" strategy has an advantage - more profit per unit hashing power - than miners who do not adopt that strategy, and additionally, that excess profits scales with increasing hashing power.
As for the OP, if this wasn't an attempt at misinformation, my apologies. But keep in mind that you're wading into a highly politically charged research field with billions hanging on the blocksize limit; understand that people aren't happy when flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future work past experts in the field prior to publishing widely if you dislike heated controversy.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwSwJ
AAoJEMCF8hzn9Lnc47AH/RknSZpnZ8r4WA4r+S0yJmlo0hKm8gsjUGhaqX7cnuSR
dB1ewrsjC4uPtSc8Ej1hzf37E67DTxiz6STq9XdtFSij+ww7SPx+z8yjEpQ0Ld0K
OIidQ80WRGJ1UPMUt7pFDU3pxNZI/A46Lg3EmqjY+xAe6+wDlOHjT/miO3tv0uws
nNYwrelA4f/KQXkUggGUOW62Sc3fJpUxLurq4eQHflIxtk3KM1reSxwG28KG02j6
lTUEHmMsmE7qoQAl60vwfvVKvvy/RwxpildwNey6IgtCQqWqqEy+WoTsgyVAGIbn
+8gR//W2hEIp+W5OSsiVNZ5S/KpcwaIBqZFcoca8838=
=HJiv
-----END PGP SIGNATURE-----
Published at
2023-06-07 17:32:48Event JSON
{
"id": "3ede308d787ae6b368acaadd9b38ff1d29f3e1b51b4ee8e17a2a182b8e66c281",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686159168,
"kind": 1,
"tags": [
[
"e",
"2da2e00d8e383de13f6ee6d9d66f9da48994b834188a0ae47ea0319febd85ff5",
"",
"root"
],
[
"e",
"33ea7fdb642af550c8f78003162b73a9a6f51e49a8d3fa647dbd9b332a803183",
"",
"reply"
],
[
"p",
"1e54a6de7941fa2778512f8b39026a806a830835f3e28d29701b37064e5ed5f2"
]
],
"content": "📅 Original date posted:2015-08-04\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n\n\nOn 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eThe paper is nicely done, but I'm concerned that there's a real problem\n\u003ewith equation 4. The orphan rate is not just a function of time; it's\n\u003ealso a function of the block maker's proportion of the network hash\n\u003erate. Fundamentally a block maker (pool or aggregation of pools) does\n\u003enot orphan its own blocks. In a degenerate case a 100% pool has no\n\u003eorphaned blocks. Consider that a 1% miner must assume a greater risk\n\u003efrom orphaning than, say, a pool with 25%, or worse 40% of the hash\n\u003erate.\n\u003e\n\u003eI suspect this may well change some of the conclusions as larger block\n\u003emakers will definitely be able to create larger blocks than their\n\u003esmaller counterparts.\n\nQuite correct; this paper is fatally flawed and at best rehashes what we already know happens in the \"spherical cow\" case, without making it clear that it refers to a completely unrealistic setup. It'd be interested to know who actually wrote it - \"Peter R\" is obviously a pseudonym and the paper goes into sufficient detail that it makes you wonder why the author didn't see the flaws in it.\n\nFor those wishing to do actual research, esp. people such as profs mentoring students, keep in mind that in Bitcoin situations where large miners have an advantage over small miners are security exploits, with severity proportional to the difference in profitability. A good example of the type of analysis required is the well known selfish mining paper, which shows how a miner adopting a \"selfish\" strategy has an advantage - more profit per unit hashing power - than miners who do not adopt that strategy, and additionally, that excess profits scales with increasing hashing power.\n\nAs for the OP, if this wasn't an attempt at misinformation, my apologies. But keep in mind that you're wading into a highly politically charged research field with billions hanging on the blocksize limit; understand that people aren't happy when flawed papers end up on reddit being used to promote bad ideas. You'd be wise to run future work past experts in the field prior to publishing widely if you dislike heated controversy.\n\n-----BEGIN PGP SIGNATURE-----\n\niQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVwSwJ\nAAoJEMCF8hzn9Lnc47AH/RknSZpnZ8r4WA4r+S0yJmlo0hKm8gsjUGhaqX7cnuSR\ndB1ewrsjC4uPtSc8Ej1hzf37E67DTxiz6STq9XdtFSij+ww7SPx+z8yjEpQ0Ld0K\nOIidQ80WRGJ1UPMUt7pFDU3pxNZI/A46Lg3EmqjY+xAe6+wDlOHjT/miO3tv0uws\nnNYwrelA4f/KQXkUggGUOW62Sc3fJpUxLurq4eQHflIxtk3KM1reSxwG28KG02j6\nlTUEHmMsmE7qoQAl60vwfvVKvvy/RwxpildwNey6IgtCQqWqqEy+WoTsgyVAGIbn\n+8gR//W2hEIp+W5OSsiVNZ5S/KpcwaIBqZFcoca8838=\n=HJiv\n-----END PGP SIGNATURE-----",
"sig": "9c2784a31ac06e54dfc674640c211e83b24195f89b49de71bceb04b52307d0eee1d3e80ec3bb63c26ab42b82b472bb34b58e93ca76651f674e22e67319be85f9"
}