From: Jeremy <jlrubin@mit.edu>
To: vjudeu@gazeta.pl
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
Date: Sun, 12 Dec 2021 17:31:42 -0800 [thread overview]
Message-ID: <CAD5xwhgPFxm9_K_z4gomDa9AV1FAdhCq+-YYnreJAS+jcW+4Sw@mail.gmail.com> (raw)
In-Reply-To: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Hey there!
Thanks for your response!
One of the reasons to pick a longer window of, say, a couple difficulty
periods would be that you can make participation in the pool hedge you
against hashrate changes.
You're absolutely spot on to think about the impact of pooling w.r.t.
variance when fees > subsidy. That's not really in the analysis I had in
the (old) post, but when the block revenues swing, dcfmp over longer
periods can really smooth out the revenues for miners in a great way. This can
also help with the "mind the gap" problem when there isn't a backlog of
transactions, since producing an empty block still has some value (in order
to incentivize mining transaction at all and not cheating, we need to
reward txn inclusion as I think you're trying to point out.
Sadly, I've read the rest of your email a couple times and I don't really
get what you're proposing at all. It jumps right into "things you could
compute". Can you maybe try stating the goals of your payout function, and
then demonstrate how what you're proposing meets that? E.g., we want to pay
more to miners that do x?
[-- Attachment #2: Type: text/html, Size: 3817 bytes --]
next prev parent reply other threads:[~2021-12-13 1:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-12 16:43 [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools Jeremy
2021-12-12 23:14 ` vjudeu
2021-12-13 1:31 ` Jeremy [this message]
[not found] ` <20211214190524.GA30559@mcelrath.org>
2021-12-14 19:39 ` Jeremy
2021-12-14 19:50 ` Jeremy
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=CAD5xwhgPFxm9_K_z4gomDa9AV1FAdhCq+-YYnreJAS+jcW+4Sw@mail.gmail.com \
--to=jlrubin@mit.edu \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=vjudeu@gazeta.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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