who knows...

I have a particular use-case that at first (and second) glance seems like it could be a bit clunky to implement with the [Wallet](getmonero.org/resources/developer-guides/wallet-rpc.html) and [Daemon](getmonero.org/resources/developer-guides/daemon-rpc.html) RPC APIs. Hopefully this is not... (full message at libera.ems.host/_matrix/media/r0/do…cb14ad2cf1583b2c2b45804e4b631937281)

Regarding the `create_account` bit, I'd be curious to know if anyone has been running wallets with 1000+ subaddresses, and if there are any actual or practical limitations to the number of subaddresses, and the performance impact of doing such a thing.

methylene[m]: having 1000+ subaddresses shouldn't be a problem

wallet RAM usage increases with subaddresses but sync time should stay constant

selsta: And if we speak of 100K, 1M, 10M addresses?

Same. Higher RAM usage and constant sync time.

Ok, that's certainly positive. Do you have an idea what the RAM requirements would be for every, say 1000 addresses?

I don't know exactly. But if your requirement is millions of subaddresses it shouldn't be a problem to run the wallet on a VPS with more than 2GB RAM :)

1000 addresses shouldn't be visible at all in RAM usage. If I remember correctly the default is 10000 subadddresses.

Whatever the memory per address (within reason), RAM requirements scaling linearly with the number of simultaneously watched addresses seems very reasonable. My main concern remains pruning of unused addresses. Is there a way to tell a wallet to stop caring about a subaddress? I don't mind if the address still "exists" (the index will obviously not be reused, deterministic derivation and tralala), I just don't want it to expend RAM

storing it, nor cycles watching for its transactions.

I don't think that exists currently.

So, practically speaking, the most straightforward path seems to be using a single wallet and not worrying about it for now, and working on a patch for the wallet core to make it support sparse subaddresses. The other solutions of having a wallet pool sound clunky, plus opening and closing wallets seems to take a not-inconsiderable amount of time in my testing.

I might convert the subaddress index to a `uint64_t` as well, while I'm at it ;)

Sanity check: I should be modifying `src/wallet`, not `simplewallet1, yes?

s/simplewallet1,/simplewallet`,/

methylene[m]: simplewallet is monero-wallet-cli program, wallet2 is the internal wallet implementation

simplewallet calls wallet2 functions

the account index is uint32_t and the subaddress index is also uint32_t

.merge+ 8190

Added

What can you say to the point of anonymity set for transactions being only 11. Why is that enough? Apparently the private version of ZCash has an anonymity set of ~500k

can you trace some xmr trades for us to show that 11 isnt sufficient?

with Tryptich over 128 will be possibo

selsta: Right, I see that it is currently a `uint32_t`. Also looks like it's already stored as a map some places internally, so I guess exposing an RPC method to delete keys out of that map would be possible, but ideally they would also not be loaded at all on wallet open. I guess this would require changing... (full message at libera.ems.host/_matrix/media/r0/do…8e2bb157fe7e3a90dc5d945254198a51380)

My hope is of course to find a way to make this change that doesn't break the `wallet2` api and all the other stuff that depends on it.

methylene[m]: it's two unit32_t indices

one account index and one subaddress index

{account, subaddr_idx}?

Aha, sure.

Same principle applies though, in order to support sparse subaddresses, that would need to become a sparse list. Wouldn't really change much for wallets/users that don't care about removing subaddrs though, if serialized in a reasonable way.

`m_subaddr_labels` *could* be changed to a `serializable_unordered_map<cryptonote::subaddress_index, crypto::public_key>`, but it's probably fine as is

So the wallet cache already seems fine also, as far as tolerating deleting/sparse subaddresses. The keys file doesn't store `{account, subaddr}`, so we expect restoring from keys to require additional...help...as it already does. And if a cache file exists it looks like it will load that, sparse or otherwise... (full message at libera.ems.host/_matrix/media/r0/do…a3f8cda8612170b98de2fa336663fba105f)

Being careful about having `null` in `m_subaddr_labels`, I suppose, could make them all point to `static LABEL_EMPTY = ""`, don't think they get derefed unless the index exists in `m_subaddrs` though.

This would obviously be great if it works, so as to not even break the existing cache format.

selsta: Does this look like it's going to blow up all over the place?

Hey everyone

I'm having some issues with the wallet RPC atm and I'd like some help

So i'm trying to just generate a monero subaddr, transfer money to that subaddr, and then send it back

The first two things I'm able to do perfectly fine w 0 issue, but it's the sending ti back part that's giving me trouble

