-
theking[m]1
As an alternative to accumulating payments, is there to get more consistent awards if you make the difficulty higher (i.e. not geometrically distribution times X monero)?
-
theking[m]1
For example, what if the software automatically lowered the difficulty each time you failed. This results in lower rewards but at a faster and importantly more consistent rate.
-
theking[m]1
The question though is if the higher consistency in payout rate outweighs the inconsistency in payout time. (Of course the average payout is still just a function of hash power; the only question is variance of some sort.)
-
theking[m]1
* is there a way to get
-
theking[m]1
* As an alternative to accumulating payments, is there a way to get more consistent awards if you make the difficulty higher (i.e. not geometric distribution times X monero)?
-
theking[m]1
For example, what if the software automatically lowered the difficulty each time you failed. This results in lower rewards but at a faster and importantly more consistent rate.
-
theking[m]1
The question though is if the higher consistency in payout rate outweighs the inconsistency in payout time. (Of course the average payout is still just a function of hash power; the only question is variance of some sort.)
-
theking[m]1
-
jberman[m]
Smaller miners would still get payouts in small outputs in each block p2pool finds, which is the crux of the issue, ya? I'm not seeing how the above approach gets around that
-
jberman[m]
Here's a protocol that I think could enable accumulated payments for p2pool miners across blocks using multisig, but also needs tx chaining + tombstone-style timelocks sech1
-
jberman[m]
- p2pool miners collaborate to construct a multisig address.... (full message at <
libera.ems.host/_matrix/media/v3/do…61882dc02ce36435cd8b644887149b48bd6>)
-
jberman[m]
child-pays-for-parent*
-
sech1
Isn't multisig vulnerable to sybil attacks? If multisig is M/N, a malicious miner could create M different addresses and empty the wallet at any time.
-
sech1
*could mine from M different addresses
-
sech1
each honest miner must know they're required to sign a tx, so it can only be N/N multisig
-
sech1
but then miners going offline is a problem
-
jberman[m]
Right. Worst case there is payout is delayed X blocks
-
jberman[m]
The multisig could be a collaboration between miners who know the others have been online a while already. But ya, it's a pretty pesky downside nonetheless
-
ghostway[m]
Hmm, I don't understand this yet, but if the pool is large, you don't want to be dependent on another person you don't know? I imagine the response is that you wouldn't do this then
-
jberman[m]
It would be mutually advantageous to avoid fees from needing to consolidate outputs. The fees saved would need to outweigh the cost of a delayed payout that would occur some % of the time
-
ghostway[m]
I see, actually this makes it more decentralized too. Cool stuff!
-
jberman[m]
It's a bit of a fragile protocol I'd admit, but maybe someone can see a way to make it better
-
ghostway[m]
Yep
-
jberman[m]
The smaller the miner, the more beneficial it would be since fees spent consolidating outputs are a larger % of their reward
-
ghostway[m]
Yes, exactly, and that's why more and smaller groups of trusted peers will appear (I imagine)
-
DataHoarder
> 08:28:58 <ghostway[m]> Hmm, I don't understand this yet, but if the pool is large, you don't want to be dependent on another person you don't know? I imagine the response is that you wouldn't do this then
-
DataHoarder
you already depend on each other in p2pool, but you also everyone verifies each other continuously, not just towards their own shares, but everyone else getting the proper amounts as well