Hi Billy!
Thanks for your response. Some replies inline:
Looks like an interesting proposal, but it doesn't seem to quite match the goals you mentioned. As you do mention, this mining pool coordination doesn't get rid of the need for mining pools in the first place. So it doesn't satisfy item 1 on your goal list afaict.
It does, actually :) Point 1 was
- Funds should not be centrally custodied, ever, if at all
And for top-level pool participants there is never any central custody. What the windows are there (100 blocks, 2016, 4032, etc) is up to the specific implementation which sets limits on how small you can be to participate.
Further, for the entities that are too small:
from the article:
> The blocks that they mine should use a taproot address/key which is a multisig of some portion of the workshares, that gets included in the top-level pool as a part of Payment Pool.
The micro-pools embed a multisig of top-contributors, 'reputable' members, or on a rotating basis, as a leaf node to the parent. They then opt-out of having their leaf channel-ized, as noted.
T
his would be fully non-custodial if we always included all miners. The issue is that opens up DoS if one miner goes away, so you do want to anchor around a few.
In this mode, you can set the protocol up such that immediately after getting a reward in a block, you should see the chosen nodes for multi-sigs distribute the spoils according to the schedule that is agreed on in the block causing the share to be granted.
the main issue is data availability, without extra in-band storage local mining pools have to track the work shares (which can be committed to in a block) locally for auditing.
This is not fully non-custodial, but it doesn't have to be centrally custodied by one party. We can multisig immediately after every block (and nodes should quit their pool if they don't get sigs quickly perhaps). Further, nodes can hash into multiple pools dividing their risk (modulo sybil attack) across many pools.
If we had stronger covenants (CAT, AMOUNT, DIVIDE/MUL), we could make every leaf node commit to payment pools that operate on percents instead of fixed amounts and we'd be able to handle this in a manner that the payment pools work no matter what amount is assigned to them.
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pools, and
2. Lower on chain footprint through combining pay outs from multiple pools.
Am I missing some?
These are interesting benefits, but it would be nice if your post was clearer on that, since the goals list is not the same as the list of potential benefits of this kind of design.
I think I hit all the benefits mentioned:
1. Funds should not be centrally custodied, ever, if at all.
see above -- we can do better for smaller miners, but we hit this for miners above the threshold.
2. No KYC/AML.
see above, payouts are done 'decentralized' by every miner mining to the payout
3. No “Extra network” software required.
you need the WASM, but do not need any networked software to participate, so there are no DoS concerns from participating.
You do need extra software to e.g. use channels or cut-through multiple pools, but only after the fact of minding.
4. No blockchain bloat.
Very little, if cut-through + LN works.
5. No extra infrastructure.
Not much needed, if anything. I don't really know what 'infrastructure' means, but I kind of imagined it to mean 'big expensive things' that would make it hard to partake.
6. The size of a viable pool should be smaller. Remember our singer – if you just pool with one other songwriter it doesn’t make your expected time till payout in your lifetime. So bigger the pools, more regular the payouts. We want the smallest possible “units of control” with the most regular payouts possible.
I think this works, roughly?
As far as enabling solo mining, what if this concept were used off chain? Have a public network of solo miners who publish "weak blocks" to that network, and the next 100 (or 1000 etc) nice miners pay you out as long as you're also being nice by following the protocol? All the nice optimizations you mentioned about eg combined taproot payouts would apply i think. The only goals this wouldn't satisfy are 3 and 5 since an extra network is needed, but to be fair, your proposal requires pools which all need their own extra network anyways.
The missing piece here would be an ordering of weak blocks to make the window possible. Or at least a way to determine what blocks should definitely be part of a particular block's pay out. I could see this being done by a separate ephemeral blockchain (which starts fresh after each Bitcoin block) that keeps track of which weak blocks have been submitted, potentially using the pow already in each block to secure it. Granted that piece is a bit half baked, but it seems quite solvable. Wdyt?
Yeah, it's worth thinking more about 100%. This post wasn't a deployable thing, more an exposition of a technique. I'd love to see a weak-block based pool, the main issue as noted is the extra software component + data availability, but perhaps that's solvable!
One thing that jumped out at me as not safe is throwing block rewards into a channel and being able to spend them immediately. There's a reason block rewards aren't spendable for a while, and channels don't solve that problem, do they? Why not simply reduce the on chain wait time for spending block rewards at that point? Seems like the consequences would be the same.
Miners could already do this if they mine to e.g. a multisig (trustlessly if they form blocks with their counterparty and pre-sign before hashing). Also in lightning we don't generally have to check that our routes channels exist, we don't care as long as they are happy. Thus it doesn't "hurt" anyone except for the miners who are taking the not fully locked in funds risk, a risk they already take. But that risk can't infect the rest of Bitcoin's users.