<plowsof[m]> "ErCiccione meeting tomorrow..." <- chairperson for meeting should be able to be unbiased or competent, it isn't the case with this candidate

i planned to run it anyway as i will be the one who has to do the release work...

selsta: is it about cli release or gui + cli ?

the meeting won't be about gui

then cli release is completely automated process as soon as code is ready

* then cli release is completely automated process once code (commit/branch/tag) is ready

I'm available to moderate the meeting if people want, but if selsta prefers to do it that's fine too 🙂

How is the Noise IK implementation in Monero going? I see on Github vtnerd is or was working on it.

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

<plazma> i think network privacy improvement will be more important in coming days as surveillance system improves

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?

The latter (mostly).

mostly?

Almost only. There's a one day leeway or so where both will be accepted.

right. so all outputs in current wallets have to be re-created after the actual hard fork date to benefit from viewtags

To... be able to rescan the chain fast ? It would not work.

what would not work?

You'd have to re-mine everything from scratch, and allow view tags from before the fork.

Recreating current outputs to have view tags.

moneromooo: no i meant current outputs that already exist

sweep_all today to self, new restore height = today (to benefit from viewtags)

plowsof[m]: this was my question, when to sweep outputs

on v.018 release or after the actual fork

why do you say today?

I guess I do not understand the point, so I'll shut up.

today as in after harrdfork

moneromooo: we have to update outputs to add viewtags to them correct?

aka re-spend/sweep

You can't add view tags to existing outputs.

plowsof[m]: right. thanks

Spending creates *new* outputs.

moneromooo: you would by creating a new outputs

I mean, you can do that, but I see no point in it, beyond "oh, cool I have an outout with a view tag".

OK, this is stupid. I'll shut up again.

(though if someone who knows more about view tags sees a point in this, please let me know)

Person A who has restore height of 0 will not 'sync his wallet 40%~ quicker' ~ only outputs after hardfork blockheight will sync '40% quicker'

plowsof[m]: right, so if you want that benefit, all your outputs need to be created after the hardfork blockheight

Viewkeys of decoys are visible onchain? How does one spend a old output with no viewtags ? Selecting only decoy outputs which have no viewtags?

View keys are not on the chain. Spending pre viewtags outputs is done the same way as spending outputs with view tags.

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.

The outputs are the same as htey were before, hte wallet can just early out when before it could not. No other change.

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).

The "spend it all to yourself and set a new refresh height" case has nothing to do with view tags.

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.

So the above discussio, if I understand it correctly, makes no sense.

(except the "Person A who has restore height..." from plowsof[m], which is correct but has nothing to do with view tags)

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 ?

moneromooo: so there's no benefit to updating a wallet to have viewtag outputs?

None AFAIK.

yes i am confusing ' block ' with 'outputs' thanks moneromoo (the block now has a slightly different json output monero-ecosystem/monero-python #113#issuecomment-1104551705

the block.. not the output.. doh

That sentence lost me :D

Oh, I see. Kinda the same. Blocks will sync faster *because* output scanning will be faster.

The wallet really only scans outputs. That's the overwhelming bulk of its work.

<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

Got it.

you're saying thats not the case? that we can just leave wallets as-is

I am saying that.

r4v3r23: youre not in #monero-community-dev:monero.social ? Come join

Is this about... development of monero related stuff, but not monero itself ?

Meh, empty anyway. Guess it's only on matrix.

moneromooo: Its coming to IRC 🫠 promise haha

Sounds about accurate.... a place for all of our side projects, xmr.sh, Termux node, hotshop, spiros web wallet etc

Nice, looks like a lot of new stuff I'd never heard of.

<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 ?

Damn Element. No threads on reply 😬

Like this?

<ofrnxmr[m]1> "Like this?" <- I was replying to a post much earlier. So, out of context, and probably answered by some later.

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?

*someone later

It will benefit wallets syncing post fork blocks.

Whether created before or not.

So, no benefit in sweeping my piconeros into a new wallet, with a current restore height. That what's I was wondering.

None that relates to view tags.

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.

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

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

Maybe it's easier to just see it as "from the fork, monero uses faster crypto".

+1

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.

Okay Moo, I'll go with your answer. You just said "Dude, don't worry"

In your case, old and new wallets would process blocks at the same speed (within pedantry limits). Both and after the fork.

Both before and after the fork.

They'd both get faster after it.

(per output)

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.

<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

<moneromooo> "Maybe it's easier to just see it..." <- right, and my original question was how to best benefit from it

You do not have to do anything in particular to benefit from it.

New outputs will get new tags (unless they don't in the day's leeway, but close enough).

s/new tags/view tags/

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.

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

The new ones. Since the outputs in your wallet also also on the chain, but you know what I'm saying.

OK, that last sentence makes me think you still didn't get it.

jberman[m]: halp ? :D

Anyway, about the exact timeline, even if it doesn't matter wrt sweeping:

- release

i will just do what jberman suggested since anyway viewtags scanning only kicks in after the hardfork

- fork <- from that point, outs with view tags are allowed, but not mandatory

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.

- one day after fork <- from that point, view tags are mandatory

Legacy blocks (assuming you mean before the fork) are not affected.

One or two people shifting their churns by a few days isn’t going to impact scanning by more than a few milliseconds.

Just do what you normally do

UkoeHB: But it's a start, right?

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

(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)

So, viewtags are only beneficial when the pool of users is "large enough" ? New transactions only.

TrasherDK[m]: basically all new wallets after the fork

I guess. If you have few users, your wallet scan will be fast anyway.

Again, old wallets also benefit to the same tune.

If the pool size matters, shouldn't we encourage migrating to a post fork restore height?

By pool, you mean overall number of monero users, right ? Or number of txes per block or the like ? Not the actual txpool ?

view tags work for everyone syncing after the fork

no need to sweep funds to have a new restore height

Must the the half dozenth time this is said, and yet it gets ignored...

if anything, mass sweeping will slow down sync because of increased transaction count

*slow down sync for everyone

Okay. I get it. I'll just STFU. But thank you for your time.

+1

when i pass a full path to openWallet() it doesn't work correctly

when i pass "/path/to/wallet" wallet2 can't use "/path/to/wallet.keys" if it is not in current directory