Registration has been disabled on this homeserver.

Got this error when trying to join monero.social homeserver matrix with element.

hi friends, this is my first time here

<n​onlogs:matrix.org> So, can you tell me the CPU and memory usage for this action would it crash? for 100k subaddress.

<r​brunner7:monero.social> I am not sure, but I dimly remember to have read somewhere that somebody tried something like this number of subaddresses, and it did not crash, but it became very sluggish.

<r​brunner7:monero.social> Anyway, the system is not designed and not built for such a high number of subaddresses, you are outside of the spec with that so to say, and it or may not work, and if it doesn't, nobody may care to improve the code. I think investing time into finding a way to avoid 100k subaddresses and still solving your use case would be a good idea.

<n​onlogs:matrix.org> If I make the hot wallet account 1 and keep user funds in account_index = 0, then run sweep_all daily to move funds into account_index = 1, the unspent outputs in account_index = 1 won’t be swept is that the best approach?

<n​onlogs:matrix.org> Or should I instead maintain a database table that records which subaddresses received deposits each day, and call sweep_all with the specific subaddr_indices for those addresses which approach is better?

<n​onlogs:matrix.org> Does XMR have issues tracking incoming transactions if there are more than 100k subaddresses, or would it still work smoothly? I’m asking this in terms of exchange scalability.

<r​brunner7:monero.social> Frankly, I think if you really wanted to know for sure, you would have to try yourself. I don't know how big exchanges manage their XMR wallets, and they probably won't tell anyway.

<n​onlogs:matrix.org> Running multiple wallets i guess. 10k subaddy each maybe.

<r​brunner7:monero.social> Could be, yes.

<r​brunner7:monero.social> But realistically, even for a big exchange 10k of incoming XMR payments may take a while.

<r​brunner7:monero.social> From 10k different people. Because if you know the wallets, you can give somebody the same address again if they transfer again, right?

<r​brunner7:monero.social> Or, if you know the people of course

<n​onlogs:matrix.org> Yes, that’s true for XMR, but with XMR forks like WOW and RYO, those limits can be easily surpassed.

<n​onlogs:matrix.org> Yes 1 account gets 1 subaddy thats how it works. so 10k accounts = 10k subaddy.

<r​brunner7:monero.social> No offense, but this reminds me a bit of questions of people about websites: "How to build a website for 1000 hits per second?" "Wow, you will have 1000 hits per seconds? You aware how few websites worldwide have traffic like that?" Half a year later: The built website gets 5 hits per seconds during the busiest times.

<n​onlogs:matrix.org> I already have 150+ wownero subaddresses, and within a few months it could easily exceed 1k. As a developer, I need to be prepared for the worst case scenario.

<r​brunner7:monero.social> Fair enough. Personally I tend to think sometimes it's enough to *know* what I will do if I have to scale, but not yet scale to such heights *today*. Maybe things develop in different ways than I anticipated. And maybe the bottlenecks won't be where I expected them, at all.

<r​brunner7:monero.social> FCMP++ is also some kind of a wildcard: If you plan years ahead, which is of course prudent, right now it's hard to do. FCMP++ transactions will be bigger, we will see how things behave with that. A bit hard to predict *exactly*.

<r​brunner7:monero.social> People at the bleeding edge of the FCMP++ test net currently have the problem that, with the still pretty un-optimized code, transactions take much longer to create, for example.

Curious about mempool stats, wouldn't the invalidated transactions be considered "failing"? paste.debian.net/plainh/ad7f286d

however for the 116 invalidated transactions it lists 0 failing

<r​brunner7:monero.social> Yes, after a first look into the code it looks a bit strange why those would not get counted as "failing"

Maybe this node saw them initially?

<r​brunner7:monero.social> I also have a daemon which has them in the pool, not failing as well

<r​brunner7:monero.social> Maybe one of those cases of a decade-old bug, or at least weakness, where it never mattered enough for somebody to really care :)

maybe

<r​brunner7:monero.social> <.,,,,.<.,y<.<<:;><e3yx

<r​brunner7:monero.social> £

<h​elene:unredacted.org> i agree with the csat

<h​elene:unredacted.org> i agree with the cat

<h​elene:unredacted.org> cat*

<r​brunner7:monero.social> Not cat, my grandchildren :)

<h​elene:unredacted.org> oh darn :D

<r​ucknium:monero.social> DataHoarder: Did you try to mine on the node with `start_mining`? I only saw log messages about failed tx verification when I tried to mine them.

Not on this one. I mean print_pool_stats

<r​ucknium:monero.social> tx verification caused by re-org on testnet and misaligned global output index, I mean.

<r​ucknium:monero.social> I don't think the node tries to re-verify a txpool tx unless it needs to, e.g. when trying to create the block template for mining.

it's mainnet node, not testnet

