-
m-relay_
<ofrnxmr:monero.social> If you must use the same seed with multiple wallet-rpc instances, i'd use subaccounts instead of subaddresses
-
DataHoarder
^ subaccounts (except account 0 that has main address at index 0) logically limit how mixing addresses work, and that lets you have multiple deposit/change addresses per user
-
DataHoarder
note subaccounts or subaddresses within the subaccount are limited to uint32 on current implementation
-
DataHoarder
uint32+uint32. This is relevant if you want to have many users.
-
darkwolf93
given uint32+uint32 index space, what operational ceilings have you seen (wallet cache size / scan time) for accounts × subaddresses before it gets painful?
-
darkwolf93
also, DataHoarder, if I run multiple wallet-rpc instances from the same seed, is the recommended pattern to restore into separate wallet files and give each instance a disjoint account (major) range to avoid overlap in change/spend selection?
-
DataHoarder
I have implemented view wallets directly (from a programming perspective) and the wallet scan is more or less, viewkey lookup per tx, then checks a hashmap
-
DataHoarder
the hashmap has all tracked subaddresses
-
DataHoarder
that allows you to get the account/offset index
-
DataHoarder
different seeds require repeating this process anew
-
m-relay_
<ofrnxmr:xmr.mx> yes, re multiple wallet files with same seed but different accounts
-
DataHoarder
each account will have its own change/spend selection, yes
-
m-relay_
<ofrnxmr:xmr.mx> but dont need a new wallet-rpc for each account
-
m-relay_
<ofrnxmr:xmr.mx> You can just pass the account in the json req
-
m-relay_
<ofrnxmr:xmr.mx> 1 wallet-rpc would be fine unless you need to send more than like, 1tps
-
DataHoarder
the hashmap is composed of 32 bytes for the key, and 8 (4+4 bytes for the account/offset) value
-
DataHoarder
you can probably have a low lookahead per user (then programmatically increase it as needed)
-
m-relay_
<ofrnxmr:xmr.mx> But if you are using multiple wallet rpcs, make sure they are designated to only touch certain accounts. Meaning wallet-rpc 1 only touches account 1-9999, wallet-rpc2 only touches account 10000-19999 erc
-
DataHoarder
monero does the same > std::unordered_map<crypto::public_key, cryptonote::subaddress_index> subaddresses;
-
m-relay_
<ofrnxmr:xmr.mx> @datahoarder, if users are creating new addresses manually, then you shouldnt need the lookahead at all
-
DataHoarder
exactly
-
DataHoarder
same for accounts, it's effectively increased
-
DataHoarder
with that, you can establish a lower bound in requirements in loaded indices ^
-
DataHoarder
(32+8
-
DataHoarder
(32+8) * (number of users * average subaddresses per user) bytes
-
DataHoarder
even considering all users (uint32) are used, with one subaddress each, that's 160 GiB of data
-
DataHoarder
map overhead will make it go above that, ofc
-
darkwolf93
thanks guys, appreciate the guidance
-
m-relay_
<merano:matrix.org> Test
-
m-relay_
<merano:matrix.org> What DEXes you suggest for swapping Monero?.. I use Fixed float
-
m-relay_
<ofrnxmr:xmr.mx> ERROR: not development related; Try [#monero:monero.social](https://matrix.to/#/%23monero:monero.social)
-
m-relay_
<btcxmrfan:matrix.org> Please don't continue using FF. They are know to retain customer funds pending an onerous KYC process. They are rated BAD in kycnot.me and not even listed in Orangefren.com. Find another option from orangefren.com or use trocador.app to choose a better rated exchange
-
m-relay_
<btcxmrfan:matrix.org> Please don't continue using FF. They are known to retain customer funds pending an onerous KYC process. They are rated BAD in kycnot.me and not even listed in Orangefren.com. Find another option from orangefren.com or use trocador.app to choose a better rated exchange
-
m-relay_
<ofrnxmr:xmr.mx> Please dont continue to use this room
-
m-relay_
<ofrnxmr:xmr.mx> and a correction: they are, in fact, listed in orangefren and trocador
-
m-relay_
<btcxmrfan:matrix.org> Apologies if this is not the right place
-
m-relay_
<btcxmrfan:matrix.org> Not in orangefren. I just checked once again. Fixed float is not listed
-
m-relay_
<handpickencounter:matrix.org> when monerod tx-proxy=tor,... do separate transactions go to different peers over different tor circuits?
-
m-relay_
<ofrnxmr:xmr.mx> No
-
m-relay_
<ofrnxmr:xmr.mx> There is ofc a more complete amswer than that, but in short: no, stream isolation per tx is not used
-
m-relay_
<handpickencounter:matrix.org> is there a way to enable it? restarting tor after every transaction is an option but why...
-
m-relay_
<handpickencounter:matrix.org> is there a way to enable it? restarting tor before every transaction is an option but why...
-
m-relay_
<handpickencounter:matrix.org> how long lived are the connections monerod forms to other peers? tor circuits have a 15 minute lifetime by default but if the connection it kept open the circuit lives indefinitely and there isn't an easy way to kill it without restarting tor.
-
m-relay_
<weaverethan:matrix.org> Hey everyone. I'm having some trouble with my monero cold storage wallet. I was trying to sign a transaction offline and broadcast it from a view only wallet and i seem to have messed something up. I got an error about a double spend and now when i restore my wallet with the private spend key vs a watching only wallet there is a 20xmr difference in balance. I think this has to do <clipped message>
-
m-relay_
<weaverethan:matrix.org> with my key image marking my outputs as spent when they aren't? On the full spend key wallet its not showing 2 of the incoming transactions that i am able to see on my view only wallet. If anyone is able to help me fix this id really appreciate it. Ive been trying for a couple days
-
m-relay_
<binarybaron:matrix.org> Cuprate may have it