š
Original date posted:2015-08-29
š Original message:I'd like to submit this paper to the dev-list which analyzes how miner
advantages scale with network and mempool properties in a scenario of
uncapped block sizes. The work proceeds, in a sense, from where Peter R's
work left off correcting a mistake and addressing the critiques made by the
community to his work.
The main result of the work is a detailed analysis of mining advantages
(defined as the added profit per unit of hash) as a function of miner
hashrate. In it, I show how large block subsidies (or better, low mempool
fees-to-subsidy ratios) incentivize the pooling of large hashrates due to
the steady increasing of marginal profits as hashrates grow.
The paper also shows that part of the large advantage the large miners have
today is due to there being a barrier to entry into a high-efficiency
mining class which has access to expected profits an order of magnitude
larger than everyone else. As block subsidies decrease, this
high-efficiency class is expected to vanish leading to a marginal profit
structure which decreases as a function of hashrate.
This work has vacuumed my entire life for the past two weeks leading me to
lag behind on a lot of work. I apologize for typos which I may not have
seen. I stand by for any comments the community may have and look forward
to reigniting consideration of a block size scaling proposal (BIP101)
which, due to the XT fork drama, I believe has been placed hastily and
undeservedly on the chopping block.
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
Regards,
Daniele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/527d1332/attachment.html>;
Daniele Pinna [ARCHIVE] /
npub16zā¦jg59c
2023-06-07 19:38:29
in reply to nevent1qā¦vqz0
Author Public Key
npub16z2msvydkmd6xsjyrggnavcwrlpevfwq74x5avxrkg2dpq7cg6js5jg59cPublished at
2023-06-07 19:38:29Event JSON
{
"id": "47081f4d260228264e3c1300409f3c2b0ad8d02419ffe5ef14356a8a31d64345",
"pubkey": "d095b8308db6dba342441a113eb30e1fc39625c0f54d4eb0c3b214d083d846a5",
"created_at": 1686159509,
"kind": 1,
"tags": [
[
"e",
"0661900655c185954861e9dd47a3c90a7539e4ad00ac9bc99572ea9f24ea546a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2015-08-29\nš Original message:I'd like to submit this paper to the dev-list which analyzes how miner\nadvantages scale with network and mempool properties in a scenario of\nuncapped block sizes. The work proceeds, in a sense, from where Peter R's\nwork left off correcting a mistake and addressing the critiques made by the\ncommunity to his work.\n\nThe main result of the work is a detailed analysis of mining advantages\n(defined as the added profit per unit of hash) as a function of miner\nhashrate. In it, I show how large block subsidies (or better, low mempool\nfees-to-subsidy ratios) incentivize the pooling of large hashrates due to\nthe steady increasing of marginal profits as hashrates grow.\n\nThe paper also shows that part of the large advantage the large miners have\ntoday is due to there being a barrier to entry into a high-efficiency\nmining class which has access to expected profits an order of magnitude\nlarger than everyone else. As block subsidies decrease, this\nhigh-efficiency class is expected to vanish leading to a marginal profit\nstructure which decreases as a function of hashrate.\n\nThis work has vacuumed my entire life for the past two weeks leading me to\nlag behind on a lot of work. I apologize for typos which I may not have\nseen. I stand by for any comments the community may have and look forward\nto reigniting consideration of a block size scaling proposal (BIP101)\nwhich, due to the XT fork drama, I believe has been placed hastily and\nundeservedly on the chopping block.\n\nhttps://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets\n\nRegards,\nDaniele\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/527d1332/attachment.html\u003e",
"sig": "58f667aa2f930b4167a77d0a8ca791681474cb280d1969a776df77f3ec574dadcbfb179dbe29e28235c1a47a74580028bb94ee4f561c227103074aea3932b29c"
}