public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
@ 2021-12-12 16:43 Jeremy
  2021-12-12 23:14 ` vjudeu
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Jeremy @ 2021-12-12 16:43 UTC (permalink / raw)
  To: Bitcoin development mailing list

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized Coordination Free Mining Pools
@ 2021-12-13 14:10 vjudeu
  0 siblings, 0 replies; 21+ messages in thread
From: vjudeu @ 2021-12-13 14:10 UTC (permalink / raw)
  To: Jeremy; +Cc: Bitcoin development mailing list

[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-01-18 18:15 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
     [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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox