<rottenwheel:unredacted.org> geonic maybe I'll just block you. say hi to your lookalike ofrn on the other side, garden gnome. bye-bye.

<rottenwheel:unredacted.org> thanks to the new bridge you can block individual irc accounts on matrix. love you DataHoarder[m] tks.

:)

<rottenwheel:unredacted.org> @jbabb:cypherstack.com: where does that post-quantum turnstile thing from @jeffro256:monero.social fall into regular polyseed vs. polyseed++? have you seen?

<rottenwheel:unredacted.org> it was shared in latest revuo. one sec.

<rottenwheel:unredacted.org> this: gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

<rottenwheel:unredacted.org> also, this: stacker.news/items/1356557

<rottenwheel:unredacted.org> ah... lol > <@jbabb:cypherstack.com> sorry, it should be "classic++ seeds", not polyseed++

<rbrunner7> @rottenwheel:unredacted.org: As far as I know the seed should not matter. That turnstile does not care about the way you used to build your private spend key bits.

<jbabb:cypherstack.com> Sorry for mixing my terminologies: “polyseed++” is my made up term for polyseed+carrot, which as I understand it will incorporate the pq turnstile > <@rottenwheel:unredacted.org> @jbabb:cypherstack.com: where does that post-quantum turnstile thing from @jeffro256:monero.social fall into regular polyseed vs. polyseed++? have you seen?

<jbabb:cypherstack.com> The classic seeds should also

<jbabb:cypherstack.com> “Classic++” is another made up term for a hypothetical seed extension to embed restore height and some additional to-be-presently-unused feature/upgrade bits

<ofrnxmr:xmr.mx> Why wpuld u need classic++?

<ofrnxmr:xmr.mx> Polyseeed exists

<ofrnxmr:xmr.mx> Classic++ sounda like "polyseed with 10+ more words"

imma gunna see how many 25 word seeds I can memorize

<jbabb:cypherstack.com> @ofrnxmr:xmr.mx: what, do you hate security??

<ofrnxmr:xmr.mx> ?

<jbabb:cypherstack.com> polyseed is 128 bits. I bought my bits, I want my bits

<ofrnxmr:xmr.mx> 25 isnt more secure than 16

<jbabb:cypherstack.com> quantum computers might make the difference negligible in the future

<ofrnxmr:xmr.mx> Isnt the private key 128bits

more bits but still polyseed is secure

<jbabb:cypherstack.com> practically, 128 bits is fine

<jbabb:cypherstack.com> no, it's below 128 bits. yes polyseed IS secure

compatibility is key

<jbabb:cypherstack.com> I prefer it for usability but would prefer 26-28 word classic seeds with an extension for blockheight so it's all contained

<ofrnxmr:xmr.mx> Roght/ so how os a 4664567 bit seed more secure than the private key?

<jbabb:cypherstack.com> another issue is that I can't convert all my old 25-word seeds to 16-word polyseeds

<jbabb:cypherstack.com> not all classic keys can be represented in the new scheme. that's a major usability gap for me: i want to be able to "upgrade" any classic seeds by embedding a restore height

<jbabb:cypherstack.com> polyseed doesn't achieve this (personal) requirement

<ofrnxmr:xmr.mx> Your okd seeds wont have pfs etc

<ofrnxmr:xmr.mx> U cant upgrade your seeds to carrot keys w/o generating new wallets

<jbabb:cypherstack.com> so?

<jbabb:cypherstack.com> old seeds can be upgraded with the simple addition of an embedded restore blockheight

<jbabb:cypherstack.com> that doesn't regen the new carrot keys, no

<jbabb:cypherstack.com> it doesn't have to

<ofrnxmr:xmr.mx> Sounds like a waste of time

<jbabb:cypherstack.com> it's a waste of time to gen the carrot keys for restore purposes before its activation height anyways

<jbabb:cypherstack.com> sounds like you hate the users

<ofrnxmr:xmr.mx> If youre storing an extra 3 words, why not store the height (1 word)

<jbabb:cypherstack.com> ofrnxmr: Enemy of the User

<ofrnxmr:xmr.mx> Joshbadd inventing problems

<jbabb:cypherstack.com> i will consider your opinions valid if you can get rotten and geonic to agree

<ofrnxmr:xmr.mx> f you make the seed even 1 word longer, its no different than wroting dowm the restore height

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: i lol'd

<jbabb:cypherstack.com> saving abandon...abandon1234567 is the current "solution"

<jbabb:cypherstack.com> how much time and energy is wasted by syncing from 0 for so many classic seeds?

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: Abandon...abandon<hashword of restoreheight> is the proposed

