the older the wallet, the less relevant the restore height

because the number of blocks that restore height lets you skip will be less than the number of blocks that need to be scanned

so IMO this is a lot of fuss to insert a solution that won't make a difference in the long run

having a separate restore height causes quite a lot of support requests, tevador's seed scheme would be nice

doesn't it introduce something not great?

imo, this could be addressed on the UX / UI side . if the user wants to use the restore height, do some checks and then always just do half a million blocks lower or something.

<selsta> "having a separate restore height..." <- Yeah I guess I don't understand what the downsides are... Upside is users wouldn't need to remember what year they created a wallet. Seems like a huge win. I have numerous wallets and i find it silly that i have to keep track of this oddball piece of information with each seed. I guess in the long run there's a non-zero chance a user won't set their block height back far

enough and that will essentially burn coins and pump the price to infinity. 🤷

04:54 <gingeropolous[m]> doesn't it introduce something not great? <-- what do you mean?

+1 for encoding the height in the seed. It simplifies UX and is not complicated to support.

i thought i remember reading that one of tevador's things introduced some kerfuffle , but i guess this wasn't it

Feather Wallet has supported Tevador's seed scheme with embedded restore date for over a year now: docs.featherwallet.org/guides/seed-scheme

Well, that's amazing.

<tobtoht> "Feather Wallet has supported..." <- Are there any clear downsides to this scheme? My smooth brain obviously wants to know if using 14 words results in a lower entropy seed

tobtoht: Off-topic, but Feather Wallet should arguably be added to the downloads page

crypto_grampy[m]: See the discussion starting here: monero-project/monero #6639#issuecomment-642926305

dEBRUYNE: I'm releasing 1.0.0 either TODAY or tomorrow. I was just about to contact you regarding this. ^^

We can ask the community about their opinion. I am sure almost everyone will be in favor

(Regarding the Reddit sidebar that is. Someone opened a PR open for getmonero that I'll comment on shortly.)

Ok cool

<tobtoht> "crypto_grampy: See the discussio..." <- Excellent. Really agree with this comment: "1) is certainly unfortunate from an UX point of view, but I think we should take the long view here. If Monero really is successful as a currency it will probably live on for many years, if not decades, and all the wallets and all the users of the few years that already passed will become a small and therefore more and more

unimportant minority over time."

sgp_: how many support tickets does Cake get about block height restore stuff / how come my funds are gone when i restore my wallet

Hundreds

and how many will they get when monero becomes as popular as SHIB in a few weeks

feather restore wallet UI, FYI

Does the 14 words retain the entropy of the 25 words by considering more than 3 letters of each word? Or is some kind of actual magic?

The brainwallet UX for a 14 word seed would make my life easier haha

UkoeHB: do you have a few moments to help explain 73 to me? It's not clear to me how it works, but obviously the ability to speed up scan times considerably is interesting to me

People erroneously entering the restore height is probably one of the most common issues

sgp_: to check if you own an output, you do several crypto operations in series. The view tag proposal is to take the result of the first crypto op and record the first byte next to an output. When you are checking the output, if your computed view tag doesn't match the recorded view tag, then you give up. This lets you skip the other crypto op steps, which are expensive, for _most_ outputs you don't own (only 1/256 unowned

outputs will randomly match your computed view tag - forcing you to do the other crypto op steps to fully check them).

Or being confused by the restore height parameter

More technically, the view tag is produced from a hash of the first crypto op result, so that the view tag doesn't reveal any important bits that can weaken output security.

so you slip this byte in, resulting in the first verification check (or an early one) throwing a STOP sign in most cases and allowing you to skip the rest of the verification for most of the transactions?

I believe we can get another ~1-3% speedup if we can use a cheaper hash function for computing view tags.

yes

I'm not overlooking any transaction distinguishability downsides here then, right? The only downside is just the 1 extra byte?

Right

Observers can't use the view tag to learn anything

This is the easiest trade in the history of trades, holy cow

ship it

haha indeed, ship ship ship :)

I remember discussing a feature like this a few years ago on reddit, yet the prevailing opinion was that this feature would have increased tx distinguishability somehow

Nice to see the change in direction

Well the idea has been sitting in the MRL issue bank for 1.5yrs. Needs someone to implement it

Regarding "a hash of the first crypto op": is there a chance that this may actually reveal something vulnerable?

merope: there is another way to speed up tx scanning (by WAY more). Simply, record a 1 byte user ID with outputs.

This would split the userbase into 256, meaning you only need to check 1/256 outputs are yours.

UkoeHB: I remember this one, not the issue 73. No idea how I missed 73

Like, if we assume (hypothetically) that the result of this computation gets revealed/broken somehow - how bad would it be? (If at all)

merope: no, it is a different hash from the one used to construct outputs (in my latest PoC)

UkoeHB: Yes, but introducing user IDs *is* bad because now they become tied to the identity of the user, and not just a random number popping out of a computation

I'm just saying... that is the only other idea that has been discussed.

Ah, that might have been it then

I do like the idea of the hash of the first step of the verification process - you pay a small extra price but you get to skip the rest of the hard work most of the time. It's a nice tradeoff

As long as the result of this operation does not weaken tx/user privacy, it's an awesome feature

yes, this will have a huge benefit to wallet users, especially more-casual users that sync infrequently (a lot of those use Cake)

This idea would only work for new blocks added to the blockchain right? It wouldn't go back and add view tags to pre-hardfork blocks?

tikwanleap[m]: correc

t

No, that would invalidate previous block hashes and solutions

got it

<tobtoht> "crypto_grampy: See the discussio..." <- Would this style seed be potentially compatible with a Trezor/Ledger style wallet? I'm assuming not really?