From: Jeremy <jlrubin@mit•edu>
To: Bob McElrath <bob_bitcoin@mcelrath•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
Date: Tue, 14 Dec 2021 11:50:33 -0800 [thread overview]
Message-ID: <CAD5xwhhx3JzUE0ggFo4Hmj4FTmWHBzeY7JHTrD__gFVFYz=H-g@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhiLBSCpErJTRbh05v+_i09daJTQQAtzYd-JcWXQojzT2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
I've received some confused messages that whatever I was replying to didn't
come through, I've reproduced Bob's e-mail below that I was responding to
for context:
*This, quite simply, is not a "pool". A pool is by definition a tool to
reduceprofit variance by miners by collecting "weak blocks" that do not
meet thedifficulty target, so as to get a better statistical measure of
each miner'shashrate, which is used to subdivide profits. These are called
"shares" and areentirely 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 Iexpect to earn 3 blocks within the
window, sometimes I will earn 2 and sometimesI will earn 4. Whether I keep
the entire coinbase in those 2-4 blocks, or I have100 other miners paying
me 1/100 as much 100 times, my payment is the same andmust be proportional
to the number of blocks I mine in the window. My varianceis not
reduced.Further, by making miners pay other miners within the window N,
this results inN^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 thesame problem and generated giant coinbases which
competed with fee revenue."Congestion control" makes this somewhat worse
since is it is an absoluteincrease in the block space consumed for these
N^2 payments.The only thing this proposal does do is smooth out fee
revenue. While hedging onfee revenue is valuable, this is an extremely
complicated and expensive way togo about it, that simultaneously *reduces*
fee revenue due to all the extrablock space used for miner payouts.*
>
[-- Attachment #2: Type: text/html, Size: 5919 bytes --]
next prev parent reply other threads:[~2021-12-14 19:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-12 16:43 Jeremy
2021-12-12 23:14 ` vjudeu
2021-12-13 1:31 ` Jeremy
[not found] ` <20211214190524.GA30559@mcelrath.org>
2021-12-14 19:39 ` Jeremy
2021-12-14 19:50 ` Jeremy [this message]
2021-12-15 0:12 ` Bob McElrath
2021-12-15 17:25 ` Billy Tetrud
2021-12-15 18:39 ` Jeremy
2021-12-15 18:51 ` Bob McElrath
2021-12-16 9:35 ` vjudeu
2021-12-16 16:57 ` Billy Tetrud
2021-12-17 0:37 ` Jeremy
2021-12-17 6:37 ` vjudeu
2021-12-20 17:18 ` Billy Tetrud
2021-12-23 11:56 ` vjudeu
2021-12-23 19:05 ` Jeremy
2022-01-18 18:15 ` Billy Tetrud
2021-12-14 23:33 ` Bob McElrath
2021-12-15 21:10 ` yanmaani
2021-12-15 21:53 ` Jeremy
2021-12-13 14:10 vjudeu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD5xwhhx3JzUE0ggFo4Hmj4FTmWHBzeY7JHTrD__gFVFYz=H-g@mail.gmail.com' \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bob_bitcoin@mcelrath$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox