Federated mining pools #1504
Replies: 13 comments 24 replies
-
|
I actually talked about this idea with an executive from one of the biggest mining pools and he was very interested. |
Beta Was this translation helpful? Give feedback.
-
|
Once we have a solid Fedimint v1 this is a module that I'd be interested in working on. |
Beta Was this translation helpful? Give feedback.
-
|
Private payouts would be a big value proposition to mining pools. That's a big reason people mine in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
An even bigger incentive could be pool fees which might be 1-2% plus on-chain payout fees. For miners operating with razor-thin margins this could be a significant % of their profits. I could see a scenario where few smaller mining companies form a federated pool to avoid those fees. Back-of-the-napkin math with some made-up numbers: If they also attract pleb miners to point their hashrate to the pool then they could have a steady enough income to avoid the major pools. |
Beta Was this translation helpful? Give feedback.
-
|
my remarks here
|
Beta Was this translation helpful? Give feedback.
-
|
The way im imagining it is if large miners are the guardians and start their own pool, then they can do things they really need. For instance maybe they don't even do BTC payouts, but a federated USD peg or something. Or do derivatives inside the federation. Cross party hashrate swaps. all kinds of stuff. |
Beta Was this translation helpful? Give feedback.
-
|
Had a private conversation with jkitman but figured I should post here for posterity. This is deceptively complicated to actually implement, and isn't solving a problem in a way that couldn't be solved much simpler: First of all, its important to agree on the set of problems here. From the pov of the bitcoin network, payout management doesn't really matter - what matters is who selects the block templates, which needs to be a decentralized as possible. Trusting one entity to manage payouts for a large group is not great for that group - at worst that entity could choose to not pay you if you don't censor, but that problem is generally easily rectified by simply migrating to a new pool in an automated and quick way. This proposal is deceptively complicated: a) in order to process payouts the federation needs to all validate all shares. In most pools today this is a very nontrivial amount of compute. You could increase the share difficulty across the pool to reduce this, but that comes at a cost of payout accuracy/reliability, which may drive some miners away. As mentioned, this proposal doesn't solve the block template creation decentralization problem, which is the problem with mining pools. It can help to address the ability of a pool to censor by telling miners to change their block selection "or else", but given the technical complexity of implementing consensus over pool shares I'm not convinced that's not better done by simply letting users migrate to another pool. Further, we don't need to reinvent the wheel here - if we want to decentralize pool payouts, p2pool exists. There's no need for a federation and it's not clear what it adds over something like p2pool. |
Beta Was this translation helpful? Give feedback.
-
|
In general this isn't what I had in mind. Simply the wallet that signs the coinbase tx is ideally a federated wallet. Or its an autoscraped wallet to a fedimint. I don't think anyone was ever advocating for this as a decentralized pool. More so a normal pool with a more federated wallet. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think that adds any value - see the comments above about ways individual entities in the federated wallet could still trivially steal funds from miners. |
Beta Was this translation helpful? Give feedback.
-
|
If you actually think that, then you missed the part where fedimint isn't bulletproof. It's for communities. A happy medium between full decentralization and centralization. You still have to trust guardians yes. But trusting many as opposed to 1 is better. Additionally, large miners such as myself would use a fedimint to do other cool things. Maybe they don't even get paid out in BTC. Maybe the fedimint only pays out in a pegged stablecoin and they can do their own p2p lending. This isn't about making the perfect pool. This is about enabling people to trust less and have more flexibility. It will be built, Fedimint is happening. And a fedipool is happening. Resistance is futile. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think you read what I said. "trusting many as opposed to 1 is better" is not the trust model of "fedipool". The trust model of the naive version of fedipool you describe is clearly "trust one", the multisig adds no value and does not change the trust model compared to a traditional pool. You can build it all you want, that doesn't mean it accomplishes what you think it accomplishes. |
Beta Was this translation helpful? Give feedback.
-
|
+1 in support for Matt.
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
A more decentralized outcome than that is for each of those individual federation members to spin up their own pool. That way you get single-best-jurisdiction properties, rather than (M-N)th best jurisdiction properties, as you'd get with an N-of-M pool.
There are various proposals to fix the dust UTXO issue with p2pool, which are relatively easy to do. Making such a change to p2pool is almost certainly easier than building out the required consensus layer for share validation in fediment. |
Beta Was this translation helpful? Give feedback.
-
I don't have any insider knowledge into mining operations, but if that was to happen it would already be happening. I don't think miners want to deal with it. Seems to me they just want to handle hardware, electricity, operations etc. not running pools. And (unfortunately) there are many benefits of pooling.
Spreading jurisdiction risk is the point here, as it makes harder to coordinate and confiscate funds simultaneously in multiple of them.
I find it unlikely. The big point of Fedimint is that consensus layer is already figured out and local (among the members of the federation and their users). Writing a new module on top is relatively easy, and critically there's no need to debate endlessly which solution is the best one, as each federation can use a different one. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that everyone using p2pool that somehow solved dust payouts and any other issues would be ideal, but is it going to be happen and will it work better in practice than federated mining pools remains to be seen. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I meant federation members, not mining pool members. Fedipool federation members are already operators of a lot of software, so running some open source pool software would also reasonably be an option.
I'm not sure that that's a large concern. Mining pools can pay out over lightning once a block and then there's no confiscation concern at all :).
A decentralized mining pool is not at all similar to simply "writing a new module" on fediment, see my longer comment above. |
Beta Was this translation helpful? Give feedback.
-
I dunno if its going to happen, someone has to sit down and write the code. My point above is that someone doing that would be (a) substantially less work and (b) have a substantially better outcome in terms of decentralization than someone sitting down and writing all the code required to do a real "multisig mining pool". |
Beta Was this translation helpful? Give feedback.
-
|
There are a couple different ideas of what a "Fedipool" is floating about. If we perform no share validation in consensus and assume one or more of the federation members can be trusted to validate shares, users still get benefits of having a Fedimint custodian (multisig security, ecash privacy, LN payouts, recovery options, mobile app, etc) If we validate shares in consensus, we will need to solve performance issues and miners will need to run a proxy, but that removes the risk of a single pool member not paying out. However, not paying out shares isn't a huge issue if miners can detect this and switch between pools or federation members before losing too many shares. A hybrid approach might be to require guardians to submit PoW shares to each other at high enough difficulty to reduce the cost of verification, but offer no guarantees to users (miners) that their lesser-difficultly shares cannot be censored, instead requiring them to switch between federation members to an honest one. This may be preferable to having each member run their own pool because it allows multiple entities to aggregate hashrate without putting trust in any single member. Solving bitcoin tx censorship isn't really a goal of Fedipool, except to the extent that giving miners privacy, harder to censor payouts, and the option of switching between members of a federation may help. |
Beta Was this translation helpful? Give feedback.
-
|
well said |
Beta Was this translation helpful? Give feedback.
-
No, you do not get "multisig security". LN payouts some pools already have. "ecash privacy" is nice, but the pool/share validator usually knows the physical location of your millions of dollars of hardware so...
But if miners can "detect this and switch between pools or federation members before losing too many shares" then they don't have any need for the "multisig pool" to begin with. You're not adding value, they can do this with pools today. In fact, its even more decentralized if you don't use a federation here! Again, I really struggle to see what value a "federated pool" is providing to anyone. It sounds really, really cool though! |
Beta Was this translation helpful? Give feedback.
-
|
Switching between pools is not momentary - it's always mean %% of share/delays looses because of deep hw CPU/GPU/ASIC miner construction, often most soft devs forget or ignore... |
Beta Was this translation helpful? Give feedback.
-
|
Ecash mints could be used to enable trustless mining by issuing ecash tokens for each hashrate share a miner submits. Tokens are non-transferable and can only be redeemed for bitcoin after the pool successfully mines a block. Since we do not allow tokens to be transferred we can use the block header hash as the "blinded secret" that the ecash mint signs, providing a provable link between each token and the hashrate share it is associated with. The mint would rotate the keyset used to sign these tokens every time a new block is mined. At the same time, the mint would produce a modified Proof of Liabilities report listing all mining shares issued for that epoch. Miners can cross-reference their submitted shares against the proof of liabilities report to ensure all of the shares they produced were included. Shares can't be "stolen" from the report because a valid ecash token requires not only a hashrate share which meets the pool difficulty target, but also a valid signature from the keyset used during that epoch. The mint is precluded from issuing unbacked ecash tokens because of the unforgeable costliness of producing a mining share. In this way every share is accounted for with every bitcoin block and cheating cannot go undetected. |
Beta Was this translation helpful? Give feedback.
-
|
This proposal is tangential to fedipool, but I didn't have a better place to put it. If there is sufficient interest, an ecash-dev mailing list would solve this problem and perhaps enable greater dialogue between the fedimint and cashu projects. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure I see why hashrate shares would need to be blind-signed, they could simply be redeemed for an amount of ecash dictated by the reward algorithm (whether PPS or PPLNS). Tying shares directly to a block could create unacceptable reward variance for miners. As you mention, the shares already contain the PoW so they are unforgeable, proof of ownership (e.g. a miner-generated pubkey) could be included in the block header mined. As far as proof-of-liabilities, this is a problem with ecash in general and key rotations are more difficult given the trust/liveness assumptions of a federation. Improvements in ZKPs are probably the only way we will get privacy + auditability in fedimint. |
Beta Was this translation helpful? Give feedback.
-
|
I was not suggesting blind-signed shares, the pool would need to validate the shares so there is no point to blinding them. I was suggesting the pool return a signature per share it receives as a means to keep the pool honest. I guess this is not really ecash, but it is inspired by ecash and can benefit from the same auditing scheme.
This does not enable the miner to prove that the pool received the share, which is what this scheme is intended for.
Aren't shares already strongly linked to a particular block via the block header that is being hashed? I was picturing PPLNS but a pool could use any payout scheme they want. PPLNS is cleaner in that all outstanding shares are paid out for every block the pool produces, but reward variance is higher for miners. PPS offers more consistent payout for miners at the cost of greater payout variance for the pool itself. I would expect PPLNS to be more popular with smaller pools, which is the decentralized mining future I would like to see.
Are you saying this makes Calle's (zkp-free) proof of liabilities scheme untenable for a federation? Can you please elaborate? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I think you have struck on the weak point of this proposal. This extra work can be mitigated by adding some compute hardware to verify signatures in between the miner ASICs and the network.
Again, this reintroduces a trust assumption. |
Beta Was this translation helpful? Give feedback.
-
I see, is that supposed to help with censorship? What prevents a pool from refusing to sign a share?
Usually shares would need to be ordered against each other as PPLNS can span multiple blocks.
Since we need all nodes to be cooperate to generate threshold keys, it breaks our trust assumption that only >2/3s of peers are live/honest. Also running distributed key gen can take several seconds to complete. |
Beta Was this translation helpful? Give feedback.
-
It is a way to assure the miners that they are being paid fairly for the work they contribute without trusting the pool.
If you want to mine trustlessly and the pool doesn't sign your shares, mine with another pool.
No ordering is necessary with this scheme since all shares come with a signature. If the pool uses PPLNS then all shares signed with a key that was introduced after the last block the pool won are valid for this payout round.
My understanding (which might be flawed) was that DKG was run at the conception of a fedimint. Is it not possible to deterministically generate a list of keys during DKG and then simply have each federation member iterate to the next key in the list when the time comes for a new epoch? Furthermore, are threshold keys even necessary? If each federation member maintains a 1 of 1 private key to sign shares with I think the scheme still works. |
Beta Was this translation helpful? Give feedback.
-
|
Are there any open source mining pool repositories? The only one I found was https://bitbucket.org/ckolivas/ckpool-solo/src/v0.9.7/ Would be interested in researching how they work before attempting a POC for a Fedipool. |
Beta Was this translation helpful? Give feedback.
-
|
For future searchers: |
Beta Was this translation helpful? Give feedback.
-
|
Peter Todd and i worked on something a few years back "proof of hashrate"
which is similar to returning a signature per share.
The issue was you have to kind of gut stratum in order to make that work.
But now that pools are mostly open to these things nowadays it could still
work. Effectively what we did was inside of the share you just add one more
field and that is pretty much it.
I will try to dig up that code.
…On Wed, May 24, 2023 at 8:28 AM vnprc ***@***.***> wrote:
I was not suggesting blind-signed shares, the pool would need to validate
the shares so there is no point to blinding them. I was suggesting the pool
return a signature per share it receives as a means to keep the pool
honest. I guess this is not really ecash, but it is inspired by ecash and
can benefit from the same auditing scheme.
proof of ownership (e.g. a miner-generated pubkey) could be included in
the block header mined.
This does not enable the miner to prove that the pool received the share,
which is what this scheme is intended for.
Tying shares directly to a block could create unacceptable reward variance
for miners.
Aren't shares already strongly linked to a particular block via the block
header that is being hashed? I was picturing PPLNS but a pool could use any
payout scheme they want. PPLNS is cleaner in that all outstanding shares
are paid out for every block the pool produces, but reward variance is
higher for miners. PPS offers more consistent payout for miners at the cost
of greater payout variance for the pool itself. I would expect PPLNS to be
more popular with smaller pools, which is the decentralized mining future I
would like to see.
key rotations are more difficult given the trust/liveness assumptions of a
federation
Are you saying this makes Calle's (zkp-free) proof of liabilities scheme
untenable for a federation? Can you please elaborate?
—
Reply to this email directly, view it on GitHub
<#1504 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQDQZST2R5Y5E6R6MRLCIYDXHYEF7ANCNFSM6AAAAAAUFNHF64>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
https://delvingbitcoin.org/t/fedimint-overview-and-fedipool-theorizing/110/1 |
Beta Was this translation helpful? Give feedback.
-
|
for reference : https://github.com/blinkhash/foundation-v2-server https://github.com/benjamin-wilson/public-pool both .js implementations where public-pool BTC only |
Beta Was this translation helpful? Give feedback.
-
|
https://delvingbitcoin.org/t/ecash-tides-using-cashu-and-stratum-v2/870 |
Beta Was this translation helpful? Give feedback.
-
Currently Bitcoin mining is dominated by a few mining pools which usually act as temporary custodians for miners which could be replaced by "FediPools".
Advantages for Miners
Sketch of implementation
Beta Was this translation helpful? Give feedback.
All reactions