-
tevador
so, should we kill pools in the next hardfork? lol
-
tevador
-
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.
-
moneromooo
(since a large pool can act as several smaller ones)
-
gingeropolous
for some reason i think that a solo-only network might work once we move to the tail emission
-
hyc
there are plenty of miners who only mine because they get that steady income
-
moneromooo
PoW really is the reason for so much good and so much bad.
-
hyc
if they have to go solo, and maybe find a block once/year, they will go away
-
gingeropolous
i mean, hell, depending how things go, it might be that monero needs to move to a solo-only network
-
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
-
hyc
do the pools really move in that case? seems like it's just their miners
-
gingeropolous
at least with a solo-only network, the maximum damage done by a solo miner has some realistic limits
-
hyc
that switch around
-
gingeropolous
well, miners, pools. same difference.
-
gingeropolous
the point is that only with pools on the network can you get 20%+ hr swings
-
hyc
what if all pools are using miner-selected block templates?
-
gingeropolous
probably less so because miners need to run nodes
-
gingeropolous
though i fear that the miner-selected block templates is gonna not live up to its promise. people will just use remote nodes
-
hyc
remote latency may discourage that
-
gingeropolous
true
-
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
-
hyc
so far pools let them maximize the former, but nobody is focusing on the latter
-
gingeropolous
i dreamt up some scheme to make it so that "owning" a block had value, but i dunno if that will really work
-
gingeropolous
i.e., if you can prove that you are responsible for mining a block
-
gingeropolous
but i think that would require multiple hops on the lilly pads
-
gingeropolous
i really think a solo network would work. its just the transition would suck
-
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
-
gingeropolous
satoshi could've anticipated pooled mining and included some block signing whatsamajiggy in bitcoin
-
gingeropolous
but he didn't
-
gingeropolous
and so we're now stuck with this notion that you need to get immediately rewarded for supporting the network
-
hyc
immediately vs delayed reward?
-
hyc
I'm sure immediate gratification was an easiersell
-
hyc
what would delayed gratification accomplish?
-
hyc
you could put an explicit N-block lock delay on the coinbase txn. what would be the point?
-
tevador
IIRC bitcoin already has a 100-block lock on the coinbase tx
-
hyc
so basically no impact on pool operation
-
jwinterm
tevador, what do you think about the idea of making some part of the big scratchpad of randomx part of the blockchain
-
jwinterm
and everytime the miner changes the nonce, the 1 MB piece of the blockchain that is required would change
-
jwinterm
so each hash requires a lookup on the full blockchain
-
jwinterm
so pools could still exist, but each miner would be forced to run a full node
-
tevador
that won't work, the blockchain is too big to fit in RAM
-
jwinterm
even with lmdb and ssd too slow?
-
jwinterm
I guess then if someone had a bigass server with 128 GB of ram they could kick everyone else's ass?
-
jwinterm
what if each hash resulted in a lookup from only the last 4 gb of blockchain
-
jwinterm
or something?
-
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?
-
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
-
jwinterm
since the chunk wouldn't change with each hash
-
jwinterm
right?
-
tevador
a better idea would be to make the dataset from part of the blockchain
-
jwinterm
that's what I meant
-
jwinterm
I think
-
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
-
selsta
so there’s an incentive for solo mining without killing pools completely
-
tevador
jwinterm: the dataset changes once per ~3 days, not every nonce like the scratchpad
-
jwinterm
oic
-
tevador
so every ~3 days, youd grab some random parts of the blockchain and keep that in RAM
-
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
-
tevador
I guess that might work
-
jwinterm
which was from the blockchain
-
jwinterm
I think that is proven by boolberry not to kill pools, unless you use a very large dataset I think
-
jwinterm
I guess if the dataset was GBs maybe
-
tevador
selsta: not sure if the incentive would be big enough to matter, small miners would still go months without a reward
-
jwinterm
you can also still have trusted mining pools that way
-
jwinterm
which maybe not a bad thing
-
jwinterm
at least get rid of mega/profit-switching pools
-
jwinterm
trusted mining pools where all miners have a copy of the coinbase key
-
sech1
btw botnets will be effectively gone with block template signing
-
sech1
catch one infected PC -> extract private key -> profit
-
jwinterm
tru
-
sech1
as well as all small miners, only big solo miners will survive
-
sech1
probably less than a 1000 miners overall
-
sech1
not good for adoption
-
jwinterm
I wonder who the biggest non-botnet solo miner of monero is
-
jwinterm
asymptotically apparenlty has like 10 Mh/s
-
jwinterm
or just non-botnet miner, solo or pool miner
-
sech1
-
sech1
10 MH/s maybe
-
sech1
I don't see any big solo miners outside pools, pool hashrates match network difficulty
-
tevador
one 3900X takes on average 100 days to find a block, which is not too bad I guess
-
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
-
jtgrassie
selsta: I like the idea of rewarding the miner that mined a block to a pool with self-select
-
UkoeHB_
what is self-select?
-
jtgrassie
miner selected block templates
-
jtgrassie
-
jtgrassie
a pool can incentivize miners to use the mode by giving a greater portion of the reward.
-
UkoeHB_
oh interesting
-
selsta
but what if people just go to pools that don’t have this?
-
jtgrassie
indeed that's still a concern
-
jtgrassie
increased self-select usage removes a lot of the pain points with large pools though.
-
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.
-
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
-
tevador
miners don't get block templates, only the header
-
tevador
so the best you can do is to check the hash of the previous block I guess
-
UkoeHB_
ah with the merkle root? makes sense
-
UkoeHB_
checking the previous block id is probably enough anyway, since to double spend you have to rewrite older blocks
-
UkoeHB_
and to selfish mine you have to make side chains
-
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
-
UkoeHB_
to maintain their reputation, pools would be incentivized to maintain compliance through every software update
-
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
-
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
-
UkoeHB_
of course, getting certified entails some costs, but since certificates only mean anything for large pools I believe the incentives are well structured
-
UkoeHB_
and the certificate would be a digital signature on the mining software checksum issued by the audit group