-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How covenants could optimize coinbase payouts in mining pools ? #8
Conversation
This is not a "pool" as it does not reduce variance. (There are no shares) I suggest changing the name to something less confusing. Please read the following, which I wrote partially in response to this idea and in which covenants are discussed in a couple places: I'm open to using covenants in a decentralized mining pool, but right now I can't see how they provide any benefit. If you think of one I'd love to hear. |
Note, the following notes are gathered from a review of https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf, which I think has some shares issuance mechanism (i.e Score Per Last N Shares). However, I can understand how those preliminary notes can lead to confusion in the lack of a strong mining pool as a comparison basis. I'll have a look on the "braidcoin" design referred and updates notes in consequence! Likewise, see ML answer here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020933.html I don't think covenants are blockers for the design of a decentralized mining pool, at best an efficiency improvement. That said, for now I think it's just good to document and research more decentralized mining pool designs, before to completely exclude covenants support from their requirements. |
So, to focus the attention, would it make sense to rewrite this as "How covenants could optimize coinbase payouts in mining pools"? That's what I think could be useful. Then documented use of CTV would be a one example, but our article here could be more general. We should also discuss how this optimization may be compatible or not with alternative pool designs, and whether this direction is even worthy of consideration. |
I think the problem could be even abstract a step further. The issue here sounds to be the non-interactive payments of a high-order of parties with compact on-chain size. It sounds similar to me to the non-interactive channel funding, where the payer is the coinbase output. On removing the trust from the block producer in the exchange of the mining shares, I think we could have some construction where the mining pool participants outputs can only be redeem by presenting a shares trace in the witness. I don't think you could to that with today Script, however some ZKP-based bisection protocol could be enroll in the witnessScript, I guess. |
Yeah, to me it sounded like a CoinPool or something, just seeing how it will work for miners specifically.
Or that can be decided by the consensus layer between miners (their own MPC based on the weak blocks), and the UTXO could be crafted within that process. This is what @mcelrath suggests i think. Btw, can you explain what do you mean by "presenting a shares trace in the witness"? I can only think of a weak block, but then not sure how do you embed it in the witnessScript (assuming ZKP allows arbitrary stuff just like RGB does then I understand). |
Yeah assuming ZKP allowing arbitrary stuff, especially recent proposals like https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html |
Additional resource: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-August/020869.html |
Closes #1. Would be good to cross analysis with other distributed/decentralized mining pool payouts schemes. Mining pool terminology could be better defined.