19:59:05 <tevador> so, should we kill pools in the next hardfork? lol
19:59:28 <tevador> https://github.com/wownero/meta/issues/28#issuecomment-631685564
20:05:19 <moneromooo> I used to think pools were always bad to some degree, but in fact if pools die it's likely some non trivial fraction of those pools' users won't switch to solo mining, they'll just leave. So what's really needed is a way to make pool advantages decrease with size. Which I really don't see being possible.
20:05:39 <moneromooo> (since a large pool can act as several smaller ones)
20:06:27 <gingeropolous> for some reason i think that a solo-only network might work once we move to the tail emission
20:06:49 <hyc> there are plenty of miners who only mine because they get that steady income
20:06:57 <moneromooo> PoW really is the reason for so much good and so much bad.
20:07:04 <hyc> if they have to go solo, and maybe find a block once/year, they will go away
20:07:06 <gingeropolous> i mean, hell, depending how things go, it might be that monero needs to move to a solo-only network
20:07:45 <gingeropolous> in the case of a monero value crash, the pools are gonna move away from monero... but any time theres a price spike, they'll hop back on and completely muck things up
20:08:17 <hyc> do the pools really move in that case? seems like it's just their miners
20:08:18 <gingeropolous> at least with a solo-only network, the maximum damage done by a solo miner has some realistic limits
20:08:23 <hyc> that switch around
20:08:44 <gingeropolous> well, miners, pools. same difference.
20:09:22 <gingeropolous> the point is that only with pools on the network can you get 20%+ hr swings
20:09:47 <hyc> what if all pools are using miner-selected block templates?
20:10:04 <gingeropolous> probably less so because miners need to run nodes
20:10:26 <gingeropolous> though i fear that the miner-selected block templates is gonna not live up to its promise. people will just use remote nodes
20:10:45 <hyc> remote latency may discourage that
20:10:53 <gingeropolous> true
20:12:30 <hyc> there must be a way to balance this out. a miner has incentive to get a share of as many other miners' blocks as possible, but also an incentive to share his own wins with as few others as possible
20:13:00 <hyc> so far pools let them maximize the former, but nobody is focusing on the latter
20:14:45 <gingeropolous> i dreamt up some scheme to make it so that "owning" a block had value, but i dunno if that will really work
20:14:57 <gingeropolous> i.e., if you can prove that you are responsible for mining a block
20:15:33 <gingeropolous> but i think that would require multiple hops on the lilly pads
20:20:03 <gingeropolous> i really think a solo network would work. its just the transition would suck
20:20:43 <gingeropolous> its the same problem with privacy on the blockchain. bitcoin came first and so everyone thinks the way that bitcoin got them to think
20:21:18 <gingeropolous> satoshi could've anticipated pooled mining and included some block signing whatsamajiggy in bitcoin
20:21:29 <gingeropolous> but he didn't
20:22:06 <gingeropolous> and so we're now stuck with this notion that you need to get immediately rewarded for supporting the network
20:25:16 <hyc> immediately vs delayed reward?
20:25:31 <hyc> I'm sure immediate gratification was an easiersell
20:27:04 <hyc> what would delayed gratification accomplish?
20:27:35 <hyc> you could put an explicit N-block lock delay on the coinbase txn. what would be the point?
20:47:08 <tevador> IIRC bitcoin already has a 100-block lock on the coinbase tx
21:01:09 <hyc> so basically no impact on pool operation
21:08:52 <jwinterm> tevador, what do you think about the idea of making some part of the big scratchpad of randomx part of the blockchain
21:09:16 <jwinterm> and everytime the miner changes the nonce, the 1 MB piece of the blockchain that is required would change
21:09:29 <jwinterm> so each hash requires a lookup on the full blockchain
21:10:34 <jwinterm> so pools could still exist, but each miner would be forced to run a full node
21:10:35 <tevador> that won't work, the blockchain is too big to fit in RAM
21:11:02 <jwinterm> even with lmdb and ssd too slow?
21:11:26 <jwinterm> I guess then if someone had a bigass server with 128 GB of ram they could kick everyone else's ass?
21:12:32 <jwinterm> what if each hash resulted in a lookup from only the last 4 gb of blockchain
21:12:34 <jwinterm> or something?
21:13:20 <asymptotically> would it be easier to concat the random blockchain junk with the block header instead of trying to put it into the hashing algo?
21:14:32 <jwinterm> I guess it might be easier, but then you'd have to use a bigger random piece of blockchain to prevent mining pools from sending out jobs
21:14:42 <jwinterm> since the chunk wouldn't change with each hash
21:14:43 <jwinterm> right?
21:17:19 <tevador> a better idea would be to make the dataset from part of the blockchain
21:17:55 <jwinterm> that's what I meant
21:17:57 <jwinterm> I think
21:18:17 <selsta> Might be a dumb idea but what if you allow pools but if someone does the template signing tevador described previously they get a bigger coinbase reward
21:19:17 <selsta> so there’s an incentive for solo mining without killing pools completely
21:19:25 <tevador> jwinterm: the dataset changes once per ~3 days, not every nonce like the scratchpad
21:19:55 <jwinterm> oic
21:20:13 <tevador> so every ~3 days, youd grab some random parts of the blockchain and keep that in RAM
21:20:22 <jwinterm> I think that is kind of how boolberry worked, and when you connected to a pool you'd have to download like an 80 MB dataset/scratchpad
21:20:22 <tevador> I guess that might work
21:20:27 <jwinterm> which was from the blockchain
21:20:56 <jwinterm> I think that is proven by boolberry not to kill pools, unless you use a very large dataset I think
21:21:48 <jwinterm> I guess if the dataset was GBs maybe
21:22:12 <tevador> selsta: not sure if the incentive would be big enough to matter, small miners would still go months without a reward
21:22:46 <jwinterm> you can also still have trusted mining pools that way
21:22:52 <jwinterm> which maybe not a bad thing
21:23:02 <jwinterm> at least get rid of mega/profit-switching pools
21:23:15 <jwinterm> trusted mining pools where all miners have a copy of the coinbase key
21:23:30 <sech1> btw botnets will be effectively gone with block template signing
21:23:52 <sech1> catch one infected PC -> extract private key -> profit
21:26:31 <jwinterm> tru
21:27:10 <sech1> as well as all small miners, only big solo miners will survive
21:27:18 <sech1> probably less than a 1000 miners overall
21:27:46 <sech1> not good for adoption
21:28:24 <jwinterm> I wonder who the biggest non-botnet solo miner of monero is
21:28:31 <jwinterm> asymptotically apparenlty has like 10 Mh/s
21:28:45 <jwinterm> or just non-botnet miner, solo or pool miner
21:30:46 <sech1> https://solo-xmr.2miners.com/miners
21:30:58 <sech1> 10 MH/s maybe
21:31:32 <sech1> I don't see any big solo miners outside pools, pool hashrates match network difficulty
21:40:05 <tevador> one 3900X takes on average 100 days to find a block, which is not too bad I guess
21:41:06 <sech1> actually, botnets are still possible - each PC will just use unique private key and send it to control center when it finds a block
21:41:11 <jtgrassie> selsta: I like the idea of rewarding the miner that mined a block to a pool with self-select
21:42:55 <UkoeHB_> what is self-select?
21:43:07 <jtgrassie> miner selected block templates
21:44:05 <jtgrassie> https://github.com/jtgrassie/monero-pool/blob/master/sss.md
21:46:07 <jtgrassie> a pool can incentivize miners to use the mode by giving a greater portion of the reward.
21:47:20 <UkoeHB_> oh interesting
21:48:27 <selsta> but what if people just go to pools that don’t have this?
21:48:46 <jtgrassie> indeed that's still a concern
21:50:40 <jtgrassie> increased self-select usage removes a lot of the pain points with large pools though.
21:52:33 <jtgrassie> there's no obvious fair way to reduce pool domininace, thus ideas that reduce the danger they pose is probably the best place to start.
21:55:49 <UkoeHB_> are there any node implementations that can monitor pools for suspicious behavior? e.g. parsing block templates, and checking the previous block ID is on-chain and that the key images are non-duplicate
22:00:23 <tevador> miners don't get block templates, only the header
22:00:44 <tevador> so the best you can do is to check the hash of the previous block I guess
22:01:32 <UkoeHB_> ah with the merkle root? makes sense
22:02:21 <UkoeHB_> checking the previous block id is probably enough anyway, since to double spend you have to rewrite older blocks
22:02:33 <UkoeHB_> and to selfish mine you have to make side chains
22:06:34 <UkoeHB_> could even have an 'honest pool compliant' certification for pools, where the miner software monitors headers it gets from the pool and checks against main-chain block IDs, and the software is only considered compliant if it automatically shuts down or issues big warnings when suspicious things happen
22:09:14 <UkoeHB_> to maintain their reputation, pools would be incentivized to maintain compliance through every software update
22:33:31 <tevador> that's not a bad idea, the miner could check for each job from the pool that the previous block has been propagated to the network after some short amount of time
22:36:47 <UkoeHB_> the biggest danger would be polling fake nodes set up by the pool to distribute non-main-chain IDs, but if an audit is required to get certified then that would just be one item on the checklist
22:37:25 <UkoeHB_> of course, getting certified entails some costs, but since certificates only mean anything for large pools I believe the incentives are well structured
22:42:51 <UkoeHB_> and the certificate would be a digital signature on the mining software checksum issued by the audit group