02:13:39 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)? 02:13:39 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. 02:13:39 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.) 02:16:31 * is there a way to get 02:16:51 * 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)? 02:16:52 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. 02:16:52 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.) 02:30:03 Let me do some quick math:... (full message at ) 03:14:44 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 04:05:11 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 04:05:28 - p2pool miners collaborate to construct a multisig address.... (full message at ) 04:07:36 child-pays-for-parent* 06:23:25 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. 06:23:38 *could mine from M different addresses 06:25:56 each honest miner must know they're required to sign a tx, so it can only be N/N multisig 06:26:07 but then miners going offline is a problem 07:20:03 Right. Worst case there is payout is delayed X blocks 07:20:22 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 07:28:58 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 07:31:59 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 07:32:46 I see, actually this makes it more decentralized too. Cool stuff! 07:35:38 It's a bit of a fragile protocol I'd admit, but maybe someone can see a way to make it better 07:36:44 Yep 09:09:46 The smaller the miner, the more beneficial it would be since fees spent consolidating outputs are a larger % of their reward 09:10:23 Yes, exactly, and that's why more and smaller groups of trusted peers will appear (I imagine) 14:49:59 > 08:28:58 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 14:50:38 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