<woodser[m]> "you can mine yourself to..." <- I am using the stagenet

<woodser[m]> "you can also print the height to..." <- I will try it.

* the stagenet, I guess it will have blocks added

okay it seems like the other listeners fire. But onnewblock and the sync related stuff does not work

(i send it some money from a different wallet)

s/send/sent/

maybe its because the syncing process happens too fast. Still odd though. I just had this intuition that it would at least for some event. But I mean thats okay maybe it just isnt a very chatty api.

similar to this unix philosphy: when everything is fine just shut up.

maybe I will investigate this later when I implement the recovery of old wallets.

by the way what is the difference between getransfers and getTxs?

okay now it cant find the transfer/transaction anymore...

weird.

maybe all of this weirdness is the result of me immediately saving the wallet after creating it. without even syncing or connection to a daemon. later i do openwallet with this data.

maybe that leads to messed up sync height or other weird things

just a guess

Does anyone here compile with visual studio?

Or is everyone on msys2

I guess neither :)

i use linux

likewise, I use linux. I still have a virtualbox vm with windows and msys2 on it somewhere, if needed

<moneromooo> "Of course, you lose the ability..." <- It looks like `add_subaddress` and `expand_subaddresses` would continue to work as usual, and I'm perfectly happy with the current incremental/derivative allocation mechanism for new addresses. The goal is simply to be able to stop caring about addresses when they become irrelevant (in some use-case specific way), which is to say not allocating memory for those addresses, matching

against the, firing events for incoming transactions, etc.

It is completely within bounds to have memory requirements that scale with the number of addresses that are relevant at any given time, but not for the memory requirements to scale with the number of addresses that are *or have ever been* relevant.

As I discussed with selsta before, these memory requirements are, on a per-address basis, pretty minimal, so I have already implemented a stopgap solution which simply doesn't bother about deleting old addresses for the time being.

void add_subaddress(uint32_t index_major, const std::string& label); // throws when index is out of bound

void expand_subaddresses(const cryptonote::subaddress_index& index);

<moneromooo> "I also have an old patch that..." <- I wouldn't mind having a look. Is there a particular reason this patch wasn't merged when it was fresh?

The one other consideration would be getting rid of the memory/storage used by the labels, which looks like it would require a bit more fudgery; in-memory, labels would also need to be stored as a map rather than a list. I don't care that much about serialized size, and it should be possible to do this without breaking the existing serialized wallet cache by serializing that map as a list, as it now is.

What's the history behind things being implemented as they are? I would think that this functionality would be helpful even for regular old wallet users who wish to generate a new subaddress for each incoming transfer, for example. If you are often doing `receive -> sweep` with a new subaddress for each transaction the user-facing wallet also currently becomes cluttered quite quickly.

<moneromooo> "github.com/monero-..." <- Cheers, I'll have a look.

Genuine question: Is my PR (monero-project/monero #8175) getting too big? There's 34 commits, but each are very specific and well documented (if it's not just removing unused files).

You have a patch for each file you remove ? I just looked at the one line messages, it looks like it.

okay I think I solved the puzzle. I created the wallet from a random mnemonic. then saved the wallet data. then connected to the daemon. with setdaemon. then later on i reopen from this data. I assume syncheight is not set. but it seems like it gets implicitly set now to the end of the chain ( maybe through the setdaemonconnection after (re)opening the wallet. I will investigate) then I do the sync and the response to getheight is higher

but (but still not the same to getSyncheight ... this one still puzzles me) ....TLDR: make sure you your syncheight makes sense. it might be implicitly set somewhere and sync wont throw any errors to warn you of this. You can not just assume that is set to the right thing)

s/you//

I think it was this description that led me down the path of paranoia. It seems like this listener fires as new blocks are processed by the wallet syncing code. theoretically you can say it fires when a new block is created because that will lead to a new block being processed. But that might not actually be the case. For me it didnt fire because my syncheight was set somewhere implicitly to something weird. So it never fired even as

newblocks were created.

this led to some mild existential dread because the assumptions didnt seem to fit reality 😅😆🤣 but I survived haha 🥰