When I just try to send back the exact amount i sent to the wallet, I get an error of "not enough money"

Which I honestly completely don't understand, since at higher log levels when it says "available" and "tx amount" tx amount is lower

Enough left for the fee ?

bootlegbilly: Fee + did you wait for the transaction to be confirmed?

Current network fee is 0.000000004565 right?

If so then yes

Oh

Thats the fee per byte

Jesus lol

Is there anyway of calculating the size of a transaction from just the amount??

s/??/?/

bootlegbilly: For your use case, just `sweep_*` rather than `transfer`.

methylene I don't think I'm able to specify the amount I send with the sweep_* functions though

Just from what i can tell from the docs

bootlegbilly: True, that's the point. You said you wanted to "send it back", all of it being the implication.

Oh that's very true, jaja

What if I only wanted to send part of it back

Then you would probably have enough for the fees :)

Ty

Hey so really quick

Whats the difference between transfer and transfer_split

Like ik the docs say that the transaction can be split if needed but does that make a difference at all?

like will transfer_split succeed more often on a specific edge case?

There's a sweep_all call.

(which will send balance-fee)

methylene[m]: I'm not familiar with the subaddress code myself so can't really help

I don't *think* it'll break, but I'm not sure. The reason I think it will not break is that you can add a subaddress with an arbitrary index, and I'm not aware of anything this breaks. However, it's unlikely to be tested much.

In any case, it's theoretically possible to make it work, so any breakage is fixable.

Of course, you lose the ability to auto bump the pregenerated indices if you receive something on an address you dumped, but I think that's what you want anyway.

I also have an old patch that halves RAM requirements for subaddreses. Might be useful if RAM usage is your original issue for wanting to forget addresses.

bootlegbilly[m]: originally, transfer_split allows making more htan one tx per request, while transfer does not.

In simplewallet, transfer now runs transfer_split internally.

In RPC, I think it's still the old nomenclature, for compat reasons.

You should not need to use the transfer RPC, just transfer_split.

moneromooo: Ty

selsta: have you seen this failure before (node_server unit test) github.com/monero-project/monero/runs/5414279246

UkoeHB: is it consistently reproducible?

I would force push and try again

do you have a trick to force pushing? the only way I know is to modify the commit with a rebase

push -f

(Whether that triggers a github build though, no idea)

Everything up-to-date

This is what I get

git commit -S --amend --no-edit

git push -f

selsta: thanks :)

monero-javscript related question: are there any limitations or underlying assumptions about the monero wallet listeners that I dont know about?

AIUI javascript doesn't grok integers, so large amounts will lose precision.

I setup the listner in a redux-saga like this. But it seems like the onSyncProgress callback never happens even though I see in the network tab that the wallet is syncing with the server

s/server/daemon /

if youre having JS problems with integers, make sure you go through and BigInt everything

hocuspocusoutoff: I dont think its related to integers. the problem is the listener callback does not get called.

I see in the network console something is happening but I dont get the callback from the listener

maybe woodser knows something I could try 😅🙂

UkoeHB: seems green now

I haven't tried the yield/call syntax. are you able to do more conventional await monero_wallet.addListener(listener) ?

woodser[m]: yes I tried it too.

still the same result. I also added a onnewblock handler

but it seems like non of the handlers get called. Maybe this is related to webasm and isolation or somthing ...

s/somthing/something/

Can you point me somwhere in the monero-javascript codebase where I can dig?

s/somwhere/somewhere/

or maybe it is webworker related

could it be that the wallet is already synced, perhaps a new wallet, and new blocks need to be added to the chain?

this test will print sync updates to the console: github.com/monero-ecosystem/monero-…25e77961/src/test/Scratchpad.js#L46

npm run test -- --grep "Scratchpad"

woodser[m]: ah okay true. maybe its working but the subconscious assumptions I had about it are wrong. I just created the wallet for testing purposes

it only fires on initial sync (doesn't apply to new wallets) and when new blocks are added to the chain

woodser[m]: hm...maybe on stagenet there were no new blocks

yeah it makes sense. So I will just assume it works and implement the sending and receiving part of the UI and then see again if it works

thanks a lot for your help. Its easy to get stuck in the mud when assuming things that shouldnt be assumed haha

np :)

Just wait 3 minutes when you can safely assume a block has been mined

Then you should see the onnewblock get called

Elijah[m]: is it also on stagenet?

Stagenet is just mainnet code wise just that xmr has no fiat value.

* just that the xmr has

hm..or maybe something is wrong with the daemon connection

selsta: yep guess it's a rare bug or oom issue