<jbabb:cypherstack.com> with some extra words for extra bits which will initially be unused, yes

<jbabb:cypherstack.com> why do we even have a mnemonic phrase? why not just save the keys?

<ofrnxmr:xmr.mx> Cuz u need multiple keys + address to restore

<jbabb:cypherstack.com> depending on the key...

monero uri supports a list of txids for wallet restoration and "almost instant" syncing , which is more convenient for the user. if they want to do arts and crafts they can hand scribble a QR code

<ofrnxmr:xmr.mx> after fcmp you csnt "skip sync" anymore

<ofrnxmr:xmr.mx> So it would do full sync from the earliest txid

no rct sync

the monero gui has a pdf for people to put their restore height on :(

<jbabb:cypherstack.com> I do like monero uris, plowsof, and that does include everything I need... thanks for the reminder

<jbabb:cypherstack.com> I just want polyseed functionality with the ability to represent (directly 1-to-1 convert) all my old seeds

<jbabb:cypherstack.com> the only real issue with monero uris is adoption at this point

<jbabb:cypherstack.com> ... but polyseed suffers on that point as well.

<ofrnxmr:xmr.mx> Dont we have a height param on uris

so txid list will be deprecated in fcmp, no one likes the user. would a uri still be possible to reduce sync times under fcmp++?

<ofrnxmr:xmr.mx> @jbabb:cypherstack.com: How?

<jbabb:cypherstack.com> (tho polyseed > uris in an adoption sense)

<jbabb:cypherstack.com> @ofrnxmr:xmr.mx: yes

<jbabb:cypherstack.com> monero uri wallet restores just aren't very widely supported afaik

<jbabb:cypherstack.com> plowsof: checking

<ofrnxmr:xmr.mx> Only by modifying the restore height

<ofrnxmr:xmr.mx> Thentree building has to be sequential, so u cant just scan in txs

<ofrnxmr:xmr.mx> So the earliest txid would set the restore height and it woukd sync normalltly from that point

<jbabb:cypherstack.com> tree building needs to be sequential from the restore point but can be jumpstarted w init_tree_sync_data

<jbabb:cypherstack.com> plowsof: no, txid lists via uri will not help speed up syncs post-fcmp++, at least not with the current code and i'm not sure that it's feasible anyhow

<jbabb:cypherstack.com> there is a manual scan_tx path but it's not for future txs, just for rescanning txs at or below the current sync height

<jbabb:cypherstack.com> key image exports still exist in fcmpland...

<jbabb:cypherstack.com> it does

<jbabb:cypherstack.com> key image export/import can help speed wallet sync. looks like key images could feasibly speed restores unless i'm mistaken. haven't had coffee yet so it's all a bit of a blur

<jeffro256> You definitely can theoretically "skip sync", its just not supported by the wallet at the moment since its kinda complex > <@ofrnxmr:xmr.mx> after fcmp you csnt "skip sync" anymore

<ofrnxmr> I was told (maybe i misunderstood) that you can't because of tree building

<jeffro256> Yeah the tree building makes that code a lot more complicated , but it should still be possible with more or less the same trust assumptions

<jeffro256> For scan_tx specifically, which I think is what youre talking about, we made the choice to not support "future scans" since they would encounter that enote anyways upon a normal refresh , so the complexity wasn't worth it

<plowsof:matrix.org> @loop.ster:matrix.org: hello, under what account name? manual approval is needed for accounts who login via a 3rd party or emails fail to get through

<rottenwheel:unredacted.org> selsta xcancel.com/MoneroSpace/status/2029272604675018996

ty for sharing

<souljaboy2007:matrix.org> 👋

<intr:unredacted.org> anyone have any luck with monero android POS apps on those special android terminals with a printer and such?

<intr:unredacted.org> I wonder which device to go with, as the Alacrity isn't very easy to get in EU

<intr:unredacted.org> and when I looked deeper there's all sorts of brands with dodgy listings and names

<agorise:matrix.org> @intr:unredacted.org: why buy a specialized device? just use a tablet with cake wallet on it or something

<agorise:matrix.org> cake wallet let's you request specific amounts in your local currency from the customers too

<intr:unredacted.org> yeah I know about wallet apps, I'm asking about point of sale apps like Kasisto, XMRpos, etc. on point of sale terminals

<intr:unredacted.org> I think they're cool and I think presentation matters

<intr:unredacted.org> I feel like in-person payment flow is a little too overlooked and could use more attention

<agorise:matrix.org> cool cool 👍️

<hbs:matrix.org> Has anybody used Gummo's nevercast.app service?

<321bob321> @intr:unredacted.org: Ajs question