<sgp_> I added more aggressive scaling examples: monero-project/research-lab #152#issuecomment-3461700149

<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1289

<rucknium> 1. Greetings

<articmine> Hi

<vtnerd> hi

<sgp_> hello

<hinto> hello

<jberman> waves

<jeffro256> Howdy

<rucknium> 2. Updates. What is everyone working on?

<rucknium> me: Looking at some changes in spy node behavior.

<vtnerd> working on a lws db/msgpack bug. unable to reproduce locally, so I may have to move on unfortunately

<jberman> Reviewed p2p SSL monero-project/monero #8996 (thank you @vtnerd:monero.social), continuing stressnet investigating / bug fixing (found and patched an issue in monerod where it over-counts pool weight in memory)

<vtnerd> oh yeah, updated that pr too! looking good hopefully

<articmine> I had to pause my scaling work to review this 10% scaling proposal

<articmine> I have not had a chance to look at the latest version

<rucknium> 3. Spy nodes monero-project/meta #1124

<jeffro256> Me: working on extending integration of Carrot devices and Carrot-derived account keys in wallet2

<jeffro256> The goal is for Carrot-derived wallets to be available before the beta stressnet

<jeffro256> As well as hybrid wallets

<rucknium> @boog900:monero.social noticed that the spy node test is showing some spy nodes as false negatives, starting about a week ago: moneronet.info

<jeffro256> They finally updated ;)

<jeffro256> Nice of them to wait until after the p2p selection improvements were reviewed and released

<rucknium> These nodes are still on the same IP addresses. About 100 in DigitalOcean and 100 in Hetzner.

<rucknium> The LionLink spy nodes have the same behavior as before.

<rucknium> The MRL ban list is still valid. The network should be monitored for "metastasizing" behavior of the spy nodes, i.e. new spy nodes without the peerID fingerprint

<rucknium> But, the spy nodes may still be detectable with other tests.

<rucknium> This recent paper monitors packet data: Kopyciok, Y., Schmid, S., & Victor, F. 2025. Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. moneroresearch.info/280

<rucknium> and finds a lot of anomalous behavior.

<rucknium> Their code is open source, so I could try to run it. They use regular passive Monero nodes to collect the data, so it won't be as fast or complete as the network crawler scan that moneronet.info uses.

<rucknium> AFAIK, @syntheticbird:monero.social discovered another way to deduce spy nodes.

<rucknium> I could push Core to change the DNS ban list to include more spy nodes: monero-project/meta #1242

<rucknium> IMHO, this issue ^ is mature and has had time for comments.

<rucknium> I set up moneronet.info because it shows pretty graphs and because it helps reveal changes in spy node behavior. It's doing its job 😁

<rucknium> Any more comments on spy nodes?

<sgp_> a picture says 1000 words, nice

<rucknium> 4. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero #44). Simple Market-Based Monero Fee Proposal (monero-project/research-lab #152).

<syntheticbird> Yes, but it isn't deterministic. Under some circumstances there could be false positives, but depending on some criteria we can limit them to probably zero. I'll need to go into some archives as librejo is now down and everything was collected on a private repository. > <@rucknium> AFAIK, @syntheticbird:monero.social discovered another way to deduce spy nodes.

<syntheticbird> s/deterministic/100% accurate

<rucknium> This discussion topic continues to be challenging. If there are suggestions about how to structure the discussion (especially in the future), please bring them :)

<articmine> As I mentioned before I do not have to report anything new since I believe that addressing this new 10% proposal is required

<sgp_> I added two more aggressive scaling examples to my proposal. My proposal aims to simplify scaling and fees. Other parameters can be chosen, so feel free to ask me for different numbers.

<sgp_> 10% is my suggestion and one example parameter, but any other value (e.g. 50%) can be chosen if desired. I included numbers for 25% and 50% this morning

<articmine> I agree that this topic is challenging primarily because of the sheer amount of fud and misinformation that has been imported from Bitcoin and related coins

<articmine> As for this 10 % proposal my preliminary assessment is that it is a complete disaster and also a serious breach of the Monero's can Cryptonote social covenants

<jberman> I think there are 2 core problems to solve on this front: 1) tx weight, and 2) scaling algo. Personally I would prefer to tackle the former first, and the latter second. They can be solved together in one pass, but I think we'd end up stuck in bikeshedding hell trying to

