07:11:17 Ukoe, related to the PR here: https://github.com/monero-project/monero/pull/8679. Do you know why each cache element is aligned to 4096 (even before ur PR)? 07:20:16 Or rather, the first element of each cache 07:20:35 Why is it doing an aligned alloc 08:49:03 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 08:59:54 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 08:59:54 certain output is spent (basically everyone else). 09:00:11 Zero to Monero is always a great place to learn about these details IMO https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf 09:14:34 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. 17:33:58 sech1: do you think we should include the ringct cache in the next release? 17:34:27 when is the next release? 17:34:43 if it's in January, it will be enough time for reviews and testing 17:39:31 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 17:40:41 making release before long holidays is never a good idea :D 17:43:25 yep, agree lol 17:45:11 -xmr-pr- GottMitUns opened issue #8680: Daemon dont synchronize 17:45:11 -xmr-pr- > https://github.com/monero-project/monero/issues/8680 18:34:54 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? 18:38:52 Use restricted RPC mode and it'll hide Dandelion phase txes. 18:39:11 And don't send txes while you look. 19:24:14 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. 19:33:04 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 19:39:35 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. 19:40:36 22 ish public nodes with ZMQ port open https://github.com/plowsof/listen_for_zmq/blob/main/zmq_list.md 20:04:09 Is ZMQ a major performance drain for public nodes, or is it pretty light? Should we recommend people enable it by default? 20:07:39 it's light on CPU, but it can generate a lot of traffic if there are many transactions on the network 20:08:00 also as far as I know, only p2pool actually uses ZMQ 20:37:02 "Is ZMQ a major performance drain..." <- There is no reason to publish ZMQ 20:41:53 Unless of course someone wants to mine P2Pool with a remote node 20:42:14 But I doubt that, since they can get insta-scammed 20:46:35 they can't get scammed because p2pool node controls payouts. 21:31:33 worst they get wrong miner data or non-existent transactions 21:31:44 in the first case they will get rejected by other p2pool nodes 21:32:11 in the second case, they will lose their own mined blocks