<g​ingeropolous:monero.social> although that could be what qubic is doing already

<o​range_horizon:matrix.org> They look super expensive to run, like $30/hr

<g​ingeropolous:monero.social> ok, so there's 1 GH/s on MRR right now. that should pull in 85 xmr/day, $23072 (based on the calculator on miningpoolstats.stream). The first page of MRR has 850 Mh/s total for 0.012 BTC, so that comes to 1.438e-5 bitcoin/(MH) , so for 1 GH, 0.01438 bitcorns, so 1668$.

<g​ingeropolous:monero.social> well, that tail end of that 1 gh/s gets pretty expensive, 99 Kh/s for 0.32 bitcoin.

<g​ingeropolous:monero.social> well that same calculator spits out 19632.98 USD for 850 MH/s

<g​ingeropolous:monero.social> so in theory they would be making more if mining monero instead of being rented... (?)

<g​ingeropolous:monero.social> at 10 cents/kwh, using 700 watts for 90 kh/s, theres a $566.15 daily profit to just mine monero

<g​ingeropolous:monero.social> but wattomine is giving me a daily 60.6176 monero instead of 85, but that shouldn't be that drastic

<o​range_horizon:matrix.org> What is the purpose of this room? discuss mining?

<o​range_horizon:matrix.org> What is the purpose of this room? discuss mining? or RandomX technical?

As the name suggests it's proof of work algorithm and development of it in particular. The calculation discussion about recent network "movements".

<o​range_horizon:matrix.org> Thanks. I had a question re the variability in time taken to mine a block:

<o​range_horizon:matrix.org> is the variability seen as good or useful? And also are there any known ways to reduce it?

<o​range_horizon:matrix.org> I'm asking because I had some thoughts about 51% attack protections that seem broken because of the wide possibility of when a block can be found by any given miner.

The variability itself is not good.

However, it is a memoryless random process, so the variability follows.

Faster blocks would lessen variability in practice, through the law of large numbers.

Things like VDFs also would, though I'm unsure how that plays out with variability in users' hardware.

Having a memory also would.

It's a compromise between things we want and things we don't.

<o​range_horizon:matrix.org> is VDFs verifiable delay functions?

There's probably also a lot of rsearch on this in the Bitcoin world already.

Yes.

<o​range_horizon:matrix.org> ok, and is having a memory a drawback due to bandwidth and storage? or are there other issues with it?

Fairness. It would mean miners with the most hash rate would get all the blocks.

<o​range_horizon:matrix.org> Is there any where you know of that i could read up on that?

<o​range_horizon:matrix.org> I was thinking about some way to record individual identities PoW on the chain and have the miner with the most store PoW create the next block. by creating a block the identity 'spends' the PoW. That way even small miners will always get their turn. and for more frequent payouts small miners could pool. but because the PoW is recorded it can also be capped to prevent pools from getting too big.

That is kinda p2pool. You record you pow on the p2pool chain. Though the final block is shared and the "memory" is finite and short.

To incrementally record your pow for a better chance at a future block, you'd have to use up chain space repeatedly.

A lot of small miners would do...

Presumably, it also means verification would need to run a lot more randomx hashes for the "icremental pow proof" hashes in each block.

Though I suppose some magi^H^H^H^Hcrypto proof might be inserted here somehow.

<o​range_horizon:matrix.org> haha that's what I was thinking.

I have handy link for more though. Except ddg.com.

*no handy link

<o​range_horizon:matrix.org> I wondered if it would be fair for the nodes to keep a running tally of the miners PoW like an account so to speak. actually thinking about it I see that doesn't lessen the workload.

One additional complication is that a future user needs to verify a chain is valid.

So you can't discard stuff that is needed to determine validity.

That's where "somehow sign a given state as a new known valid starting point" ideas graft to.

<o​range_horizon:matrix.org> Thanks for the info, I'll go learn something.

<g​ingeropolous:monero.social> yeah to beat 30$ an hour you'd need 29 MH/s, which i doubt one of those AWS instance could do