<articmine> @jberman: Actually the scaling algorithm need to be addressed first

<spackle> At present, Monero's scaling design gives no consideration to the capabilities of the daemon. Regardless of the path chosen, I believe this must change in the future.

<articmine> Since what we are ultimately dealing is fee incentives

<sgp_> My proposal works for any transaction weight calculation, so it would be fine to handle those separately from that perspective

<ofrnxmr> sorry fkr dragging off topic, but what is "weight" ? Is this just some made up concept that is a combination of various factors, but then given a value?

<ofrnxmr> (since its not the byte size on the tx, im not sure what its supposed to be)

<articmine> @sgp_: No it doesn't

weight can be calculated by number of elements, byte size, or estimated cost of verification etc.

<ofrnxmr> Monero seems to have weight and size used interchangeably throughout the codebase, but apparently they aren't the same thing

<jeffro256> @ofrnxmr: Yeah basically. The idea of "weight" is a value assigned to how much space a transaction should take up in a block, and thus indirectly, what ratio of fees it should pay compared to other txs

<jeffro256> @ofrnxmr: Yeah we love using inconsistent terminology in the codebase

<sgp_> weight = size + other relevant factors, whatever those are

<jberman> on current mainnet BP+ txs, weight is byte size,with exception to BP+ txs with >2 outputs, which add marginally larger weight for the BP+ clawback

<sgp_> monero used to use size until verification became more costly for some things than others, that's why it changed

<ofrnxmr> @jeffro256: ban & block 🥲

<jeffro256> But IIRC, weight was the same as byte size until the first BP fork

<ofrnxmr> Ok thanks

<sgp_> I don't have anything else to discuss from my end for this topic

<ofrnxmr> (this of note because sum of fcmp txs != advertised block size)

<articmine> @sgp_: Same here

<ofrnxmr> So the "1.4mb" block we see, only has like 800kb of txs. And a 130kb tx has a weight of like 700kb

<jberman> the core pushback on weight = roughly byte size for FCMP++ comes from @kayabanerve:monero.social, who argues this incentivizes larger txs over n broken up txs, to spend the same number of inputs

<jeffro256> @jberman: I agree with j-berman on his point to try to determine weight now

<jeffro256> And I also think it should be approx eq to byte size b/c of the arguments enumerated last week

<jberman> kayaba also expressed weight roughly = byte size would not be a blocker

<ofrnxmr> on the subject of scaling, im firmly against uniformity taking precedent over scaling. Scaling is more important than uniformity

<articmine> @jeffro256: I can do this based upon my proposed scaling

<jberman> I think the argument for weight roughly = byte size (simplicity, minimize byte size spending n inputs, minimize n outputs on the chain to spend n inputs), is sound enough to warrant the decision

<rucknium> Maybe someone should calculate how much developer labor costs it would take for the service that needs to do lots of consolidation txs to develop and deploy the ideal tx algorithm, compared to just accepting a little higher fee costs for suboptimal consolidation. And then compare the actual costs to node operators for storing those txs, in the two methods.

<jberman> I think participants today have rough consensus on weight roughly = byte size

<rucknium> I think the difference would not be large.

<articmine> @jberman: Yes

would pruned size (long term size for "small" nodes) be considered for weight?

<jberman> No

<jberman> @rucknium: Is this analysis required to come to rough consensus here in your view?

<rucknium> Has the discussion about tx weight concluded? (Or the minority voices been worn down enough to give up 😉 ?)

<rucknium> @jberman:monero.social: No. My point is that the points of contention are small details that don't matter much.

<jberman> Ya I agree with that as well

<jberman> > Or the minority voices been worn down enough to give up

<jberman> I think simplicity in design over tinkering with minutiae details is a huge plus here to move forward with

<rucknium> To continue ad absurdium, you could compute the labor cost to computing those figures, and then compute the cost to compute the ith, etc.

<rucknium> I doubt there would be a large empirical effect if one option were chosen compared to the other.

<jberman> Linear increasing fees was probably the main alternative, and then we end up stuck deciding how 1 input/output/extra should count toward the weight, and rehash similar arguments

<jberman> All this to say, I think there is strong merit in the simplicity of (and arguments for) weight roughly = byte size, such that the detracting views are not strong enough to warrant deviation from it imo