<r​ucknium:monero.social> You can still start mining on it. Just won't find a block soon :)

<r​ucknium:monero.social> I don't want to touch any of my mainnet nodes yet with `start_mining` since it's like disturbing a crime scene. Must preserve the evidence!

well yeah. this is also mainnet :D

I started "mining" on it but via p2pool so it's not relevant

<r​ucknium:monero.social> Just tried on testnet (2 stuck txs). It works. `start_mining` those 2 txs into "failing" in the `print_pool_stats` output.

<r​ucknium:monero.social> `set_log verify:trace;ringct:trace;txpool:trace` gives you `E Failed to check ringct signatures!` messages when you `start_mining`.

maybe a reorg should re-verify pool txs the same way?

<r​brunner7:monero.social> Yup, can confirm. Starting to mine does not result in any error messages, but after that the transactions are listed as "failed"

<o​frnxmr:xmr.mx> Tf r u talking abt..?

<o​frnxmr:xmr.mx> No fork help here.

<r​brunner7:monero.social> Uh oh ofrnxmr notices absolutely everything :)

<n​onlogs:matrix.org> Are you sure a wallet file with 100k subaddresses could handle an RPC query for get_transfers or get_balance?

<r​ucknium:monero.social> I know for a fact that get_balance is slow if you have lots of accounts, at least. Lots = tens of thousands.

<n​onlogs:matrix.org> ofrnxmr: i think you need to read the question again.

<r​ucknium:monero.social> Since I've done it on stressnet.

<n​onlogs:matrix.org> Thats what i have been asking for.

<o​frnxmr:xmr.mx> theres no diff between wow and xmr

<o​frnxmr:xmr.mx> You're expecting 100k users = lol

<r​ucknium:monero.social> I don't know what happens when you have a single account and tens of thousands of subaddresses since I didn't structure my tx spammer that way.

<o​frnxmr:xmr.mx> 250k was where antidarknet claimed there to be a slowdowm

<n​onlogs:matrix.org> What I’m saying is that on my exchange, I won’t need to create many subaddresses for XMR since fewer people will be trading it. But many users are interested in WOW, so my exchange could potentially reach over 1k subaddresses in the next few months. I hope that makes it clear.

<o​frnxmr:xmr.mx> This is a simple excercise. Create 100k subaddresses and then run the query

<o​frnxmr:xmr.mx> 1k is nothing. Wow doesnt have 10k users, nevermind 100k

<o​frnxmr:xmr.mx> Again, "_no fork help_"!

<o​frnxmr:xmr.mx> Read the room description

<n​onlogs:matrix.org> Even if they don’t have 10k users, that doesn’t mean my exchange doesn’t need to prepare for it. I think you have very little experience in development that’s not how things work in production.

<o​frnxmr:xmr.mx> .. And none of this is related to monero development

<o​frnxmr:xmr.mx> I think you use chatgpt too much and make assumptions based on hallucinations, and dont read docs

<o​frnxmr:xmr.mx> ^^ this is the last thing thats needs ti be said on the subject

<o​frnxmr:xmr.mx> I'm sure [@plowsof:matrix.org](https://matrix.to/#/@plowsof:matrix.org) has ran this exercise

<n​onlogs:matrix.org> any doc's or findings ?

<o​frnxmr:xmr.mx> Generating 1.5m addresses monero-project/monero #5370#issuecomment-1435494507

For Sweep_all with many outputs: a complex process, selecting outputs and possibly waiting multiple blocks before sending further transactions alot of logic there. In practice sweep_all creates transactions until it grinds to a hault, you just try again and again . As for handling these large wallet caches, there are a few open issues reg how long

it takes to simply open them

<o​frnxmr:xmr.mx> [@plowsof:matrix.org](https://matrix.to/#/@plowsof:matrix.org) it only grinds to a halt if you have many outputs to sweep

<o​frnxmr:xmr.mx> `Sweep all, amount below` daily, should have minimal outputs being spent

👍

<o​frnxmr:xmr.mx> sweep_all doesnt only grind to a halt, jt fails entirely if it takes too long to generate all of the txs

<o​frnxmr:xmr.mx> monero-project/monero #10032

<o​frnxmr:xmr.mx> But again, these are akl xyprobkem.info

<o​frnxmr:xmr.mx> Nonlogs's goal is to consolidate dust on a regular basis. This prevents issues described above, so the issues arent relevant

<o​frnxmr:xmr.mx> I helped a user the other day that had an active wallet with over 100k subaddresses, even resynced the wallet from the restore height. No notable issues with the many addresses

<o​frnxmr:xmr.mx> Things like coincards and cakepay (btcpayserver) have a a new address for every invoice, and likely far exceed 100k subaddresses.

<o​frnxmr:xmr.mx> I highly doubt that you will have issues when your users have static addresses, when these services do not have issues when they generate a new address for every invoice