the assumption is that the restoreheight of createwallet when creating a random wallet is the blockheight at the time when the wallet was created. The issue is that I didnt supply a daemon uri directly and did setdeamonconnection after saving the wallet file. At this point there is no way for createwallet to know what the current blockheight is. So I manged to hit the edge case where the the syncheight/restoreheight of the wallet is the

one and (re)opening time. Because syncheight was set implicitly somewhere.

s/and/at/

would be interesting to find out where. Any ideas?

moneromooo Yeah most of the times, but sometimes if they're related, I'll delete them all together in one commit

moneromooo But sometimes I do make logical changes like in monero-project/monero #8175/commits/9a59b131c4ed1be8afe238fff3780fe203c65a46

* Any ideas? EDIT: It seems like it is set to 1056219 in the openwallet even though open wallet does not have the servuri. maybe it is set to this value even earlier. This would also explain why getheight was below getSyncheight even after syncing. It seems like syncheight is set to something in the future randomly somewhere.

* Any ideas? EDIT: It seems like it is set to 1056219 in the openwallet even though open wallet does not have the servuri. maybe it is set to this value even earlier. This would also explain why getheight was below getSyncheight even after syncing. It seems like syncheight is set to something in the future randomly somewhere. EDIT2: okay it seems to be set on wallet creation to something in the future.

Are you creating a new wallet and getting a value of refresh-from-block-height that's higher than the chain actually is ?

Your names are all wonky but it sounds like it.

moneromooo: yes. I think this is what is going on. I will pass serveruri to it and see if there is a difference

If the wallet is not connected to the daemon, it can't know what the chain height is, so it makes a guess. Due to huge hash rate variations, guesses on testnet are bad.

github.com/monero-ecosystem/monero-…/js/wallet/MoneroWalletFull.js#L234 it goes form this to this: github.com/monero-ecosystem/monero-…ain/cpp/monero_wasm_bridge.cpp#L173 and then into this:

github.com/monero-ecosystem/monero-…wallet/monero_wallet_full.cpp#L1063 it says indeed something about set_refresh_from_block_height i dont know if it is actually this codepath. The daemon info is all "" emptied out so it might short circuit some where before. Or you are saying it makes a guess somehow?

sounds cool

but maybe a warning or leaving it unset would be good too

I would be interested to see the guess code. would be glad for a link 🥰

rbrunner: could you review this? monero-project/monero #8195

wallet2.cpp, /:estimate_ (IIRC)

If you don't set a daemon, it'll default to 127.0.0.1:18081 (modulo port if testnet).

<moneromooo> "If you don't set a daemon, it'll..." <- what if there is no daemon running? in my case it would be like this. It still guesses a number? Why is this number not left unset?

If there is no daemon running, the connection will fail, as you might expect. It'll guess.

It is not left unset for performance. If unset, it'd have to scan all txes from the start of the chain. There are a lot.

moneromooo: but it can also lead to situation where it be set to something in the future like in this case which will break all sorts of assumptions.

If that was a question, yes.

moneromooo: in this case it will set the height to 1056219 it seems like this number is static. It does this without daemon connection. I dont run a daemon locally.

It should go up by one every two minutes. If it does not, then it's probably not what is happening.

moneromooo: the create wallet did not get fed a serverUri. So its pulling this number from somewhere. I cant quite pin down where it comes from. But its happening without a connection to a daemon.

s/create/createwallet()/, s/wallet//

the TLDR is this: createWallet() will let you create a wallet without a serveruri (reard: daemon connection). it will randomly set a syncheight that might be in the future. It is essentially this offline wallet described here: github.com/monero-ecosystem/monero-…eveloper_guide/view_only_offline.md

s/reard/read/

Interestingly, I haven't yet gotten `monero-wallet-rpc` to use above ~50% utilization on one core...even when trying to add subbaddrs 10000 at a time. It just takes forever.

must be doing a lot of IO then

spirobel: The network targets a fixed block rate per time, so it basically guesses based on when "now" is.

yesterday in social i was talking about storj and how it would be nice to see a service like that that used xmr. anyone here an expert in that kinda stuff?

storj is a decentralized cloud storage for those who dont know

hocus pocus out of focus: Well, it's not quite clear, but this is running over loopback, so I don't think it should be IO bound unless it is flushing the wallet cache to disk after every address. I'm certainly not explicitly telling it to do that.

Re: Storj, you would be happy if they accepted Monero as payment, or something deeper?

