From: vjudeu@gazeta•pl
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
Date: Mon, 13 Dec 2021 15:10:49 +0100 [thread overview]
Message-ID: <150216403-2fc1a5b1e9f48639bccf4fa9a5ebd62e@pmq4v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]
> Can you maybe try stating the goals of your payout function, and then demonstrate how what you're proposing meets that?
The goals are quite simple: if you are a solo miner, you are trying to mine a block that meets the network difficulty. If you are using some kind of pool, then you are trying to mine N times easier blocks and receive N times lower reward for doing that. If many miners work on similar transactions, then each miner can validate each transaction once and assign transaction fee to transaction id, in this way the coinbase reward can be quickly checked, because you have to check only those transactions, which were unknown to you and for example included only by this miner and not broadcasted. Assuming that most of the transactions will be the same and included by most of the miners, that verification would be quick and can be simplified only to checking "what is different from what I am mining".
Also, to determine the proper amount of shares received, you can assign a difficulty for each miner. So, if you are connected to eight mining nodes, you can assign a difficulty to each of them, just to limit how much work for each share they can produce to have it accepted and included for payments. It is needed to avoid spamming by producing a lot of shares at difficulty one by bigger miners, they should find it more profitable to create bigger shares, because by accumulating them, it is cheaper to receive one bigger payment than a lot of smaller payments.
On 2021-12-13 14:59:58 user Jeremy <jlrubin@mit•edu> wrote:
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: 5340 bytes --]
next reply other threads:[~2021-12-13 14:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 14:10 vjudeu [this message]
-- strict thread matches above, loose matches on Subject: below --
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
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
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=150216403-2fc1a5b1e9f48639bccf4fa9a5ebd62e@pmq4v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/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