<rucknium> Lets move on to the next item. I will see if I can come up with more structure for the scaling discussion for next time. In the meantime, please feel free to share ideas for a structure.

<rucknium> 5. FCMP alpha stressnet. monero.town/post/6763165

<rucknium> I'm not a real programmer, but it seems to me that monerod is full of technical debt.

<vtnerd> seen worse. its still manageable, but others may have different thoughts

<articmine> @rucknium: Yes, I agree and this debt needs to be repaid before the hard fork

I'm a programmer, I agree, specially in the older parts of the codebase. They are usually also uncommented and have generic naming

<vtnerd> there are some oddities with epee and how that hooks into things, I wish that was done a little differently. the refactor of the tcp server probably helped

<articmine> I recognize that this may require additional time and resources

<jberman> ofrn and I discussed blocker issues for mainnet launch: 1) OOM after synced (we're going to figure this out), 2) pool consistently cutting down to 1 tx (hopefully solved with the latest bug fix), 3) wallet complaining about double spends

<articmine> Including CCS to fund the repayment of this devt

<articmine> Debt

<rucknium> I think @jeffro256:monero.social and @jberman:monero.social 's fixes to the stressnet code created other problems, like OOM (RAM exhaustion). Fixing problems causing more problems seems to be a symptom of bad initial architecture.

Ends up with fun side discovery trips like ge_fromfe_frombytes web.getmonero.org/resources/research-lab/pubs/ge_fromfe.pdf

<boog900> Its not just making the changes, its getting them reviewed and merged

<jberman> The OOM was there from the start, we think it's related to something from the FCMP++ integration, potentially the FFI

<boog900> Monerod doesn't really move that fast, for good reason

which now got fully resolved by kayaba&others

<articmine> @boog900: It is a lot of work that takes time. This needs to be recognized

<jberman> > Fixing problems causing more problems

<jberman> Just judging the stressnet channel, it seems to me like we have noticed actual improvement on connection issues and such. So it doesn't look like problems are increasing to me, but maybe you guys have a different experience @ofrnxmr:monero.social @rucknium:monero.social ?

there's also the (probably coming at a later point) DNS checkpoints being intertwined with block check code which ends up hard blocking nodes when used on specific thresholds

<rucknium> I mean the OOM on sync catch-up. My nodes with 8GB of RAM OOM'ed a lot on sync catch-up recently.

I think major improvements have been done but the underlying technical debt is seen on mainnet as well

<ofrnxmr> @rucknium: The ooms have been there since the beginning

<rucknium> Some of the connection problems are related to hard-coded limits. You can raise the limits, but that doesn't solve the architecture problems.

<ofrnxmr> @rucknium: This has existed on master/mainnet forever

it's just surprises when things that have been with us all along end up not working fully, either to breakage (or never worked properly)

<jeffro256> @jberman: I also thought that this was the case. My stressnet node has been taking up excessive RAM since v1.1

<ofrnxmr> Its just not noticable due to checkpoints

I think splitting what is FCMP++ issues vs mainnet would be a starter towards fixing these for beta stressnet?

<rucknium> I don't mean that the fixes caused the problems directly, but the fixes can reveal another lay of problems. Sorry to have worded that poorly.

<rucknium> another layer*

<jeffro256> Some of the fixes that we think are upstream issue have been adding to the FCMP++ upstreaming plan: seraphis-migration/monero #103

<jberman> @rucknium: Node mines >4mb fluffy block, relays it to another node that doesn't accept >4mb blocks because of hardcoded limit. We now relay empty fluffly block as expected, and the limit shouldn't be 4mb anyway

<ofrnxmr> @rucknium: Its neither. Its that the blockchain has grown and extended periods of large blocks are exposing the long standing broken spans

yeah. symptom vs actual problem

<ofrnxmr> DataHoarder: They are, for the most part

<jberman> @jberman: The architecture is established to allow 0 tx fluffy blocks to relay, but we weren't using it

<ofrnxmr> The last stressnet was when i showed the runaway spans to boog and 0xfffc

<jberman> Some issues are definitely architectural and require significant structural changes. For example, I personally don't think daemons should keep any counter state in memory in sync with db, because that is bug-prone. But there are little bugs that are fixable like counting correctly that allow us to move forward

<boog900> @ofrnxmr: I couldn't figure out the problem at the time, but I did find another issue. I think now I have found the problem: seraphis-migration/monero #147#issuecomment-3446862454

<rucknium> @ofrnxmr:monero.social: Yes. I think about how rough last year's stressnet was, even after the small fixes that prevented netsplits. It's more than a year later. I don't know where the labor and expertise will appear to fix all these things in a short period of time so the node can scale smoothly.

I can bring this to stressnet channel later, but do we want to do one last stressnet run with leak detectors or other tools engaged to gather data? for old or new issues

<jberman> We have been, ASAN isn't proving helpful unfortunately

<ofrnxmr> @rucknium: Boog found a vuln associated with runaway spans. 0x attempted to fix them in the dynamic span pr. But they still arent reliably solved

<jeffro256> DataHoarder: I think that it would be great if someone could compile monerod in debug mode and set their OS to save core dumps on OOM then send me or Berman the core dump

<kayabanerve:matrix.org> Sorry for being late. I've been working on some Ed25519 code and optimizations. I'll also note, somewhat as a circle-jerk but with relevance due to jeffro256's commentary, I've increasingly been working in code which doesn't allocate at all for usage within monero-oxide, and @boog900:monero.social: has done remarkable work on a more efficient DB.

<ofrnxmr> The dynamic span pr seems to work to keep the spans below 1gb, but it still runs away a bit, just not to 8gb

<jeffro256> It's probably not a "true" memory leak in the sense that the memory is still accessible, but something somewhere isn't being pruned. ASAN won't catch the former, but hand-inspecting the latter might

<ofrnxmr> @jeffro256: I havent had an running oom in a while and it seems to happpen when the txpool is huge

19:02:09 <br-m> <jeffro256> DataHoarder: I think that it would be great if someone could compile monerod in debug mode and set their OS to save core dumps on OOM then send me or Berman the core dump

^ I can do that, I ran monerod in debug mode during first stressnet days... but I'd have to move this elsewhere, as the OOM is killing more important things

<ofrnxmr> And only when the txpool is huge

unbounded memory growth :)

would relwithdebug info help?

<jberman> only happening when tx pool is huge is actually interesting new info

<ofrnxmr> @jeffro256: it could very well be the txpool..

oh woah

<boog900> Is this not just the OOM that txrealy v2 is trying to fix?

<jeffro256> DataHoarder: Debug build would probably be more helpful, but much, much slower to run / sync

<ofrnxmr> @boog900: Could be

I have two core dumps of fcmp monero

on debug mode

from the 1st of October

<jeffro256> Was that OOM'ed too?

<jeffro256> That was before the fork tho, yeah?

<jberman> have you had one since v1.3? > <@ofrnxmr> I havent had an running oom in a while and it seems to happpen when the txpool is huge

<ofrnxmr> yea, large txpool during spam attack caused nodes to repeatedlt oom

probably it was during db conversion

<ofrnxmr> @jberman: No

I would need to check system logs, it's SIGABRT

<ofrnxmr> @ofrnxmr: Or. maybe..

since v1.3 I had two OOMs and one preventive restart from me

where monerod was using 40+ GiB on stressnet with no RPC usage

<ofrnxmr> I told you the last time i had one. Not sure the date on that, but the txpool went from 20mb to 200mb when it did

I think we can discuss all of this on stressnet channel, if it's FCMP++ monero stressnet specific issues

<ofrnxmr> the running oom is probably tx-relay

<ofrnxmr> I think boog's right

<ofrnxmr> @0xfffc:monero.social pushed an update addressing @vtnerd:monero.social 's review on master

<jberman> Ok, generally I think we're going to need tx relay v2 and caching input validation (which is ready), and to observe alpha stressnet perf after both of those are in

<ofrnxmr> I dont know if its "ready", but ive run it and it seems ok

<rucknium> Let's count resources. Who thinks they are able to fix deep performance issues in monerod? Who would be willing to dedicate a lot of time to that in the next 6 months, 1 year, 2 years, etc.? Who thinks they could recruit new contributors who could and would do it?

<jberman> If we see significantly improved behavior after that point, then I'd vote to move toward beta stressnet

<rucknium> And there is a need to review proposed changes. What are the resources for that?

<ofrnxmr> @ofrnxmr: Main issue is that it still has amplification, as it requests missing txs from every peer at once. I think sequentially would be better, but other might disagree (?)