i would like it to be built on xmr

storj themselves wont do that, they exist to pump their own shitcoin

How would you envision something like that working?

people with extra disk space run a daemon to reserve that space for the cloud network. people who want to use cloud space pay xmr to access it. some magic happens and that xmr gets distributed to providers of cloud space

not really sure how the magic part would work. like i said im not an expert in this area

A bastard system could be to use the credit system. Mine to a daemon offering that service, building up credits. As long as you pay for time * space, the daemon keeps your data.

You'd need to build the server than manages the data, but monerod would handle all the monero side already.

And it's only "decentralized" insofar as you select some node in the set of those that offer such a service, it would not be distributed.

(though you can pay more nodes to keep the same data for availability).

And of course you have no guarantee the service offerer will keep their side of the bargain (hence the availability above).

Kind of a crutch, but possible without micropayment chain spam.

right im more thinking of all disk space providers get thrown into some kind of generic pool of disk space, and the client's files can be anywhere in that pool (maybe offer some kind of built-in redundancy too)

storj only pays providers if they maintain a certain uptime

You could build a program than auto directs your miner to mine to several nodes offering this service, and keeping your data on every one of them.

sure but say im just some avg joe who wants cloud storage. i should be able to acquire xmr however i want then pay that xmr to access cloud

<moneromooo> "And it's only "decentralized..." <- Would using ipfs help here?

* Would using ipfs help here?... (full message at libera.ems.host/_matrix/media/r0/do…089a0d2dc98b82d4267a7aa7848dcf86bb4)

* Would using ipfs help here?... (full message at libera.ems.host/_matrix/media/r0/do…6988854db43933f9622c498910f4986e023)

imo no node should ever know what data it holds. everything is e2e encrypted

<merope> "That's not obfuscation, and..." <- What happens to an individual who sends/spends their entire balance?

Then the whole balance (minus the tx fee) goes into a single output destined for the recipient

Though iirc there's now a second "dummy" empty output in every tx in that case, so that there's always at least two outputs - to make such transactions harder to distinguish

<merope> "Though iirc there's now a second..." <- Thank you for the reply. I think I saw something about this "second dummy/empty output" when I was reading a medium article about how people are trying to profile the origin of the tx spike in July of 2021. Based on your reply and that article I take 2 outputs to be the minimum even for whole spends, as the people working on that issue started their profiling at 2 outputs and more,

there was not data point for single output transactions.

hocus pocus out of focus: What you want doesn't really have anything to do with Monero other than that you want to be able to pay with Monero. I'm not clear why you don't like Storj other than it's not Monero. Would you like Filecoin better? The same service could be built atop that. These coins were designed with proof-of-storage as the baseline, because storage is what they are intended to do. Thus they do a good job of providing

reliable, yet decentralized storage in exchange for their coin. Monero was built with completely different requirements in mind. Why not find a way that fits your privacy requirements to swap Monero for a coin that does storage, if you want storage?

the problem with these coins are that you can only spend them to buy the product that you by-definition dont need because youre a provider. theyre scam coinsd

s/coinsd/coins/

"just swap" is absurd

i dont swap my fiat dollars for target gift cards every time i want to shop at target

and i never said it "had to do with monero." i asked if there are any experts in this arena that would be interested in building a solution based around monero payments

dunno why you guys get so defensive

<hocuspocusoutoff> "i dont swap my fiat dollars..." <- Perhaps because your fiat dollars are already sufficiently private and Target accepts them?

<hocuspocusoutoff> "the problem with these coins are..." <- Maybe you could elaborate on this...

ok i host storj space and i collect storj-coins. what can i buy with storj-coins? space in the storj cloud... which i provide...

Ah, yes, you've discovered the great conundrum of blockchains, I suppose. Why would Ethereum miners want more ETH, if all they can do with ETH is buy more computation on the Ethereum blockchain?

no, the conundrum of ShitCoins and ScamCoins. but a coin that has all the properties of money (xmr is the only one i know of), can be used as money if people offer goods and services for it. im proposing a possible service to offer and asking if there are any people with the expertise necessary to help build it

* the expertise and desire necessary to

if this channel is for monero core dev only, rather than dev work related to monero, thats fine you can just say that

no need to have a drawn out pointless convo