📅 Original date posted:2021-12-14
📝 Original message:This, quite simply, is not a "pool". A pool is by definition a tool to reduce
profit variance by miners by collecting "weak blocks" that do not meet the
difficulty target, so as to get a better statistical measure of each miner's
hashrate, which is used to subdivide profits. These are called "shares" and are
entirely absent here.
The only available information here to decide payouts is the blocks themselves,
I do not have any higher statistics measurement to subdivide payments. If I
expect to earn 3 blocks within the window, sometimes I will earn 2 and sometimes
I will earn 4. Whether I keep the entire coinbase in those 2-4 blocks, or I have
100 other miners paying me 1/100 as much 100 times, my payment is the same and
must be proportional to the number of blocks I mine in the window. My variance
is not reduced.
Further, by making miners pay other miners within the window N, this results in
N^2 payments to miners which otherwise would have had N coinbase payments. So,
this is extremely block-space inefficient for no good reason. P2Pool had the
same problem and generated giant coinbases which competed with fee revenue.
"Congestion control" makes this somewhat worse since is it is an absolute
increase in the block space consumed for these N^2 payments.
The only thing this proposal does do is smooth out fee revenue. While hedging on
fee revenue is valuable, this is an extremely complicated and expensive way to
go about it, that simultaneously *reduces* fee revenue due to all the extra
block space used for miner payouts.
Jeremy via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> Howdy, welcome to day 15!
>
> Today's post covers a form of a mining pool that can be operated as sort of a
> map-reduce over blocks without any "infrastructure".
>
> https://rubin.io/bitcoin/2021/12/12/advent-15/
>
> There's still some really open-ended questions (perhaps for y'all to consider)
> around how to select an analyze the choice of window and payout functions, but
> something like this could alleviate a lot of the centralization pressures
> typically faced by pools.
>
> Notably, compared to previous attempts, combining the payment pool payout with
> this concept means that there is practically very little on-chain overhead from
> this approach as the chain-load
> for including payouts in every block is deferred for future cooperation among
> miners. Although that can be considered cooperation itself, if you think of it
> like a pipeline, the cooperation happens out of band from mining and block
> production so it really is coordination free to mine.
>
>
> Cheers,
>
> Jeremy
>
> --
> @JeremyRubin
> !DSPAM:61b626be345321821816715!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:61b626be345321821816715!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
Bob McElrath [ARCHIVE] /
npub15n…8vrz4
2023-06-07 23:01:26
in reply to nevent1q…xee2
Author Public Key
npub15n7zls4lcps7wksmdctal39neyact74jljgsq86ylkzfn4njk95sv8vrz4Published at
2023-06-07 23:01:26Event JSON
{
"id": "5b721cdfdb5f0367a9248e970eb34f80c39efb14c92398b38a246bd7a76e866b",
"pubkey": "a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169",
"created_at": 1686178886,
"kind": 1,
"tags": [
[
"e",
"9a9e1cb20e5c4bb51b22b23239ac4878d89ce4dba6ef6fe0cc58cd4270d58751",
"",
"root"
],
[
"e",
"5a28560a535e5f7e65089da2d7753b74593119e35c5c70dadcec38f07f30954e",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2021-12-14\n📝 Original message:This, quite simply, is not a \"pool\". A pool is by definition a tool to reduce\nprofit variance by miners by collecting \"weak blocks\" that do not meet the\ndifficulty target, so as to get a better statistical measure of each miner's\nhashrate, which is used to subdivide profits. These are called \"shares\" and are\nentirely absent here.\n\nThe only available information here to decide payouts is the blocks themselves,\nI do not have any higher statistics measurement to subdivide payments. If I\nexpect to earn 3 blocks within the window, sometimes I will earn 2 and sometimes\nI will earn 4. Whether I keep the entire coinbase in those 2-4 blocks, or I have\n100 other miners paying me 1/100 as much 100 times, my payment is the same and\nmust be proportional to the number of blocks I mine in the window. My variance\nis not reduced.\n\nFurther, by making miners pay other miners within the window N, this results in\nN^2 payments to miners which otherwise would have had N coinbase payments. So,\nthis is extremely block-space inefficient for no good reason. P2Pool had the\nsame problem and generated giant coinbases which competed with fee revenue.\n\"Congestion control\" makes this somewhat worse since is it is an absolute\nincrease in the block space consumed for these N^2 payments.\n\nThe only thing this proposal does do is smooth out fee revenue. While hedging on\nfee revenue is valuable, this is an extremely complicated and expensive way to\ngo about it, that simultaneously *reduces* fee revenue due to all the extra\nblock space used for miner payouts.\n\nJeremy via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:\n\u003e Howdy, welcome to day 15!\n\u003e \n\u003e Today's post covers a form of a mining pool that can be operated as sort of a\n\u003e map-reduce over blocks without any \"infrastructure\".\n\u003e \n\u003e https://rubin.io/bitcoin/2021/12/12/advent-15/\n\u003e \n\u003e There's still some really open-ended questions (perhaps for y'all to consider)\n\u003e around how to select an analyze the choice of window and payout functions, but\n\u003e something like this could alleviate a lot of the centralization pressures\n\u003e typically faced by pools.\n\u003e \n\u003e Notably, compared to previous attempts, combining the payment pool payout with\n\u003e this concept means that there is practically very little on-chain overhead from\n\u003e this approach as the chain-load\n\u003e for including payouts in every block is deferred for future cooperation among\n\u003e miners. Although that can be considered cooperation itself, if you think of it\n\u003e like a pipeline, the cooperation happens out of band from mining and block\n\u003e production so it really is coordination free to mine.\n\u003e \n\u003e \n\u003e Cheers,\n\u003e \n\u003e Jeremy\n\u003e \n\u003e --\n\u003e @JeremyRubin \n\u003e !DSPAM:61b626be345321821816715!\n\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e !DSPAM:61b626be345321821816715!\n\n--\nCheers, Bob McElrath\n\n\"For every complex problem, there is a solution that is simple, neat, and wrong.\"\n -- H. L. Mencken",
"sig": "9bce95d6d744c8d2b144167f0ffe35ca37dc076e46ae7302cc987538e04c9b2b0408b9465648709e5a348d717c8eba71679f6939094517cfa45eb5583b4c7ab3"
}