you'd probably at least 2x of the resources for making the changes and then review

<rucknium> This ^ type of work would be "good" to have before the FCMP hard fork, but it's most relevant for scaling discussions.

specially if doing modifications/refactors as needed

<jberman> Paging @perfect-daemon

<ofrnxmr> @jberman: shhhhh

<rucknium> @jberman:monero.social: Well, need something to be reviewable.

<jberman> I'm fine with reviewing whatever. I would personally like to prioritize FCMP++, Serai, and async scanner

<jeffro256> @ofrnxmr: @ofrnxmr:monero.social: run which one? Caching input validation or tx relay v2?

<ofrnxmr> @jeffro256: V2

<ofrnxmr> Havent tested the caching input pr

<ofrnxmr> With amplification, its still about = to boogs calculated 75% savings. W/o amplification, i think were upwards of 95% > <@ofrnxmr> Main issue is that it still has amplification, as it requests missing txs from every peer at once. I think sequentially would be better, but other might disagree (?)

<rucknium> More discussion about stressnet?

<kayabanerve:matrix.org> I'll throw on that I rewrote my RPC code for Monero and it should be a fascinating presentation of why the RPC is frustrating to use as-is, circling into vtnerd's prior commentary on debt and the HTTP server.

<ofrnxmr> I think its going well, and the IBD oom is a master issue that needs to be solved at some point (and doesnt req a hf to fix)

<jberman> @0xfffc:monero.social: 9933 is ready for re-review?

<ofrnxmr> I'll ask 0x to update & rebase the dynamic span pr and i'll retest it against stressnet.. it wasnt well received in review, but the general idea seemed to work well enough

@kayabanerve:matrix.org agree, reminds me of the other discussions a few weeks ago about undocumented areas or inconsistent usage or bad data on specific calls

<0xfffc> @jberman: Yes, it has been reviewed once by @vtnerd:monero.social . Of course there are still problems. ( since it is a huge PR ). But it is ready for review / testing.

<ofrnxmr> @jberman: I believe so.

<jberman> dynamic span PR is in stressnet already and seemed ok to me. It was the restricted RPC PR that I had some thoughts on that we didn't include in stressnet

<ofrnxmr> Dynamic bss is in stressnet,not dynamic span

<jberman> ah, misread

<ofrnxmr> Dynamic span was intended to curb the runaway spans by stopping download if sync time exceeded a set value

<ofrnxmr> By default, only downloading what can be synced within 2mins. (it still runs away occasionally, but not to 8+gb)

<ofrnxmr> monero-project/monero #9495

<boog900> Yeah that PR didn't change the stripe_proceed_main condition IIRC, where I am almost certain the issue is

<jberman> ok, I think I will pause continuing on OOM while already synced and focus on reviewing 9933 instead, and will review the issue boog pointed out for runaway spans

