> 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?