02:28:02 <hyc> the older the wallet, the less relevant the restore height
02:28:25 <hyc> because the number of blocks that restore height lets you skip will be less than the number of blocks that need to be scanned
02:28:51 <hyc> so IMO this is a lot of fuss to insert a solution that won't make a difference in the long run
02:49:08 <selsta> having a separate restore height causes quite a lot of support requests, tevador's seed scheme would be nice
02:54:52 <gingeropolous[m]> doesn't it introduce something not great?
02:55:57 <gingeropolous[m]> 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.
03:32:57 <crypto_grampy[m]> <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
03:32:57 <crypto_grampy[m]> enough and that will essentially burn coins and pump the price to infinity.  🤷
03:51:51 <selsta> 04:54 <gingeropolous[m]> doesn't it introduce something not great? <-- what do you mean?
18:37:56 <BusyBoredom[m]> +1 for encoding the height in the seed. It simplifies UX and is not complicated to support. 
18:49:30 <gingeropolous> i thought i remember reading that one of tevador's things introduced some kerfuffle , but i guess this wasn't it
19:13:32 <tobtoht> Feather Wallet has supported Tevador's seed scheme with embedded restore date for over a year now: https://docs.featherwallet.org/guides/seed-scheme
19:26:45 <crypto_grampy[m]> Well, that's amazing.  
19:42:03 <crypto_grampy[m]> <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 
19:43:43 <dEBRUYNE> tobtoht: Off-topic, but Feather Wallet should arguably be added to the downloads page
19:44:07 <tobtoht> crypto_grampy[m]: See the discussion starting here: https://github.com/monero-project/monero/issues/6639#issuecomment-642926305
19:44:46 <tobtoht> dEBRUYNE: I'm releasing 1.0.0 either TODAY or tomorrow. I was just about to contact you regarding this. ^^
19:46:42 <dEBRUYNE> We can ask the community about their opinion. I am sure almost everyone will be in favor
19:46:55 <tobtoht> (Regarding the Reddit sidebar that is. Someone opened a PR open for getmonero that I'll comment on shortly.)
19:47:44 <dEBRUYNE> Ok cool
20:05:54 <crypto_grampy[m]> <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
20:05:54 <crypto_grampy[m]> unimportant minority over time."
20:08:31 <crypto_grampy[m]> sgp_: how many support tickets does Cake get about block height restore stuff / how come my funds are gone when i restore my wallet
20:11:22 <sgp_> Hundreds
20:11:37 <crypto_grampy[m]> and how many will they get when monero becomes as popular as SHIB in a few weeks
20:19:16 * crypto_grampy[m] uploaded an image: (86KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/HMPuhLSshmQqfITSvYxFxOnM/image.png >
20:19:22 <crypto_grampy[m]> feather restore wallet UI, FYI
20:26:23 <carrington[m]> 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?
20:26:56 <carrington[m]> The brainwallet UX for a 14 word seed would make my life easier haha
20:39:59 <sgp_> 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
20:44:00 <dEBRUYNE> People erroneously entering the restore height is probably one of the most common issues
20:44:02 <UkoeHB> 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 
20:44:02 <UkoeHB> outputs will randomly match your computed view tag - forcing you to do the other crypto op steps to fully check them).
20:44:15 <dEBRUYNE> Or being confused by the restore height parameter
20:45:27 <UkoeHB> 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.
20:45:55 <sgp_> 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?
20:46:04 <UkoeHB> I believe we can get another ~1-3% speedup if we can use a cheaper hash function for computing view tags.
20:46:17 <UkoeHB> yes
20:47:07 <sgp_> I'm not overlooking any transaction distinguishability downsides here then, right? The only downside is just the 1 extra byte?
20:47:16 <UkoeHB> Right
20:47:27 <UkoeHB> Observers can't use the view tag to learn anything
20:47:40 <sgp_> This is the easiest trade in the history of trades, holy cow
20:47:59 <tobtoht> ship it
20:48:13 <sgp_> haha indeed, ship ship ship :)
20:48:59 <merope> 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
20:49:18 <merope> Nice to see the change in direction
20:49:19 <UkoeHB> Well the idea has been sitting in the MRL issue bank for 1.5yrs. Needs someone to implement it
20:50:26 <merope> Regarding "a hash of the first crypto op": is there a chance that this may actually reveal something vulnerable?
20:50:27 <UkoeHB> merope: there is another way to speed up tx scanning (by WAY more). Simply, record a 1 byte user ID with outputs.
20:50:55 <UkoeHB> This would split the userbase into 256, meaning you only need to check 1/256 outputs are yours.
20:51:04 <sgp_> UkoeHB: I remember this one, not the issue 73. No idea how I missed 73
20:51:33 <merope> Like, if we assume (hypothetically) that the result of this computation gets revealed/broken somehow - how bad would it be? (If at all)
20:51:34 <UkoeHB> merope: no, it is a different hash from the one used to construct outputs (in my latest PoC)
20:52:45 <merope> 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
20:53:05 <UkoeHB> I'm just saying... that is the only other idea that has been discussed.
20:53:20 <merope> Ah, that might have been it then 
20:54:40 <merope> 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
20:55:47 <merope> As long as the result of this operation does not weaken tx/user privacy, it's an awesome feature
20:59:23 <sgp_> yes, this will have a huge benefit to wallet users, especially more-casual users that sync infrequently (a lot of those use Cake)
20:59:52 <tikwanleap[m]> 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?
21:00:36 <UkoeHB> tikwanleap[m]: correc
21:00:38 <UkoeHB> t
21:00:42 <merope> No, that would invalidate previous block hashes and solutions
21:00:50 <tikwanleap[m]> got it
22:06:38 <crypto_grampy[m]> <tobtoht> "crypto_grampy: See the discussio..." <- Would this style seed be potentially compatible with a Trezor/Ledger style wallet?  I'm assuming not really?