<jberman> > <@jberman> ofrn and I discussed blocker issues for mainnet launch: 1) OOM after synced (we're going to figure this out), 2) pool consistently cutting down to 1 tx (hopefully solved with the latest bug fix), 3) wallet complaining about double spends

<jberman> but generally I think we want to solve these issues before mainnet launch. And once tx relay v2 + cache validated txs is in and perf observed, we decide on beta stressnet

<rucknium> 6. Mining pool centralization: Temporary rolling DNS checkpoints (monero-project/monero #10064), Share or Perish (monero-project/research-lab #146), and Lucky transactions (monero-project/research-lab #145).

<ofrnxmr> i think we should release 2) (195) on stressnet and see if anyone runs into the issue again

<jberman> typo?

<ofrnxmr> Im running on a few nodes, but its not a consistent condition to reproduce, but atleast 3 people on 1.3 have hit it

<ofrnxmr> 195 = the fix for the double counting of txs

<jberman> agree wasn't sure what the 2) was before

still blocked by the issue on monero around hitting a checkpoint in the wrong place

<jberman> we can get a release out today. Possibly will include cache re-validation too

<ofrnxmr> oh, yea, 2 = pool cutting down to 1x (which is a secondary cause of double spend errors)

<jberman> DataHoarder: which issue is this one again sorry

<rucknium> DataHoarder: DataHoarder: What are the resources needed to address the DNS checkpoint bug, in your opinion?

<jberman> ah ya

see jberman monero-project/monero #10075#issuecomment-3418776630

rucknium: a reproducer that can be fed via pop_blocks, restart, then feed blocks / txs via RPC in offline mode

(that way we can literally script the steps and can verify the behavior to debug further and start untangling that)

realistically it should get refactored to not be really tied together then it can get well unit tested

that's a ... larger change, in a very consensus part of the logic

someone that knows that consensus part well can attempt the fixes, but it's not great without a specific reproducer other than "get lucky when the checkpoints are set"

I manually attempted to selfish mine myself and place the branch in the specific point it's supposed to trigger the issue, but it didn't (and instead got banned for several days by all testnet peers :D)

<ofrnxmr> When i was repro, i was manually splitting the chain, causing reorgs, then plugging in checkpoint from the old chain

from looking at ofrnxmr logs, the call gets called twice in quick succession, one passes and next one fails with the intended block to checkpoint

so elsewhere it pops (?) and then it can't find the block again in db on next iteration

<ofrnxmr> yeah, after getting the checkpoint, the first run through i think should notice that the checkpoint is associated with one of the alt chains, andreinstate the alt chain

yep. then it tried to add the block, but it couldn't find the parent, which was the checkpointed block

<ofrnxmr> Instead, it recognizes the alt chain as orphaned, and refused to reorg onto it, and pops back to before the checkpoint.. then rejects all new blocks

<ofrnxmr> Rejects checkpointed block because its ordered. Rejects any other blocks because they dont match the checkpoint

^ can't find checkpoint as parent, yeah

<ofrnxmr> Manually setting is_a_checkpoint to true, seems to "fix" it (first pass doesnt dall through), so that it reinstates the alt chain. i dont understand what is_a_checkpoint is supposed to do though

<ofrnxmr> ..Just that setting it to true "fixes" it

it forces reorg on it, instead of checking difficulty

however that means every block is a checkpoint :)

FCMP++ stressnet also took all the attention, so not much has been done on regular testnet ^ looking into this one

<rucknium> I converted most of my testnet nodes to stressnet nodes. I could keep both stressnet and testnet on the same machines, but then the stressnet node would OOM kill everything :D

<rucknium> Thanks for the explanations, DataHoarder and @ofrnxmr:monero.social .

<rucknium> We can end the meeting here. Thanks everyone.

<sgp_> @rucknium:monero.social: your comment about hashrate and XMR/USD price from earlier this week sparked some ideas in my head for scaling, and I may incorporate that idea in some form into my block size proposal

<ofrnxmr> DataHoarder: Yeayea, i mean, i dont know what causes it to be true under normal circumstances

<ofrnxmr> Because it doesn't seem to do anything.. but the function within it appears to do as advertised and reorg onto the checkpointed chain

<sgp_> My first impression is to use a decreasing hashrate/reward ratio from the prior year as an indicator of network contraction, but I'm still testing a few scenarios for that idea

<sgp_> @rucknium:monero.social: I thought about it more, and I think hashrate is too unreliable on an indicator of price to use for anything important. If electricity costs grow faster than CPU speeds, then hashrate per miner reward will decrease. But that's not even the biggest issue. If a network decides to merge mine on Monero, an [... too long, see mrelay.p2pool.observer/e/g_Ss2MMKY21tQTZZ ]

<ofrnxmr> Or the cost per hash decreases every year based on improvements in processing speed

<sgp_> The efficiency gain is fine for my initial intended use. I was considering using a decrease in hashrate/miner_reward compared to a year ago as a conservative indicator of XMR's decrease in value. But it's not reliable enough for even that due to the merge mine unknown. This is the response I was working on if you want more con [... too long, see mrelay.p2pool.observer/e/nsK-2MMKYlVTdkQw ]

<spacekitty69420:matrix.org> @sgp_: wouldnt the miner reward average be an estimate tho? unless there is an actual way to know how many invidiual rigs are mining on the network but i dont think its an actual thing tho

<sgp_> I don't think the average block reward per miner is a useful indicator, or at least I can't think of how to use that

<articmine> @sgp_: Of course. It is essentially fixed

<articmine> It is called a tail emission

<articmine> I suspect what you are really trying to measure is the rate of electricity consumption of the Monero network.

<articmine> Since the block reward and the block frequency this would provide a price for Monero in terms of kWh

<articmine> . block reward and block frequency are constant