Ukoe, related to the PR here: monero-project/monero #8679. Do you know why each cache element is aligned to 4096 (even before ur PR)?

Or rather, the first element of each cache

Why is it doing an aligned alloc

Hello! I recently heard some critics about Monero that the txo state (the chain state in Bitcoin) is growing indefinitely and will cause issue in the future. However I don't find anything about it on the web. Can you point me to some resources? What is your opinion about it? Thank you

The data that you have to process to run a full node grows indefinitely in Bitcoin as well, but what you're probably thinking of is the UTXO (unspent) set. B/c of ring signatures, there is no way to tell (as long as you don't dox your own key image) if any output on the chain is spent or not, so Monero can't "prune" any of these outputs away like you can in cryptocurrencies where you can say for sure for any given transaction if a

certain output is spent (basically everyone else).

Zero to Monero is always a great place to learn about these details IMO web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf

Yes Monero can't prune the txo set, makes total sense. No magic solution for now then. I don't see where Zero to Monero talks about this.

sech1: do you think we should include the ringct cache in the next release?

when is the next release?

if it's in January, it will be enough time for reviews and testing

I wanted to make a release in the next week or so but we have quite a lot of changes so maybe v0.18.2.0 in January makes more sense

making release before long holidays is never a good idea :D

yep, agree lol

I am using the get_transaction_pool RPC call to collect mempool data. For best privacy, is there a way to exclude (1) transactions in the Dandelion++ stem phase and/or (2) transactions submitted directly to the node? Or does get_transaction_pool already exclude those transactions?

Use restricted RPC mode and it'll hide Dandelion phase txes.

And don't send txes while you look.

Thank you. So far I'm using unrestricted mode to record the tx receive_time field. I think I could get the same effect by just checking when I first see the tx. I am polling once per second anyway.

I think if you get transactions via ZMQ, it will automatically filter only fluff phase transactions, and at the exact time they're received or transition to the fluff phase

I considered using ZMQ since it would be more efficient than polling. But for now I've prioritized portability of the code to run on different nodes (to get a view of different parts of the network). Some nodes would have to restart to enable ZMQ AFAIK.

22 ish public nodes with ZMQ port open github.com/plowsof/listen_for_zmq/blob/main/zmq_list.md

Is ZMQ a major performance drain for public nodes, or is it pretty light? Should we recommend people enable it by default?

it's light on CPU, but it can generate a lot of traffic if there are many transactions on the network

also as far as I know, only p2pool actually uses ZMQ

<BusyBoredom[m]> "Is ZMQ a major performance drain..." <- There is no reason to publish ZMQ

Unless of course someone wants to mine P2Pool with a remote node

But I doubt that, since they can get insta-scammed

they can't get scammed because p2pool node controls payouts.

worst they get wrong miner data or non-existent transactions

in the first case they will get rejected by other p2pool nodes

in the second case, they will lose their own mined blocks