00:22:26 <UkoeHB> who knows...
00:41:24 <methylene[m]> 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](https://www.getmonero.org/resources/developer-guides/wallet-rpc.html) and [Daemon](https://www.getmonero.org/resources/developer-guides/daemon-rpc.html) RPC APIs. Hopefully this is not... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2a89bcb14ad2cf1583b2c2b45804e4b631937281)
00:44:05 <methylene[m]> 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.
00:56:11 <selsta> methylene[m]: having 1000+ subaddresses shouldn't be a problem
00:56:23 <selsta> wallet RAM usage increases with subaddresses but sync time should stay constant
00:59:32 <methylene[m]> selsta: And if we speak of 100K, 1M, 10M addresses?
00:59:54 <selsta> Same. Higher RAM usage and constant sync time.
01:01:08 <methylene[m]> Ok, that's certainly positive. Do you have an idea what the RAM requirements would be for every, say 1000 addresses?
01:08:16 <selsta> 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 :)
01:08:47 <selsta> 1000 addresses shouldn't be visible at all in RAM usage. If I remember correctly the default is 10000 subadddresses.
01:09:01 <methylene[m]> 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
01:09:01 <methylene[m]> storing it, nor cycles watching for its transactions.
01:09:53 <selsta> I don't think that exists currently.
01:12:27 <methylene[m]> 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.
01:18:23 <methylene[m]> I might convert the subaddress index to a `uint64_t` as well, while I'm at it ;)
01:21:59 <methylene[m]> Sanity check: I should be modifying `src/wallet`, not `simplewallet1, yes?
01:22:31 <methylene[m]> s/simplewallet1,/simplewallet`,/
02:16:46 <selsta> methylene[m]: simplewallet is monero-wallet-cli program, wallet2 is the internal wallet implementation
02:16:56 <selsta> simplewallet calls wallet2 functions
02:18:43 <selsta> the account index is uint32_t and the subaddress index is also uint32_t
02:18:45 <selsta> https://monerodocs.org/public-address/subaddress/
03:18:07 <selsta> .merge+ 8190
03:18:07 <xmr-pr> Added
03:30:45 <euneauxhoo[m]> 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
03:32:05 <hocuspocusoutoff> can you trace some xmr trades for us to show that 11 isnt sufficient?
06:16:31 <tusko> with Tryptich over 128 will be possibo
08:00:18 -xmr-pr- EWIT521 opened issue #8204: How to simulate a TXID for multiple UTXO transaction
08:00:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8204
10:15:18 -xmr-pr- mj-xmr opened pull request #8205: Compil. time: cryptonote_core minus portable_storage header
10:15:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8205
12:57:39 <methylene[m]> 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/735428e2bb157fe7e3a90dc5d945254198a51380)
13:01:59 <methylene[m]> 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.
13:11:30 <selsta> methylene[m]: it's two unit32_t indices
13:12:01 <selsta> one account index and one subaddress index
13:12:18 <methylene[m]> {account, subaddr_idx}?
13:12:23 <methylene[m]> Aha, sure.
13:14:26 <methylene[m]> 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.
13:31:46 <methylene[m]> `m_subaddr_labels` *could* be changed to a `serializable_unordered_map<cryptonote::subaddress_index, crypto::public_key>`, but it's probably fine as is
14:10:03 <methylene[m]> 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/4a844a3f8cda8612170b98de2fa336663fba105f)
14:18:00 <methylene[m]> 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.
14:21:02 <methylene[m]> This would obviously be great if it works, so as to not even break the existing cache format.
14:21:02 <methylene[m]> selsta: Does this look like it's going to blow up all over the place?
15:05:19 <bootlegbilly[m]> Hey everyone
15:05:33 <bootlegbilly[m]> I'm having some issues with the wallet RPC atm and I'd like some help
15:05:50 <bootlegbilly[m]> So i'm trying to just generate a monero subaddr, transfer money to that subaddr, and then send it back
15:06:14 <bootlegbilly[m]> 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
15:07:26 <bootlegbilly[m]> When I just try to send back the exact amount i sent to the wallet, I get an error of "not enough money"
15:07:50 <bootlegbilly[m]> Which I honestly completely don't understand, since at higher log levels when it says "available" and "tx amount" tx amount is lower
15:08:26 <moneromooo> Enough left for the fee ?
15:09:05 <methylene[m]> bootlegbilly: Fee + did you wait for the transaction to be confirmed?
15:12:02 <bootlegbilly[m]> Current network fee is 0.000000004565 right?
15:12:45 <bootlegbilly[m]> If so then yes
15:43:00 <bootlegbilly[m]> Oh
15:43:02 <bootlegbilly[m]> Thats the fee per byte
15:43:04 <bootlegbilly[m]> Jesus lol
15:43:25 <bootlegbilly[m]> Is there anyway of calculating the size of a transaction from just the amount??
15:43:35 <bootlegbilly[m]> s/??/?/
15:45:08 <methylene[m]> bootlegbilly: For your use case, just `sweep_*` rather than `transfer`.
15:46:40 <bootlegbilly[m]> methylene I don't think I'm able to specify the amount I send with the sweep_* functions though
15:46:46 <bootlegbilly[m]> Just from what i can tell from the docs
15:53:02 <methylene[m]> bootlegbilly: True, that's the point. You said you wanted to "send it back", all of it being the implication.
15:53:21 <bootlegbilly[m]> Oh that's very true, jaja
15:53:27 <bootlegbilly[m]> What if I only wanted to send part of it back
15:54:55 <methylene[m]> Then you would probably have enough for the fees :)
15:55:53 <bootlegbilly[m]> Ty
16:14:06 <bootlegbilly[m]> Hey so really quick
16:14:08 <bootlegbilly[m]> Whats the difference between transfer and transfer_split
16:14:21 <bootlegbilly[m]> Like ik the docs say that the transaction can be split if needed but does that make a difference at all?
16:14:31 <bootlegbilly[m]> like will transfer_split succeed more often on a specific edge case?
16:29:27 <moneromooo> There's a sweep_all call.
16:30:06 <moneromooo> (which will send balance-fee)
17:29:48 <selsta> methylene[m]: I'm not familiar with the subaddress code myself so can't really help
17:39:03 <moneromooo> 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.
17:39:24 <moneromooo> In any case, it's theoretically possible to make it work, so any breakage is fixable.
17:39:53 <moneromooo> 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.
17:40:58 <moneromooo> 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.
17:41:52 <moneromooo> bootlegbilly[m]: originally, transfer_split allows making more htan one tx per request, while transfer does not.
17:42:07 <moneromooo> In simplewallet, transfer now runs transfer_split internally.
17:42:24 <moneromooo> In RPC, I think it's still the old nomenclature, for compat reasons.
17:42:40 <moneromooo> You should not need to use the transfer RPC, just transfer_split.
17:42:57 <bootlegbilly[m]> moneromooo: Ty
18:57:29 <UkoeHB> selsta: have you seen this failure before (node_server unit test) https://github.com/monero-project/monero/runs/5414279246
19:03:42 <selsta> UkoeHB: is it consistently reproducible?
19:05:35 <selsta> I would force push and try again
19:07:29 <UkoeHB> do you have a trick to force pushing? the only way I know is to modify the commit with a rebase
19:07:43 <moneromooo> push -f
19:08:13 <moneromooo> (Whether that triggers a github build though, no idea)
19:08:25 <UkoeHB> Everything up-to-date
19:08:29 <UkoeHB> This is what I get
19:08:56 <selsta> git commit -S --amend --no-edit
19:09:03 <selsta> git push -f
19:11:51 <UkoeHB> selsta: thanks :)
20:45:18 -xmr-pr- BebeSparkelSparkel opened issue #8206: unit_tests node_server.bind_same_p2p_port FAILED
20:45:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8206
21:19:26 <spirobel[m]> monero-javscript related question: are there any limitations or underlying assumptions about the monero wallet listeners that I dont know about? 
21:19:39 * spirobel[m] uploaded an image: (356KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/lFsieMskpPlErLvdmaRPRhGp/walletlisteners_code.png >
21:19:44 * spirobel[m] uploaded an image: (167KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/OdsfKMCgyzJXpkCZZGmItlaK/consolelog.png >
21:20:35 <moneromooo> AIUI javascript doesn't grok integers, so large amounts will lose precision.
21:20:43 <spirobel[m]> 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
21:21:26 <spirobel[m]> s/server/daemon /
21:22:45 <hocuspocusoutoff> if youre having JS problems with integers, make sure you go through and BigInt everything
21:23:22 <spirobel[m]> hocuspocusoutoff: I dont think its related to integers.  the problem is the listener callback does not get called.
21:23:52 * spirobel[m] uploaded an image: (242KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/NycoGKiJDGTjxecdPgFDMFIJ/image.png >
21:24:11 <spirobel[m]> I see in the network console something is happening but I dont get the callback from the listener
21:24:34 <spirobel[m]> maybe woodser  knows something I could try  😅🙂
21:32:01 <selsta> UkoeHB: seems green now
21:52:45 <woodser[m]> I haven't tried the yield/call syntax. are you able to do more conventional await monero_wallet.addListener(listener) ?
21:55:38 <spirobel[m]> woodser[m]: yes I tried it too.
21:56:31 * spirobel[m] uploaded an image: (380KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sUlTOWrvkMDovccYWIxbiRxc/image.png >
21:57:05 * spirobel[m] uploaded an image: (218KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/czGeCaemTZDrquZaaYglnVfr/image.png >
21:57:27 <spirobel[m]> still the same result. I also added a onnewblock handler
21:58:00 <spirobel[m]> but it seems like non of the handlers get called. Maybe this is related to webasm and isolation or somthing ...
21:58:08 <spirobel[m]> s/somthing/something/
21:58:40 <spirobel[m]> Can you point me somwhere in the  monero-javascript codebase where I can dig? 
21:58:47 <spirobel[m]> s/somwhere/somewhere/
22:00:30 <spirobel[m]> or maybe it is webworker related
22:00:57 <woodser[m]> could it be that the wallet is already synced, perhaps a new wallet, and new blocks need to be added to the chain?
22:02:05 <woodser[m]> this test will print sync updates to the console: https://github.com/monero-ecosystem/monero-javascript/blob/f167d6890d0764ee7dbeb9deacc6ad1825e77961/src/test/Scratchpad.js#L46
22:02:05 <woodser[m]> npm run test -- --grep "Scratchpad"
22:03:29 <spirobel[m]> 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
22:04:20 <woodser[m]> it only fires on initial sync (doesn't apply to new wallets) and when new blocks are added to the chain
22:04:23 * spirobel[m] uploaded an image: (183KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/CISQUUYDqzmpqBHqWeTXBSVw/image.png >
22:04:41 <spirobel[m]> woodser[m]: hm...maybe on stagenet there were no new blocks
22:05:46 <spirobel[m]> 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
22:06:31 <spirobel[m]> thanks a lot for your help. Its easy to get stuck in the mud when assuming things that shouldnt be assumed haha
22:06:42 <woodser[m]> np :)
22:06:44 <Elijah[m]> Just wait 3 minutes when you can safely assume a block has been mined 
22:07:02 <Elijah[m]> Then you should see the onnewblock get called 
22:08:02 <spirobel[m]> Elijah[m]: is it also on stagenet?
22:08:59 <Elijah[m]> Stagenet is just mainnet code wise just that xmr has no fiat value. 
22:09:06 <Elijah[m]> * just that the xmr has
22:13:19 <spirobel[m]> hm..or maybe something is wrong with the daemon connection
22:17:53 <UkoeHB> selsta: yep guess it's a rare bug or oom issue