00:07:47 <m-relay> <h​egelo:matrix.org> Hi comrade
00:08:40 <m-relay> <h​egelo:matrix.org> What is going on the wallet zip in the website ? A Trojan ?  Why ?
00:09:33 <m-relay> <h​egelo:matrix.org> Trojan:Win32/Wacatac.H!ml , Trojan:Win32/Phonzy.C!ml
02:46:41 <m-relay> <j​effro256:monero.social> huh
02:47:26 <m-relay> <j​effro256:monero.social> Is your anti-virus flagging the monero binaries?
05:59:04 <m-relay> <0​xfffc:monero.social> Anybody understand why this needed:  https://github.com/monero-project/monero/pull/3412
06:52:33 <fluffypony> restrict the lookahead when creating a wallet (eg. where the hardware wallet is involved in the scanning) and then you can open it up once it's caught up?
09:28:02 <john_alan> is anyone here up to speed on the latest with Seraphis/Jamtis/FCMP?
10:03:24 <m-relay> <0​xfffc:monero.social> fluffypony thanks. Why is it necessary to restrict the lookahead?
10:04:21 <m-relay> <0​xfffc:monero.social> For example, from the comments I see it says “not waiting long time”. If we don’t restrict the lookahead, we should wait long time?
10:06:54 <m-relay> <p​lowsof:matrix.org> cc vthor for any performance impact of lookahead with a pi / his xmrsigner project
10:17:14 <vthor> how to restrict lookahead, couldn't find any switch. I this what happens on open/restore a wallet, what takes a very long time while outputs import, key images export, signing tx takes no time at all?
10:35:49 <m-relay> <s​pirobel:kernal.eu> all of these issues could be sidestepped by using integrated addresses
10:37:26 <m-relay> <p​lowsof:matrix.org> lookahead of _one_ :P
12:29:19 <m-relay> <o​frnxmr:monero.social> 🥴
12:30:36 <m-relay> <o​frnxmr:monero.social> https://docs.getmonero.org/interacting/monero-wallet-cli-reference/#restore-wallet
12:31:07 <m-relay> <o​frnxmr:monero.social> https://docs.getmonero.org/interacting/monero-wallet-cli-reference/#performance
12:32:03 <m-relay> <o​frnxmr:monero.social> `fluffypony thanks. Why is it necessary to restrict the lookahead? ` because scanning more addresses uses more resources
12:32:47 <m-relay> <o​frnxmr:monero.social> Vthor 0xfffc
12:38:00 <m-relay> <o​frnxmr:monero.social> Now, something i need to confirm:
12:38:00 <m-relay> <o​frnxmr:monero.social> > The wallet will not check for payments to subaddresses further than n away from the last received payment. This can happen if you generated unique subaddresses for n clients in a row but none of them paid.
12:38:02 <m-relay> <o​frnxmr:monero.social> is this factual? Does the lookahead also act as the "gap"?
12:40:42 <m-relay> <o​frnxmr:monero.social> I guess i could test this be sending to the 50th and 250th subaddress to see if both outputs are detected, but won't have time today. Would be great is someone else already knows the answer
12:50:23 <moneromooo> It can happen if you generate all these addresses but don't save your wallet cache (thereby forgetting those new addresses).
12:50:39 <moneromooo> "don't save" also includes monero-wallet-cli crashing or being killed hard.
12:53:44 <moneromooo> (or if gen addresses from a copy of the wallet you receive to)
14:47:58 <fluffypony> imagine you generate 50 subaddresses as people checkout
14:48:04 <fluffypony> but none of them are paid
14:48:30 <fluffypony> from your wallet's perspective those are just normal subaddresses, it doesn't conceptually understand that you're running an ecommerce business and those match 1:1 to orders
14:49:12 <m-relay> <j​akep2.0:matrix.org> Hello, I'm new here. I am seeking some answers and hoping you all may be able to help me.
14:49:29 <fluffypony> so you end up with a scenario where, during catch-up, it assumes that it only needs to scan up to the last used subaddress + some "gap" ahead (ie. a few extra subaddresses) as the NORMAL use-case for subaddresses is to actually use all of them
14:49:38 <fluffypony> hence the need to have a larger subaddress gap in some cases
14:49:58 <moneromooo> If they're about monero development, sure, go ahead. For Monero usage, ask in #monero. For pool/mining, #monero-pools (or there's another newer one IIRC, dunno the name, someone might chime in).
14:54:48 <m-relay> <j​akep2.0:matrix.org> Oh ok, Thank you for your help. I have a wallet that I have been using with no problems for a year and a half.  On the 8th of last month I attempted to deposit some Monero into it, like I had countless times before. I use this wallet as a transfer point, for lack of a better term. The customer service for the wallet that I have been dealing with has been trying to tel l me that th<clipped message>
14:54:48 <m-relay> <j​akep2.0:matrix.org> e reason my Monero is not deposited is because of a Monero update. Is there any validity to this statement?
14:56:08 <moneromooo> It depends on the details. But ask in #monero, I'll go there and try to see if I understand your problem in more detail.
14:57:31 <m-relay> <j​akep2.0:matrix.org> Okay, again I am very new here, I'm not sure how to get there. Thank you all in advance for any and all information pertaining to my situation.
14:58:00 <moneromooo> Same way you got to #monero-dev, except replace #monero-dev with #monero. Might be different but similar names in matrix.
14:58:35 <moneromooo> Oh wait, there was a bridging issue wasn't there...
14:59:27 <moneromooo> OK well, let's do it here this time. Monero hasn't had a fork in quite a while. So that's not the reason if you used the wallet recently as you suggest.
14:59:40 <m-relay> <j​akep2.0:matrix.org> um maybe. Im not sure what that means
14:59:52 <moneromooo> There was a point release recently, but bug fixes. It may be they hit a bug there. They'd have to be more explicit.
15:00:06 <moneromooo> Or they could mean they are updating the monero software and are in the middle of it.
15:00:56 <m-relay> <j​akep2.0:matrix.org> they are telling me that monero is in the middle of an update and that is why it hasnt shown up in my wallet for a month.
15:00:58 <moneromooo> Or it could be a dishonest lie.
15:01:39 <moneromooo> A month ? Well, that sounds like they're either lying of fukcing up big time.
15:02:04 <moneromooo> The recent update should be "exit monerod, restart it". No consensus changes AFAIK (or omly backward compat ones).
15:02:07 <m-relay> <j​akep2.0:matrix.org> Hello,
15:02:08 <m-relay> <j​akep2.0:matrix.org> Please consider the previously provided information.
15:02:10 <m-relay> <j​akep2.0:matrix.org> XMR is currently undergoing a scheduled upgrade.
15:02:12 <m-relay> <j​akep2.0:matrix.org> The upgrade started on July 24th and is expected to take a significant amount of time. We will inform you of our progress and notify you once it is completed.
15:02:14 <m-relay> <j​akep2.0:matrix.org> Please do not deposit XMR to your Freewallet XMR address until further notice from our team confirming that the upgrade is over.
15:02:16 <m-relay> <j​akep2.0:matrix.org> Please stay tuned and refer to our official social media accounts for further updates on the status of the XMR upgrade.
15:02:18 <m-relay> <j​akep2.0:matrix.org> Best regards,
15:02:20 <m-relay> <j​akep2.0:matrix.org> Mia,
15:02:22 <m-relay> <j​akep2.0:matrix.org> Here is the latest email. i think its a blatant lie.
15:02:25 <moneromooo> Oh, freewallet, that was a known scam wasn't it.
15:03:03 <m-relay> <j​akep2.0:matrix.org> bingo
15:03:19 <m-relay> <j​akep2.0:matrix.org> So what can I do?
15:03:20 <moneromooo> I hope I'm not confusing names...
15:03:53 <m-relay> <j​akep2.0:matrix.org> I dont think so
15:03:57 <plowsof> features in the avoid list on reddit https://www.reddit.com/r/Monero/wiki/avoid/ 
15:04:14 <moneromooo> Well, proably try to get terms with the loss of sweet monero. I don't think you can find them, they'd have been found already. It's many years old.
15:04:22 <m-relay> <j​akep2.0:matrix.org> hindsight is 20/20
15:05:13 <m-relay> <j​akep2.0:matrix.org> Things I wish I would have known sooner.🤦
15:06:03 <moneromooo> Maybe monero-wallet-{cli,gui} could include a URL to that as a "welcome" message. A bit centralized, but altogether helpful.
15:09:27 <m-relay> <o​frnxmr:monero.social> Tldr, freewallet is scam. Rip
15:10:33 <m-relay> <j​akep2.0:matrix.org> I am very sorry but I am extremely uneducated at all of this. Could you please use layman's terms.
15:11:32 <m-relay> <j​akep2.0:matrix.org> Thanks for your input, we concluded that.
15:11:50 <m-relay> <j​akep2.0:matrix.org> 😔
15:12:07 <moneromooo> My last line ? It wasn't intended for you really. I meant "show users the avoid list on monero wallet startup".
15:12:41 <m-relay> <j​akep2.0:matrix.org> oh, I understand. Thanks for your time.
15:12:54 <m-relay> <o​frnxmr:monero.social> The website is a scsm. they stole your money
15:13:03 <moneromooo> Then again, maybe most users don't even use monero-wallet-{cli,gui} before using a third party wallet, so it would not help in those cases.
15:13:27 <m-relay> <j​akep2.0:matrix.org> correct
15:13:35 <m-relay> <o​frnxmr:monero.social> Getmonero.org/downloads has some wallets that arent scams
15:14:08 <m-relay> <j​akep2.0:matrix.org> thanks
15:14:18 <moneromooo> In your particular case, where did you look that is controlled by the monero team where a warning/avoid list would have taught you about freewallet before you used it ?
15:14:47 <m-relay> <o​frnxmr:monero.social> where did you find freewallet?
15:25:26 <shillo> Where can I find info on why `save` must be called manually?
15:27:50 <moneromooo> It can take quite some time for large wallets, such as exchanges'.
15:31:03 <shillo> I assume some form of database updates happen periodically in the background. Do those accomplish the same thing as calling `save`? And since it can take a while for large wallets I assume this happens infrequently enough that `save` should be called manually as well on exit to ensure the latest state is saved before exit?
15:32:18 <m-relay> <j​akep2.0:matrix.org> I downloaded over a year and a half ago.
15:32:45 <moneromooo> The wallet does not use a database, only the node does. The wallet saves its in-memory state as a serialized stream.
15:33:07 <moneromooo> So every save saves everything, there is no incremental save possible.
15:33:54 <moneromooo> So while there is no "database updates happen periodically in the background", every new block (for example) changes that state.
15:34:13 <m-relay> <j​akep2.0:matrix.org> I didn't know there was a scam taking place. Again, I am fairly new at all of this. I was doing things based of of info I was getting from what I thought was a trusted source.
15:35:11 <m-relay> <j​akep2.0:matrix.org> 😔
15:35:52 <moneromooo> Well, if you persist with crypto currencies, always search the internet for whatever you're going to be using first. Scams abound.
15:36:13 <moneromooo> Not all will find a search hit though, but it's a good first filter.
15:38:47 <m-relay> <j​akep2.0:matrix.org> I appreciate All of the helpful info. Thank you all for your input.
15:39:03 <m-relay> <j​akep2.0:matrix.org> I appreciate all of the helpful info. Thank you all for your input.
15:43:37 <shillo> So all that calling `save` manually really does is speed up the rebuilding of the wallet state on next startup?
15:52:35 <vthor> "It can happen if you generate all these addresses but don't save your wallet cache (thereby forgetting those new addresses)." <- on XmrSigner the wallet get thrown away anyway, and next time restored, so cache also gone
15:53:57 <moneromooo> If you do not save, you lose changes you made, such as tx notes, destinations for outgoing txes, etc. You also lose the refresh "progress".
15:54:22 <vthor> " https://docs.getmonero.org/interacting/monero-wallet-cli-reference/#performance" <- doesn't work in RPC, would need to see where to path (appart from using RPC sucks anyway - on a offline signing device)
15:54:44 <moneromooo> And any subaddresses you generated, which will have to be regenerated based on incoming and lookahead, which can fail in the case above.
16:01:15 <vthor> "Then again, maybe most users don't even use monero-wallet-{cli,gui} before using a third party wallet, so it would not help in those cases." <- would me drive nuts as user, I hate all this fuzz, like I would be a monkey. When you using already monero-gui I don't think so are so prone to fall for a (wallet-)scam. It is like the endless messages you get from mobile providers and/or banks - but it doesn't change anything for possible victims only now the rest 
16:01:16 <vthor> needs to live bothered with the crap they was laughting about before (at least my POV).
16:04:26 <shillo> moneromooo: Would not that data benefit from being stored incrementally? (unsure about the refresh progress bit) 
16:04:42 <moneromooo> It would benefit from it.
16:05:08 <vthor> "And any subaddresses you generated, which will have to be regenerated based on incoming and lookahead, which can fail in the case above." <- not sure, but I think it doesn't matter at all, because the signer wallet is a cold wallet, the hot wallet (view key only), will generate all lookahead, I guess. Cold wallet needs only to care about the outputs and generate for them key images and have the info to sign the unsigned tx in my understanding...
16:05:32 <moneromooo> It was not done because it would require a fait bit of work, and some people are writing a wallet2 replacement, so any benefit would be short lived.
16:07:08 <shillo> Yea I can see that change not being simple/quick. Is any part of the wallet2 rewrite public yet?
16:09:20 <shillo> I'd be curious to see what approach is being used for wallet state persistence
16:15:12 <sneurlax> AIUI there's https://github.com/monero-project/monero/pull/9464 , not a rewrite but rather making a "feature complete" wallet2_api prior to any further work to make a new wallet api
16:15:42 <sneurlax> SNeedleWoods and rbrunner7 may have corrections for my understanding of the situation tho.
16:20:41 <m-relay> <o​frnxmr:monero.social> Moneromooo, does the lookahead (default 50:200) do both: 1. Set initial lookahead and 2. Set gap lookahead from last used address?
16:22:44 <moneromooo> AFAIK, it generates 50:200 on wallet creation, then ensures x+50 x:y+200 on each receive at x,y and each creation of x,y. Memory lapse permitting.
16:23:00 <m-relay> <o​frnxmr:monero.social> I know it does #1, but not sure about 2. The issue is having a hot wallet and a view wallet, where the view wallet may have N invoices generated and unpaid beyond the default 200, but the hot wallet is not able to view them. I'm assuming that lookahead does both 1 (initial scan) and 2 (gap from last used addr), but not sure
16:23:06 <moneromooo> "ensures" here meaning creation of anything <= that limit.
16:24:14 <m-relay> <o​frnxmr:monero.social> Ok perfect. So sounds like something like setting subaddress-lookahead 5:20000 will both scan the initial 20k AND use a gap of 20k.
16:25:14 <moneromooo> If by "gap" you mean lookahead, then... it's redundant, so maybe not... :)
16:25:45 <moneromooo> I'm not sure the distinction you intend with these two terms.
16:26:37 <m-relay> <o​frnxmr:monero.social> By gap i mean.. how far to lookahead after thr last used address
16:26:47 <moneromooo> OK, so same thing. Good.
17:09:22 <m-relay> <s​needlewoods:monero.social> @ sneurlax: rbrunner7 is the better spokesman, but iirc we (in #no-wallet-left-behind) decided that a completely new wallet API is out of scope or would take too long to finish, I don't know of any plans to make one afterwards. This journey started a while ago from jbermans proposal [here](https://github.com/seraphis-migration/wallet3/issues/64), but discussions happened in many p<clipped message>
17:09:22 <m-relay> <s​needlewoods:monero.social> laces, and quite a few things changed since then (now the general focus in development is more on FCMPs than Seraphis) so it's not always obvious what's going on.
17:11:50 <sneurlax> thanks for the clarification, SNeedleWoods
17:12:27 <sneurlax> I'm hoping that we can implement Seraphis and a new wallet API at the same time with a subsequent hardfork
17:12:41 <sneurlax> but I imagine we'll want wallet2/wallet2_api to continue existing for backwards-compatibility?
17:13:13 <sneurlax> or maybe a new implementation will continue to provide the old API endpoints
17:14:15 <sneurlax> SNeedlewoods* :P
17:14:22 <m-relay> <r​brunner7:monero.social> Yup, can confirm, I remember the same course of events as SNeedlewoods . I see it as a window of opportunity that we missed, for various reasons. Nobody really started the very difficult and challenging task of *defining* that brand-new / out on a green field API, for example.
17:15:55 <m-relay> <r​brunner7:monero.social> I would speculate that we will live with the expanded / feature complete Wallet API for the foreseeable future. IMHO you don't need a brand-new API if you put a Seraphis technological base underneath, it should be possible to expand that API "gently" for Seraphis - if we ever come around to that :)
17:16:31 <m-relay> <r​brunner7:monero.social> I don't see problem here, I don't think the decision to go for Wallet API makes implementing Seraphis later much harder.
17:19:56 <m-relay> <r​brunner7:monero.social> I still hope we will be able to go private with `wallet2`, so to say, within a reasonable timeframe, with everybody using the Wallet API exclusively. If we can't wean people off `wallet2.h`, **that** would be a serious problem for implementing Seraphis.
17:22:23 <m-relay> <r​brunner7:monero.social> In fact, that was one motivation for using Wallet API as the base and not trying to come up with something new despite being late, as I understood it: Many apps already use Wallet API, and those who don't might still get a headstart because the system and naming is similar to `wallet2.h`. Thus less friction, and less resistance.
17:24:03 <moneromooo> Why would using wallet2.h instead og wallet2_api be a serious problem for implementing Seraphis ?
17:27:15 <m-relay> <r​brunner7:monero.social> I never systematically checkd, I have to confess, but I think it's too low-level, and a lot of implementation details "leak through", and if you put a radically different implementation underneath, could be you had to fight with a lot of subtle compatibility and implementation problems. I could be wrong, however, and it just would all be very ugly :)
20:23:33 <selsta> jeffro256: can you update #9462 to also invlude the latest changes?
20:32:20 <m-relay> <j​effro256:monero.social> Yes I will do that rn
21:13:44 <m-relay> <j​effro256:monero.social> Done
21:19:16 <m-relay> <n​vmitsmatrixdotorg:matrix.org> Banhammer MOOODS @comingback:matrix.locker98.com is spreading FUD about the best hoster in the world servers.guru!!!!
22:38:56 <selsta> .merge+ 9462 9450
22:38:56 <xmr-pr> Added