00:48:33 <ooo123ooo1234567> <plowsof[m]> "ErCiccione meeting tomorrow..." <- chairperson for meeting should be able to be unbiased or competent, it isn't the case with this candidate
01:31:23 <selsta> i planned to run it anyway as i will be the one who has to do the release work...
01:31:44 <ooo123ooo1234567> selsta: is it about cli release or gui + cli ?
01:32:13 <selsta> the meeting won't be about gui
01:32:45 <ooo123ooo1234567> then cli release is completely automated process as soon as code is ready
01:32:58 <ooo123ooo1234567>  * then cli release is completely automated process once code (commit/branch/tag) is ready
06:27:21 <ErCiccione> I'm available to moderate the meeting if people want, but if selsta prefers to do it that's fine too 🙂
06:49:37 <Siren[m]> How is the Noise IK implementation in Monero going? I see on Github vtnerd is or was working on it.
09:20:24 <ErCiccione> btw we were talking about calling a meeting after the audit is done recently and didn't organize it for this weekend before of monerokon. Makes sense to have one single meeting for multisig and release
09:50:30 <bridgerton[m]> <plazma> i think network privacy improvement will be more important in coming days as surveillance system improves
12:39:46 <r4v3r23[m]> re: view-tags, will they be present in all outputs created on v0.18 and be ready for use after the actual fork height? or only will only outputs created after the fork have them?
12:42:13 <moneromooo> The latter (mostly).
12:42:47 <r4v3r23[m]> mostly?
12:43:18 <moneromooo> Almost only. There's a one day leeway or so where both will be accepted.
12:47:02 <r4v3r23[m]> right. so all outputs in current wallets have to be re-created after the actual hard fork date to benefit from viewtags
12:48:04 <moneromooo> To... be able to rescan the chain fast ? It would not work.
12:48:56 <r4v3r23[m]> what would not work?
12:48:56 <moneromooo> You'd have to re-mine everything from scratch, and allow view tags from before the fork.
12:49:10 <moneromooo> Recreating current outputs to have view tags.
12:49:45 <r4v3r23[m]> moneromooo: no i meant current outputs that already exist
12:49:59 <plowsof[m]> sweep_all today to self, new restore height = today (to benefit from viewtags)
12:50:44 <r4v3r23[m]> plowsof[m]: this was my question, when to sweep outputs
12:50:45 <r4v3r23[m]> on v.018 release or after the actual fork
12:50:58 <r4v3r23[m]> why do you say today?
12:51:01 <moneromooo> I guess I do not understand the point, so I'll shut up.
12:51:06 <plowsof[m]> today as in after harrdfork
12:51:33 <r4v3r23[m]> moneromooo: we have to update outputs to add viewtags to them correct?
12:51:40 <r4v3r23[m]> aka re-spend/sweep
12:52:15 <moneromooo> You can't add view tags to existing outputs.
12:52:20 <r4v3r23[m]> plowsof[m]: right. thanks
12:52:22 <moneromooo> Spending creates *new* outputs.
12:52:44 <r4v3r23[m]> moneromooo: you would by creating a new outputs
12:53:00 <moneromooo> I mean, you can do that, but I see no point in it, beyond "oh, cool I have an outout with a view tag".
12:53:21 <moneromooo> OK, this is stupid. I'll shut up again.
12:54:39 <moneromooo> (though if someone who knows more about view tags sees a point in this, please let me know)
12:55:00 <plowsof[m]> Person A who has restore height of 0 will not 'sync his wallet 40%~ quicker' ~ only outputs after hardfork blockheight will sync '40% quicker'  
12:56:09 <r4v3r23[m]> plowsof[m]: right, so if you want that benefit, all your outputs need to be created after the hardfork blockheight
12:58:01 <nikg83[m]> Viewkeys of decoys are visible onchain? How does one spend a old output with no viewtags ? Selecting only decoy outputs which have no viewtags?
12:58:49 <moneromooo> View keys are not on the chain. Spending pre viewtags outputs is done the same way as spending outputs with view tags.
12:59:51 <moneromooo> I think there is a general misunderstanding of what view tags are here. Hopefully it's not me. AFAIK view tags are a very small part of an intermediary state when checking an output for whether it's going to the scanning wallet.
13:00:20 <moneromooo> The outputs are the same as htey were before, hte wallet can just early out when before it could not. No other change.
13:01:12 <moneromooo> So spending an output just so you can get another that has a view tag is pointless. The only thing you've done is that the new output can be earlied out before (which it won't be, since it's really for you).
13:01:42 <moneromooo> The "spend it all to yourself and set a new refresh height" case has nothing to do with view tags.
13:02:24 <moneromooo> And spending your coins to make an out with view tags just adds a pointless output on the chain, unless you intended to do that even if view tags weren't a thing.
13:02:54 <moneromooo> So the above discussio, if I understand it correctly, makes no sense.
13:03:27 <moneromooo> (except the "Person A who has restore height..." from plowsof[m], which is correct but has nothing to do with view tags)
13:04:11 <moneromooo> And if you don't self spend, you'll still sync new blocks faster, even if you have old outs. That might be what is causing hte confusion ?
13:04:12 <r4v3r23[m]> moneromooo: so there's no benefit to updating a wallet to have viewtag outputs?
13:04:22 <moneromooo> None AFAIK.
13:05:11 <plowsof[m]> yes i am confusing ' block ' with 'outputs' thanks moneromoo (the block now has a slightly different json output https://github.com/monero-ecosystem/monero-python/issues/113#issuecomment-1104551705
13:05:19 <plowsof[m]> the block.. not the output.. doh 
13:05:56 <moneromooo> That sentence lost me :D
13:06:22 <moneromooo> Oh, I see. Kinda the same. Blocks will sync faster *because* output scanning will be faster.
13:07:00 <moneromooo> The wallet really only scans outputs. That's the overwhelming bulk of its work.
13:17:47 <r4v3r23[m]> <moneromooo> "And if you don't self spend, you..." <- yes. i thought we had to create new outputs with viewtags to benefit from faster syncing
13:19:27 <moneromooo> Got it.
13:20:08 <r4v3r23[m]> you're saying thats not the case? that we can just leave wallets as-is
13:21:54 <moneromooo> I am saying that.
13:34:34 <ofrnxmr[m]1> r4v3r23: youre not in #monero-community-dev:monero.social ? Come join
13:35:28 <moneromooo> Is this about... development of monero related stuff, but not monero itself ?
13:36:24 <moneromooo> Meh, empty anyway. Guess it's only on matrix.
13:40:08 <ofrnxmr[m]1> moneromooo: Its coming to IRC 🫠 promise haha
13:40:08 <ofrnxmr[m]1> Sounds about accurate.... a place for all of our side projects, xmr.sh, Termux node, hotshop, spiros web wallet etc
13:43:07 <moneromooo> Nice, looks like a lot of new stuff I'd never heard of.
14:08:37 <TrasherDK[m]> <r4v3r23[m]> "this was my question, when to..." <- plowsoft: Wouldnt that be: sweep_all to a post-fork wallet, making the current height the restore height ?
14:10:15 <TrasherDK[m]> Damn Element. No threads on reply 😬
14:14:32 <ofrnxmr[m]1> Like this?
14:21:34 <TrasherDK[m]> <ofrnxmr[m]1> "Like this?" <- I was replying to a post much earlier. So, out of context, and probably answered by some later.
14:24:20 <TrasherDK[m]> I'm trying to wrap my head around those viewtags. They will not benefit already synced wallets, but will speed up syncing new wallets, right?
14:25:24 <TrasherDK[m]> *someone later
14:26:44 <moneromooo> It will benefit wallets syncing post fork blocks.
14:26:52 <moneromooo> Whether created before or not.
14:29:08 <TrasherDK[m]> So, no benefit in sweeping my piconeros into a new wallet, with a current restore height. That what's I was wondering.
14:30:03 <moneromooo> None that relates to view tags.
14:32:52 <TrasherDK[m]> Okay. I'm lost. What's the benefit of those tags. I did read some of the GitHub stuff, but most passed over my head.
14:33:12 <jberman[m]> If you sweep after fork, and then in the future want to import your seed into a new wallet and need to rescan the chain from a restore height, then you can choose a restore height from the height you sweep, and would always leverage the benefit of view tags when rescanning from a restore height
14:33:47 <jberman[m]> If you plan to use the same wallet forever, the sweep has no benefit, because your wallet will already have done all the scanning it needs to up until the fork height, and all future scanning after fork height leverages the benefit of view tags already
14:35:10 <moneromooo> Maybe it's easier to just see it as "from the fork, monero uses faster crypto".
14:35:23 <jberman[m]> +1
14:36:06 <TrasherDK[m]> Okay. I think I was specific in saying a new wallet, noticing the new restore height. I get that a already synced wallet will only benefit going forward, whatever that benefit might be.
14:38:08 <TrasherDK[m]> Okay Moo, I'll go with your answer. You just said "Dude, don't worry"
14:39:02 <moneromooo> In your case, old and new wallets would process blocks at the same speed (within pedantry limits). Both and after the fork.
14:39:24 <moneromooo> Both before and after the fork.
14:39:36 <moneromooo> They'd both get faster after it.
14:39:47 <moneromooo> (per output)
14:43:06 <TrasherDK[m]> Okay. You put my mind back to sleep. I'm not worrying about those wallets, that didn't have transactions for the last 2-3 years, and haven't been synced for a while. I can do a bash script syncing those things, when I get sober.
14:45:56 <r4v3r23[m]> <jberman[m]> "If you sweep after fork, and..." <- this is what i was trying to understand. so you DO need to create new outputs to get the viewtags
14:47:13 <r4v3r23[m]> <moneromooo> "Maybe it's easier to just see it..." <- right, and my original question was how to best benefit from it
14:49:21 <moneromooo> You do not have to do anything in particular to benefit from it.
14:50:03 <moneromooo> New outputs will get new tags (unless they don't in the day's leeway, but close enough).
14:50:42 <moneromooo> s/new tags/view tags/
14:51:12 <moneromooo> But, in case that's waht you think, the speedup does not come from the outputs in your wallet, it comes from the outputs on the chain.
14:51:38 <r4v3r23[m]> moneromooo: i know, and i was asking when this will happen (starting at v0.18 release or after the fork height) so i know when to sweep
14:51:43 <moneromooo> The new ones. Since the outputs in your wallet also also on the chain, but you know what I'm saying.
14:52:13 <moneromooo> OK, that last sentence makes me think you still didn't get it.
14:52:29 <moneromooo> jberman[m]: halp ? :D
14:53:26 <moneromooo> Anyway, about the exact timeline, even if it doesn't matter wrt sweeping:
14:53:29 <moneromooo> - release
14:53:40 <r4v3r23[m]> i will just do what jberman suggested since anyway viewtags scanning only kicks in after the hardfork
14:53:47 <moneromooo> - fork   <- from that point, outs with view tags are allowed, but not mandatory
14:53:55 <TrasherDK[m]> Does this optimization impact legacy blocks? I got stuff from like Cryptonight mining, a while back. Just to free my mind, I'll churn those into 0.01 transactions, into a new wallet, after the fork, and the first 2 minor point releases.
14:53:57 <moneromooo> - one day after fork <- from that point, view tags are mandatory
14:54:24 <moneromooo> Legacy blocks (assuming you mean before the fork) are not affected.
14:54:53 <UkoeHB> One or two people shifting their churns by a few days isn’t going to impact scanning by more than a few milliseconds.
14:55:10 <UkoeHB> Just do what you normally do
14:55:48 <TrasherDK[m]> UkoeHB: But it's a start, right?
14:57:16 <jberman[m]> The only benefit for this action is if you expect to need to restore your wallet at some point (and you have very old outputs). If you don't expect to restore your wallet, then you shouldn't do anything you'll get no added benefit
14:58:21 <moneromooo> (and the above only applies if you restore with a recent refresh height, and, again, is orthogonal to whether view tags exist, or when they started being used if they do exist)
15:00:26 <TrasherDK[m]> So, viewtags are only beneficial when the pool of users is "large enough" ? New transactions only.
15:00:42 <r4v3r23[m]> TrasherDK[m]: basically all new wallets after the fork
15:00:59 <moneromooo> I guess. If you have few users, your wallet scan will be fast anyway.
15:01:31 <moneromooo> Again, old wallets also benefit to the same tune.
15:02:25 <TrasherDK[m]> If the pool size matters, shouldn't we encourage migrating to a post fork restore height?
15:03:12 <moneromooo> By pool, you mean overall number of monero users, right ? Or number of txes per block or the like ? Not the actual txpool ?
15:03:46 <sech1> view tags work for everyone syncing after the fork
15:04:14 <sech1> no need to sweep funds to have a new restore height
15:04:43 <moneromooo> Must the the half dozenth time this is said, and yet it gets ignored...
15:04:49 <sech1> if anything, mass sweeping will slow down sync because of increased transaction count
15:05:05 <sech1> *slow down sync for everyone
15:06:30 <TrasherDK[m]> Okay. I get it. I'll just STFU. But thank you for your time.
15:08:39 <r4v3r23[m]> +1
23:43:02 <MeowingCat> when i pass a full path to openWallet() it doesn't work correctly
23:53:32 <MeowingCat> when i pass "/path/to/wallet" wallet2 can't use "/path/to/wallet.keys" if it is not in current directory