00:15:45 <wernervasquez[m]> Are there any projects which integrate pool mining directly into their protocol?
00:39:36 <crypto_grampy[m]> <sech1> "monerod is a more appropriate..." <- I actually really like this idea.  It makes it vastly easier for anyone to develop a UI whereas a bunch of effort to add it into the GUI only gives us one implementation.  
00:42:01 <crypto_grampy[m]> So add to monerod first, then add to GUI via monerod 
01:07:17 <hyc> add what, to monerod? a miner that can mine against p2pool?
01:22:49 <merope> no, add p2pool itself, so that it can be easily launched even by non-technical users
08:56:08 <mj-xmr[m]> > <@rucknium:monero.social> And there is now a 25 XMR bounty for writing code integrating p2pool into the Monero GUI wallet. Any takers?
08:56:08 <mj-xmr[m]> > https://bounties.monero.social/posts/53/integrate-p2pool-mining-into-monero-gui-wallet
08:56:08 <mj-xmr[m]> Thanks. My current proposal wears off at the end of January. If there are no takers until then, I could handle it. 
08:56:17 <mj-xmr[m]> But if there are: just go ahead.
08:56:25 <localmonero05> Nice.
08:57:30 <mj-xmr[m]> Ah. There's already a PR :)
08:57:48 <sech1> mj-xmr I'm not taking that bounty, but I can add more stuff to p2pool code to make integration easier
08:59:20 <localmonero05> Good point by selsta. https://github.com/monero-project/monero-gui/pull/3829#issuecomment-1018191461
08:59:21 <mj-xmr[m]> That's nice. Let's talk in Feb. Perhaps this bounty is no more by that time anyway.
13:51:38 <wernervasquez[m]> I have a mad idea. Allow aggregate PoW so that any miner, however small, has a chance to contribute and get rewarded straight from the chain.
13:52:55 <wernervasquez[m]> Suppose we allowed up to 32 proofs of work to be associated with a block. Such that the sum of the work met the target toughness.
13:54:00 <wernervasquez[m]> I do not believe this would substabtially increase block size. But it would increase block time reliability.
13:56:11 <wernervasquez[m]> The reward structure could be such that there is no relative benefit to making a smaller contribution to keep miners preferring one size over another. 
13:59:05 <wernervasquez[m]> In the simplest case, imagine two miners that have found nonces that are just short of the target. These two PoWs could both be associated with the block. The block is published as enough work has been done.
13:59:56 <merope> How would you distribute the block reward though? Those 32 proofs are not going to be found at the same time. How would you prevent a faster miner from witholding a block until they've found all 32 proofs for themselves?
14:00:28 <merope> Also, pow hashes are not additive (at least as far as I know?)
14:01:19 <wernervasquez[m]> To your second point, I dont think we should care. If someone has done the work then so be it. But will they be faster than cooperative miners....probably not.
14:01:48 <merope> wernervasquez[m]: Each miner is working on a different block template though, and they would have to somehow share results in real time to know that both of them have found a nonce "close enough" to the final target
14:03:13 <wernervasquez[m]> regarding the additive nature of hashes, we would only be summing some abstract notion of work such that the total represents a given target.
14:04:40 <wernervasquez[m]> Regarding distribution, I have been thinking. Why do miners include the amount of their own reward if literally everyone verifies that it is correct anyway.
14:05:00 <atomfried[m]> given a set of workers which have done some work and to choose the right ones to meet a given target sounds a lot like the knappsack problem.
14:05:10 <atomfried[m]> atomfried[m]: nevermind ... ofc it is ok for them to overshoot the target of required work
14:05:27 <wernervasquez[m]> We only need to check that they spend the correct amount when they cash it in. Why do the work twice?
14:06:18 <atomfried[m]> no i meant from the perspective of the miner it could be not that trivial to find and select the other shares.
14:07:13 <wernervasquez[m]> So, I think we could establish a reward splitting algo that establishes how much each miner should be able to spend against a block they helped mine without including the amounts with the block explicitly.
14:08:03 <atomfried[m]> maybe this could lead to some kind of central mining server collecting all the shares and doing the work of collecting them together 
14:08:44 <wernervasquez[m]> So, a miner finds a partial PoW and puts the block and proof in pool like the tx pool
14:08:52 <merope> wernervasquez[m]: They "cash in" the reward the moment they publish the block, via the coinbase transaction
14:09:14 <wernervasquez[m]> Any other miner could start working on that block if they so chose.
14:11:40 <wernervasquez[m]> merope: suppose a miner mines a block and publishes his address but no reward amount. Later he spends the amount he should have received. The protocol finds the block he is spending against, calculates his reward, allows the tx if it verifies.
14:12:13 <wernervasquez[m]> Same if someone uses it as a decoy.
14:13:22 <wernervasquez[m]> Why calculate and publish in the chain a quantity which everyone both has the ability to calculate and already does so to check its validity
14:15:30 <Rucknium[m]1> wernervasquez: Xthinner from BCH is maybe relevant:
14:15:30 <Rucknium[m]1> https://news.bitcoin.com/xthinner-protocol-tested-on-bch-mainnet-shows-99-block-compression/
14:15:57 <merope> wernervasquez[m]: Because it changes the hash of the coinbase tx, and thus the whole block hash
14:16:11 <wernervasquez[m]> If the kinks of such a proposal could be worked out, theoretically , even the weakest individual miner could contribute to a block if they push the sum over the target.
14:16:59 <wernervasquez[m]> merope: Why include a value in the hash which everyone can calculate on their own?
14:17:07 <hyc> wernervasquez[m]: what are you attempting to save?
14:17:27 <hyc> the value isn't there by itself. the coinbase txn amount includes both the emission and sum of txn fees
14:17:47 <hyc> removing the emission value doesn't save any space, the coinbase txn still needs to be there
14:18:32 <merope> Because without the inclusion of the coinbase tx in the merkle root, anyone could rewrite the coinbase tx and steal the reward
14:18:54 <hyc> anyway, this overall proposal doesn't seem to offer any advantage over p2pool, while severely weakening a lot of integrity guarantees
14:20:47 <merope> hyc: just brainstorming an idea, no need to shoot it down a priori just because it's incomplete
14:21:00 <wernervasquez[m]> merope: Let me make sure I understand. Currently, does a miner include both his address and his reward in a block and thus its hash?
14:21:32 <wernervasquez[m]> If so, why not just include the address? What does putting the amount in accomplish?
14:21:49 <merope> Not the address per se, but yes
14:22:09 <hyc> merope: better not to waste time on obviously bad ideas.
14:22:14 <atomfried[m]> > <@rucknium:monero.social> wernervasquez: Xthinner from BCH is maybe relevant:
14:22:14 <atomfried[m]> > https://news.bitcoin.com/xthinner-protocol-tested-on-bch-mainnet-shows-99-block-compression/
14:22:14 <atomfried[m]> does monero have something like xthinner currently?Rucknium 
14:22:20 <wernervasquez[m]> well, the output publickey or whatever the technical term is
14:23:27 <merope> hyc: then don't chime in if you have nothing to contribute :)
14:23:50 <hyc> merope: saving time is a contribution. 
14:24:11 <hyc> and people who don't know wtf they're talking about aren't actually contributing anything
14:24:41 <wernervasquez[m]> hyc: Tell me how you really feel :P
14:25:09 <Rucknium[m]1> atomfried: I don't know. I don't think so. Someone else would know.
14:25:12 <hyc> wernervasquez[m]: if you're asking about what is contained in the coinbase txn, then you should have done your homework before suggesting changes
14:25:22 <hyc> only fools try to change a system before they understand how it currently works
14:25:24 <merope> Good learning opportunity though. And who knows, maybe they might come up with something new
14:25:35 <wernervasquez[m]> hyc: Do you have a specific criticism which I can take back to the drawing board?
14:25:47 <hyc> a good learning opportunity requires doing the homework first.
14:26:09 <hyc> \as I already said - you're not saving any space by removing the emission value. so what do you actually hope to accomplish?
14:26:30 <wernervasquez[m]> hyc: It is not foolish to ask questions, which is what I have done. Not making a PR here...
14:26:52 <hyc> also you make it more difficult to analyze individual blocks. i.e., given a block ID, we need only inspect that block to see its coins.
14:27:26 <hyc> with your proposal, any time anyone wants to inspect one block, they must always do a complete sume from block 0 to that block ID to know what the expected emission amount is
14:27:56 <hyc> again, my words were quite specific. it is foolish to *suggest changes* to a system before you understand how it currently works.
14:28:16 <hyc> asking questions is one thing. but you're going beyond that.\
14:28:23 <localmonero05> Jesus christ...
14:29:11 <hyc> so - what do you hope to gain, for all of the cost you'll impose on how the blockchain gets used?
14:31:10 <wernervasquez[m]> hyc: I respect you a lot and think you are very smart. I can handle your blunt dismissiveness. But you may turn away others who could grow into something with such coarseness.
14:31:21 <localmonero05> +1
14:32:00 <hyc> if you really believe it's too much to ask that everyone participating in a reseaarch discussion already understand how things currently work, then I have bad news for you
14:32:26 <hyc> that's now how anybody gets work done.
14:32:43 <merope> You know, some people learn more by asking questions about stuff they don't know to people who do know
14:32:44 <hyc> s/now/not/
14:33:42 <merope> And if your time is too precious to answer them, then nobody stops you from not replying (thus saving more of your valuable time)
14:33:51 <wernervasquez[m]> hyc: I like you. Chatting in a quiet channel, on topic, is not a problem.
14:34:22 <hyc> merope: this is not a question: (09:07:13) wernervasquez[m]: So, I think we could establish a reward splitting algo that establishes how much each miner should be ab
14:34:23 <hyc>  le to spend against a block they helped mine without including the amounts with the block explicitly.
14:34:36 <wernervasquez[m]> hyc: I really do respect you and intellect.
14:35:53 <wernervasquez[m]> hyc: You have provided me with at least one, thoughtful, specifc point to ponder. Which I will go and do.
14:36:28 <hyc> there's plenty more. miners aren't required to use the entire block emission in the block they mine.
14:36:43 <hyc> i.e., the emission per block isn't actually a fixed/predetermined value.
14:37:05 <hyc> a miner can choose to underpay themself, and then a future block can include the unspent excess
14:37:38 <sech1> they could before, but now they're forced to get the full block reward
14:37:47 <merope> Not anymore
14:38:48 <UkoeHB> 8:23 AM <hyc> merope: saving time is a contribution.
14:39:07 <UkoeHB> Speak for yourself... wtf is this patronizing thing?
14:40:00 <hyc> still haven't explained what they hoped to gain.
14:40:35 <hyc> and why it's better than just using p2pool
14:40:49 <localmonero05> Someone types a little wall text with an idea, couple questions, in a research channel and they get mauled by another wall text of patronizing, abrasive, shut-it-down comebacks.
14:40:54 <merope> "I have a mad idea. Allow aggregate PoW so that any miner, however small, has a chance to contribute and get rewarded straight from the chain."
14:40:56 <localmonero05> 4 people call you out and you keep doubling down on it?
14:40:58 <localmonero05> Really?
14:41:11 <merope> That was the initial premise
14:41:33 <hyc> p2pool already rewards miners straight from the chain
14:41:35 <localmonero05> Sorry a genuine proposal, or rather question, upsets you so much.
14:42:27 <merope> But p2pool still follows the "traditional" pow method, where a single hash above the target wins, and all other hashes are wasted
14:43:12 <merope> wernervasquez's idea is that multiple below-target hashes could be aggregated in some way to find a block
14:43:18 <hyc> they're not wasted. shares are accumulated and determine proportion of payout
14:43:56 <merope> 1 - that's a p2pool-specific thing
14:44:04 <merope> 2 - p2pool itself, under the hood, still follows that method
14:44:06 <merope> Oooooh
14:44:24 <hyc> yes that's a p2pool-specific thing, but it already exists and works
14:44:34 <hyc> and doesn't have an arbitrary 32-payee limit
14:44:45 <merope> But p2pool is still based on the premise of pool mining
14:45:45 <hyc> I don't see the relevance of that comment
14:45:57 <hyc> miners form their own blocks
14:46:11 <merope> What if each miner can individually combine their own hashes (without sharing them with others), and use the combined work to claim a block? This could significantly reduce the effect of variance, which combined with the nonce-signing proposal would make solo-mining slightly more tolerable to small miners
14:46:28 <merope> ^ see? Research questions!
14:46:45 <hyc> ... and how will they do that?
14:47:03 <hyc> gee, maybe they will pool their work so they can tally up how close to the target they've gotten
14:47:35 <merope> If the diff is 100 and I find two shares worth 50, they go to waste in the current system
14:47:42 <atomfried[m]> imo the combination of the work of the single miners would again be solved by a centraliced mining pool which then would just give more power to them.
14:47:53 <hyc> ^ exactly
14:47:57 <merope> But with a "cumulative pow" I could submit those two shares to claim a blocm
14:48:34 <merope> atomfried: hence the second part: combining the cumulative work with the nonce signing (which forces solo mining)
14:48:57 <wernervasquez[m]> <hyc> "with your proposal, any time..." <- Doesnt everyone already recalculate the miner reward to accept the block? Why does it matter if that calculation is done at the time of block publishing, or at the time of reward spending? Worst case, anyone who cares calculates the reward at the time the block is mined and store it in an off chain database for future reference.
14:49:08 <merope> (Doesn't completely fix the issue of leaving small miners at a disadvantage, but it's less bad)
14:50:33 <atomfried[m]> merope: would then the monero nodes perform the combination to a full block? what happens if two nodes with different shares of small miners combine a different block from different work pieces
14:51:36 <wernervasquez[m]> atomfried[m]: What happens if two nodes choose competing blocks now?
14:52:12 <hyc> highest pow wins
14:52:28 <hyc> but you're introducing a new pool that nodes must maintain, in addition to current txpool
14:53:06 <hyc> p2pool does the same work, but tracks it on its own sidechain that monerod doesn't need to worry about
14:53:14 <merope> atomfried[m]: Instead of verifying a single nonce and checking against target, it would verify both my nonces and check that their sum meets target. Still subject to the rule of highest cumulative pow
14:53:56 <hyc> whatever you do will require new bookkeeping
14:54:21 <merope> No new pool in my idea. Instead of having a single nonce in the block header, a miner can optionally include up to N (where N is limited by the protocol)
14:54:48 <merope> So the only extra recordkeeping would be a few extra bytes for each additional 32-bit nonce
14:55:21 <hyc> so for an incoming block all nodes will have to perform N pow verifications instead of just 1
14:55:39 <merope> Yes, as I've already mentioned
14:55:55 <hyc> that seems like an anti-scalability feature
14:56:15 <merope> But I suspect even N=2 or N=4 would have a pretty significant improvement on variance 
14:57:16 <merope> And if I'm not mistaken, pow verification is only a small part of block verification. Checking the validity of all txes takes longer (and the bigger the blocks, the more prevalent tx verification becomes)
14:57:20 <atomfried[m]> merope: could nonce signing lead to custodian mining pools where they pre sign a huge number nonces with their key and the miners need to use only those?
14:57:56 <merope> atomfried[m]: I think you're the first one to ask that question...
14:58:21 <atomfried[m]> merope: i guess thats a bad thing ...
14:58:52 <merope> But I don't think it would, because the pool would have to redo all the signatures for each new block header (ie a new block, or a tx gets added to the current block)
14:59:21 <merope> Which would require pretty significant computational resources
14:59:57 <merope> (I think I read a comment somewhere about the potential asics for that signing part?)
15:00:17 <atomfried[m]> ah ok so not only the nonce is signed but also the new block header
15:00:43 <merope> From what I recall, yes
15:01:32 <atomfried[m]> tbh i just heard about this nonce signing thing about half an hour ago, so i have not fully understand or reasearched it
15:01:48 <hyc> that's what wownero is doing now?
15:02:14 <merope> Yes: https://git.wownero.com/wownero/wownero/pulls/369
15:02:44 <atomfried[m]> the pr is closed or am i wrong?
15:02:53 <hyc> it's been in effect for a while
15:03:02 <atomfried[m]> ah ok
15:04:38 <sech1> aggregate pow requires all shares to be checked during block validation, this is too slow
15:04:53 <sech1> RandomX validation takes 0.01 seconds already
15:05:17 <hyc> yeah, this proposal will make for easy DOS attacks
15:05:23 <wernervasquez[m]> <merope> "No new pool in my idea. Instead..." <- I think that is a better idea than what I was thinking. It is a much simpler change which retains the benefit of reduced variance.
15:07:00 <merope> Would taking 0.02 or 0.04 seconds be so bad, relative to the benefit of decreased miner variance?
15:07:49 <merope> Re: DOS attacks - if a node gets caught sending "too many" invalid blocks, it gets banned
15:08:50 <merope> And the "too many" threshold can be tuned to be N out of the last M blocks, such that even a large swarm of malicious nodes could only add, say, less than 10% extra work for the whole network overall
15:11:10 <sech1> p2pool gives decreased miner variance, by the factor of 500x and it doesn't burden block validation for the rest of time (every syncing node will have to verify all PoW shares)
15:16:03 <hyc> this proposal would kick all pi nodes off the network.
15:16:50 <sech1> I remember we had to reduce RandomX dataset size from 4 GB to 2 GB just because of this (validation time)
15:17:01 <merope> Yes, the nonce signing proposal (as implemented by wownero) is very bad for small miners - I already delved into that yesterday
15:17:26 <wernervasquez[m]> <sech1> "p2pool gives decreased miner..." <- Is a further decrease not beneficial? p2pool would lower the variance even more leveraging such a change.
15:18:47 <sech1> p2pool is configurable, it can lower the variance even more but then individual payouts would be too little (network fees would eat a significant % when moving mined coins)
15:19:04 <hyc> new node operators would not thank you for increasing validation cost
15:19:12 <sech1> right now network fee is ~0.8% when you move a single smallest p2pool payout
15:19:16 <wernervasquez[m]> hyc: Obviously a concern, but what is your personal threshold when you stop worrying about old hardware. sbc's get faster like everything else.
15:20:15 <hyc> I'm already assuming hardware advances. it's not about old hardware.
15:21:22 <hyc> it's about ubiquitous hardware. whatever the lowest threshold is 5-10 years from now should not be a smaller set than it is today.
15:21:36 <merope> Of course it's a tradeoff. We are trying to establish if it's a worthwhile one
15:22:01 <merope> (And possibly quantify that)
15:23:35 <merope> Perhaps it could be tested on wownero, and see the effects that it hash on nethash?
15:24:33 <Rucknium[m]1> Our diagnosis of the problem is: It's too easy for noob miners to point xmrig to the first Google result for a pool (minexmr)? About to give a controversial and maybe unworkable idea...
15:25:46 <merope> prepares popcorn
15:25:58 * hyc prepares salt
15:26:02 <Rucknium[m]1> It feel like some of these proposals are dealing with the problem in a quite indirect way. Instead, maybe xmrig devs issue an ultimatum to minexmr: temporarily increase your fee (which would reduce number of miners) or the new compiled versions of xmrig don't allow mining to your domain.
15:26:28 <hyc> a bit draconian
15:26:45 <hyc> a better idea would be for xmrig to poll a list of pools e.g. from miningpoolstats and ping them
15:26:53 <hyc> then choose the one with the lowest hashrate and fastest ping time
15:27:36 <hyc> or if not lowest hashrate, <moderate> hashrate, excluding the highest. 
15:27:40 <merope> But then you'd be relying on whatever centralized resources provides the nethash numbers to be true 
15:28:15 <merope> Maybe not outright stop miners, but it should spam a big letter warning to move to smaller pools
15:28:27 <merope> The problem is that minexmr has a lot of (pre-existing) botnets
15:28:38 <rbrunner> I somehow pity minexmr: You put up a top-quality mining pool, always serve your "customers" well, be stable and trustworthy, and so on, and as a "thank you" the community ponders nuclear options like this ...
15:28:42 <merope> And botnets don't give a fuck
15:28:44 <sech1> at least 1/3 of their hashrate are a few big botnets
15:28:52 <sech1> minexmr just needs to ban they so they'd move elsewhere
15:28:59 <merope> And neither does the minexmr admin very much
15:29:27 <crypto_grampy[m]> Rucknium[m]1: I think things like nicehash or Norton antivirus cryptominer that may have default/hardcoded pools are a bigger and more likely problem than people googling pools and finding minexmr.  
15:29:58 <hyc> norton is relatively new, and only on eth
15:30:00 <crypto_grampy[m]> Bigger problem**
15:30:33 <Rucknium[m]1> Isn't it possible for there to be an independent measurement of pool hashpower by mining to a bunch of pools and observing payouts to your miner?
15:30:58 <crypto_grampy[m]> Yes, but it's just a matter of time and very likely that some corporate bobble head finds out ASIC resistant algos are a thing and plops a minexmr in the app
15:31:07 <hyc> ... we can setup another sidechain where miners report their observed hashrates
15:32:00 <Rucknium[m]1> rbrunner: minexmr knew what the game was when they entered. Get too much hashpower on a PoW coin, and a target forms on your back.
15:32:23 <sech1> pools even DDoSed each other in the early days
15:32:46 <merope> Rucknium[m]1: Iirc moneroocean does that. Or maybe some other pool, don't recall 
15:32:48 <sech1> any big botnet miner can ddos minexmr to boost their profits for a while
15:33:00 <sech1> https://moneroocean.stream/profits/
15:33:33 <merope> There's a page somewhere which lists the income vs expected income on a bunch of different pools, using a few small workers
15:33:54 <merope> But still, it's a centralized resource 
15:34:36 <hyc> right, so use a blockchain instead. a sidechain...
15:35:31 <hyc> although not even sure that's needed.
15:36:07 <hyc> pool blocks are all identifiable, so a miner just has to read the last N blocks of the mainchain and see which pools are dominant
15:37:33 <rbrunner> Rucknium[m]1: Sure. Something like a business that works so well as to achieve a monopoly and then getting shot down by corresponding laws. Still a little paradoxical, punished for being too good, right?
15:37:48 <sech1> monopoly is not good
15:37:56 <sech1> especially in blockchain :D
15:38:26 <hyc> rbrunner: https://twitter.com/hyc_symas/status/1316389016959438855
15:38:57 <rbrunner> Lol
15:43:55 <hyc> how would a pool info blockchain work... have all miners broadcast the domain/ip addr of the pool they're using, sum the counts up into blocks?
15:47:40 <hyc> decentralizing the ledger is easy enough. how do you validate it? what's a possible proof-of-pool algorithm?
15:58:49 <fluffypony> hyc: but then Monero would be a public utility, because it's >80% of private cryptocurrency transactions worldwide :-P
15:59:03 <hyc> lol
15:59:20 <hyc> but we're not a corporation
16:00:29 <hyc> are we sure new miners are actually googling to find a pool to join? why not just hardcode xmrig to default to pointing at p2pool in the first place
16:01:06 <nioc> because you need a synced blockchain
16:01:47 <hyc> wallets already know how to find public nodes
16:02:07 <nioc> hmmm
16:02:51 <merope> And a running p2pool
16:03:39 <hyc> starting p2pool up from scratch only takes some tens of seconds
16:04:05 <merope> And yes, lots of miners just join the first pool they find. Plus a lot of incomplete or outright bad info, so many end up joining minexmr because it sits at the top of the pool list
16:04:39 <merope> I've encountered multiple people that thought bigger pool == better
16:05:01 <merope> Once you know the startup flags, sure
16:05:22 <nioc> big pools = less variance which actually matters with a decreasing block reward  
16:05:22 <atomfried[m]> does using p2pool requires running a full p2pool node or could there be an electrum equivalent for p2pool?
16:05:35 <merope> But non-technical users who barely know what a wallet is have a very steep learning curve when they first start
16:06:16 <hyc> even so, it's easier to wrap the startup procedure than design all this other stuff
16:06:20 <merope> atomfried: you have to pass your wallet address as a parameter when starting p2pool
16:06:39 <merope> And that p2pool instance will only mine for you
16:07:25 <merope> Hence the cureent 25 XMR bounty to integrate p2pool into the official software
16:07:43 <hyc> so. newbie installs GUI wallet. wallet selects a public node automatically
16:08:09 <merope> nioc: the decreasing block reward affects everyone the same way though, regardless of the pool size
16:08:19 <hyc> wallet now has a public node address and a wallet address, which is sufficient info to give to p2pool
16:09:10 <merope> Doesn't p2pool requre unrestricted rpc access though?
16:09:14 <hyc> no
16:09:25 <hyc> it only does if you want it to use monerod for pow validation
16:09:34 <merope> For when p2pool asks for a block template
16:09:50 <hyc> which only makes sense when you're running monerod on same box as p2pool
16:09:54 <hyc> no, that's a public rpc
16:11:06 <nioc> merope: not as much now as the the block reward decreases very slowly now, someone did the math about a year and a half ago and it did make a difference 
16:11:34 <hyc> final steps: short xmrig benchmark run to get baseline hashrate. then start xmrig with fixed difficulty based on hashrate, so that p2pool gives meaningful statistics
16:12:01 <hyc> the latter might usefully be combined into one step in xmrig code itself
16:12:02 <nioc> depends on the difference between the pools, I was on one that found a block every month on avg
16:25:06 <hyc> i'm not sure the aggregate pow idea is actually beneficial. consider a small network with 2 miners. 1 has 1H/s and the other has 2H/s, and difficulty=4.
16:25:50 <hyc> while the smaller miner on its own would solve the PoW in the target time every time, the faster miner will usually solve it in one half of the target time
16:28:10 <hyc> forcing the difficulty to adjust higher, and basically locking the slower miner out from ever finding a solution
16:41:43 <hyc> basically, allowing an aggregate of N=2 pow hashes makes a faster miner's advantage over slower miners quadratic instead of linear
16:42:00 <hyc> and the advantage gets even greater with larger N
16:42:19 <hyc> so while you're trying to make mining results better for slower miners, you're actually killing them
17:07:02 <merope> The small miner still has roughly 25% chances of finding a valid hash in a single try, and some good chances of finding the result in two hashes (1+3, 2+2, 3+1)
17:17:19 <gingeropolous> minexmr didn't go from 37% to 42% to 37% because of noobs mining to the biggest pool methinks
17:18:50 <sech1> yes, they have several 100+ MH/s miners
17:31:24 <hyc> merope: the faster miner has even more chances though. more than 2x.
19:42:21 <gingeropolous> obvi just need to stop all the botnets
22:23:29 <dr_overdose[m]> <UkoeHB> "I have seen wernervasquez and dr..." <- I do have a mathematical background and a keen interest in protocol details but admittedly limited coding experience. I do happen to have quite a bit time right now, though. Perhaps I could be help