17:56:19 <br-m> <r4v3r23> @rbrunner7:monero.socialyoure handling polyseed implementation?
17:59:40 <br-m> <rbrunner7> @r4v3r23:monero.social: Yes
18:00:16 <br-m> <rbrunner7> In the Monero core software, the CLI wallet and hopefully later also in the GUI wallet, though I am not sure my Qt knowledge will be up to the task there
18:00:43 <br-m> <r4v3r23> @rbrunner7: is there a PR?
18:01:01 <br-m> <r4v3r23> tobtoht wrote a WIP patch a couple of years ago that works
18:01:50 <br-m> <rbrunner7> No, not yet progressed far enough to PR. Standing maybe at 70%
18:02:39 <br-m> <rbrunner7> Yes, after consulting with tobtotht I took that patch (which is now alive as code in monero-c) and modified it gently
18:03:23 <br-m> <r4v3r23> @rbrunner7: ok great. is the plan to add it during the hardfork or is it coming before?
18:04:00 <br-m> <rbrunner7> Not sure. I don't think something will prevent this PR going in before the hardfork to FCMP++
18:04:20 <br-m> <rbrunner7> Didn't yet discuss any "plan" with selsta however
18:04:38 <br-m> <r4v3r23> has there been a decision on seed encryption? legacy offset vs PS's built in passphrase?
18:05:40 <br-m> <rbrunner7> Well, I have a proposal that I now implement, and when I PR, people can certainly comment: Support encrypted Polyseeds when restoring, but not producing any encrypted Polyseeds and working only with seed offsets
18:06:49 <br-m> <r4v3r23> not sure if polyseed's built in encryption was even shipped in the wild
18:06:55 <br-m> <r4v3r23> but that seems like a good balance
18:07:43 <br-m> <rbrunner7> It's active in Cake Wallet: If you create a wallet and give a passphrase, it generates an encrypted Polyseed. But I think that was the only source of such seeds that I ever saw
18:08:31 <br-m> <r4v3r23> lol
18:08:35 <br-m> <r4v3r23> yeah
18:08:46 <br-m> <rbrunner7> Yeah, why not :)
18:08:49 <br-m> <r4v3r23> heads up: getSeed() doesnt play nice after stopBackgroundSync(), spoke the jberman about it
18:09:22 <br-m> <rbrunner7> You mean that looks like a bug in the current release code?
18:09:46 <br-m> <r4v3r23> in the current version of tobtohts patch + release bg sync code
18:10:19 <br-m> <r4v3r23> theres a hotfix but well have it reviewed with your PR i guess
18:10:35 <br-m> <rbrunner7> Ah, I see. Then it's probably a good idea that I have a look. Sounds strange that these 2 things should be connected somehow, but everything is possible
18:10:38 <br-m> <r4v3r23> ah wait
18:10:42 <br-m> <rbrunner7> A hotfix against what?
18:10:47 <br-m> <r4v3r23> thats on the bg sync side
18:10:59 <br-m> <r4v3r23> but itll need the polyseed PR to get a proper fix in
18:11:26 <br-m> <rbrunner7> Maybe @jberman:monero.social knows already more details and can chime in
18:12:02 <br-m> <r4v3r23> i mixed up, the bug is on bg sync since it was obviosuly written without PS in mind
18:12:20 <br-m> <r4v3r23> its only present on polyseed wallets tho
18:14:53 <br-m> <rbrunner7> I wonder a bit how monero-c's story will continue after we have Polyseed support as regular part in the Monero core code. That library supports 3 coins, Monero, Wownero and Zano. Now supporting those 3 coins work in pretty similar ways, however after my addition differences will grow
18:15:15 <br-m> <rbrunner7> It's based anyway on a pretty old version of the Monero core code, that's not a very good story if you ask me
18:16:15 <br-m> <rbrunner7> It probably does not matter too much, because it's only for wallet apps, and not that much happened in wallet2 and nearby code, but still
18:17:25 <br-m> <jberman> Basically just need to be sure to properly bring the polyseed back in memory when stopping background sync > <@rbrunner7> Maybe @jberman:monero.social knows already more details and can chime in
18:18:02 <br-m> <rbrunner7> The Polyseed? Not just the spend private key?
18:18:18 <br-m> <rbrunner7> Polyseed or not Polyseed, there is only ever a single spend private key, no?
18:19:16 <br-m> <jberman> I guess depends on the impl, but presumably yes. The bug was that starting background sync clears spend key + polyseed, and then only spend key was brought back properly but not the polyseed
18:19:55 <br-m> <rbrunner7> You mean the Polyseed as it's part of the Account object as instantiated by wallet2?
18:20:05 <br-m> <r4v3r23> @rbrunner7: private key is fine, yo ucan still spend after, its just displaying the actual seed phrase that crasehs it
18:20:51 <br-m> <jberman> The bug in that patch was that forget_spend_key would also clear where the polyseed was kept in memory
18:20:58 <br-m> <rbrunner7> Ah, I see, the Polyseed has to go in the interest of security
18:21:26 <br-m> <jberman> And then it wasn't properly brough back into memory
18:22:40 <br-m> <rbrunner7> I see. Is there a "hotfix" from you that I could incorporate?
18:22:43 <br-m> <jberman> Probably does make sense to clear while background syncing. Extra info not exactly critical for background sync to function
18:24:25 <br-m> <r4v3r23> @rbrunner7: http://git.anonero5wmhraxqsvzq2ncgptq6gq45qoto6fnkfwughfl4gbt44swad.onion/ANONERO/monero/commit/a6ea01e2f826733595acc5989ff0d1809d20f4a2
18:24:28 <br-m> <jberman> I don't know if you're keeping the polyseed in the same place in memory as the other polyseed patch is, so I'm not sure if it would apply to your code. The other code was keeping it stored in the account keys same place as private spend key, so it's also stored in the .keys file
18:25:08 <br-m> <rbrunner7> Yes, that's the approach. I did not deviate from that
18:25:11 <br-m> <jberman> This was my proposed fix (the hotfix won't work for all cases, should only work for anonero / "unattended" walles):
18:25:25 <br-m> <rbrunner7> Thanks to you both, will certainly have a look.
18:25:55 <br-m> <jberman> one sec
18:26:05 <br-m> <rbrunner7> One more thing? :)
18:28:13 <br-m> <jberman> the more optimal fix is:
18:28:13 <br-m> <jberman> A) recover cryptonote::account_keys from verify_password rather than the secret spend key alone (so that you also recover the polyseed)
18:28:13 <br-m> <jberman> B) if m_polyseed, verify the recovered polyseed is correct (probably by verifying that it corresponds to the priv spend key) in addition to the checks already done that the priv spend key corresponds to the pub spend key [I actually don't know if this is possible to do, probably isn't and I wrongly assumed so]
18:28:13 <br-m> <jberman> C) have m_account.set_spend_key also take the polyseed as an optional param where if provided, set polyseed also
18:29:18 <br-m> <jberman> "in addition to the checks already done that the priv spend key corresponds to the pub spend key" -> this is referring to the checks already done in stop_background_sync
18:30:19 <br-m> <rbrunner7> Ok, might take some work for me to read into everything, but I am optimistic that I will find a good. Man, it's high time we solve Polyseed once and for all as core part of the regular Monero code ...
18:30:24 <br-m> <rbrunner7> *good solution
18:32:29 <br-m> <r4v3r23> @rbrunner7: definitely looking forward to this
18:33:56 <br-m> <rbrunner7> I hope that MrCyjaneK will come around to modify monero-c to use it. The solution for wallet apps that are based on that library is of course not complete until then.
18:36:04 <br-m> <rbrunner7> Maybe it won't be too hard - continue to use the "patch approach" for Wownero and Zano and stop to use any patch for the Monero part?
18:37:34 <br-m> <rbrunner7> Hey, I feel pressured by all those thanks and upvotes emojis :)
18:38:09 <br-m> <rbrunner7> I guess now I have to deliver
19:36:43 <br-m> <rbrunner7> 6.8 times faster wallet sync is coming :) https://old.reddit.com/r/Monero/comments/1t6jq1v/i_modified_the_original_monero_wallet_for/
19:37:34 <br-m> <jpk68:matrix.org> I didn't know monerod had gRPC :P
19:37:54 <br-m> <rbrunner7> They are talking about using Cuprate instead
19:38:08 <br-m> <jpk68:matrix.org> Ah, my bad
19:38:28 <br-m> <rbrunner7> But I think that hasn't gRPC for wallet sync either out of the box?
19:38:41 <br-m> <rbrunner7> Maybe they vibe-coded it ...
19:44:52 <br-m> <boog900> Yes they AI'd the rest of the RPC endpoints and then added gRPC
19:45:09 <br-m> <boog900> On our old too DB btw 
19:46:45 <br-m> <jpk68:matrix.org> Would be cool to have CBOR or something. gRPC is kind of bloated
19:47:35 <br-m> <rbrunner7> @boog900:monero.social: Are you in contact with them?
19:47:50 <br-m> <boog900> no I think this is their fork 
19:47:51 <br-m> <boog900> https://github.com/tex8com/cuprate/tree/fast-rpc
19:47:58 <br-m> <boog900> I saw it a week or so ago 
19:48:13 <br-m> <boog900> also this: https://github.com/tex8com/cuprate/tree/fast-rpc
19:48:31 <selsta> from what I remember out current wallet sync code is quite slow so it seems plausible they got a large speedup
19:48:35 <br-m> <boog900> my bad: https://github.com/tex8com/monero-gui/tree/fast-crypto
19:48:53 <br-m> <jpk68:matrix.org> Lmao, they wrote tests in C++ > <@boog900> https://github.com/tex8com/cuprate/tree/fast-rpc
19:49:14 <plowsof> cover all bases 
19:52:23 <br-m> <rbrunner7> Hmm. Let's see where this all leads us.
19:54:58 <br-m> <boog900> I am surprised the AI managed to get it working tbf 
19:55:01 <br-m> <rbrunner7> The truth is in solid, working, production quality code, anyway.
19:55:45 <br-m> <boog900> it looks like it was just allowed to rip with little input 
19:56:38 <br-m> <rbrunner7> I wonder whether it really works. I mean, whether it syncs correctly if there are received enotes.
19:56:57 <br-m> <rbrunner7> Not only that it munches through all the blocks in record time.
20:00:13 <br-m> <boog900> Yeah I wouldn't be surprised if there are many bugs
20:01:02 <br-m> <rbrunner7> Might be these people behind that Cuprate fork: https://tex8.com/
20:01:46 <br-m> <rbrunner7> "In days, not months" :)
20:03:05 <br-m> <rbrunner7> Sometimes I wish I was a startup guy for just a few weeks. Promise the sky, get noticed, get people raving about what you will build, collect some millions from venture capitalist, burn through that, vanish ...
20:05:07 <br-m> <boog900> I think I am most annoyed about them using our old DB, the new one is so much better
20:05:18 <br-m> <rbrunner7> Lol
20:05:28 <br-m> <boog900> https://github.com/tex8com/monero-gui/tree/fast-crypto#best-performance-use-with-cuprate-node
20:05:35 <br-m> <rbrunner7> I understand, but frankly, that would be the last thing on my mind :)
20:06:05 <br-m> <rbrunner7> Confronted with these claims
20:06:34 <br-m> <boog900> what claims?
20:06:51 <br-m> <rbrunner7> The speedup claims, like 46x for some steps of syncing
20:07:28 <br-m> <rbrunner7> But hey, maybe we really should explore things like pruning txs on the fly and zipping RPC traffic on the fly seriously
20:08:14 <br-m> <rbrunner7> And aggressive batching of things
20:10:06 <br-m> <jpk68:matrix.org> Cap'n Proto (which I think bitcoind uses for some things) is supposedly ~75% smaller and up to 10x faster
20:10:22 <br-m> <jpk68:matrix.org> Also a lot more memory-efficient, of course
20:11:18 <br-m> <rbrunner7> Yes, there certainly is no lack of RPC protocols and libraries. Nobody really takes you seriously as a dev until you designed and built one as well
20:18:40 <br-m> <boog900> we should have them beat daemon side with the new DB for normal RPC. That one 46x speed up by making 6,600 calls 1 isn't even a different call for us now, it's joined to the block blobs request, so it's all 1 single DB request now. > <@rbrunner7> The speedup claims, like 46x for some steps of syncing
20:19:37 <br-m> <boog900> The bugs they mentioned that slowed sync I had already fixed 
20:30:31 <br-m> <boog900> If they just used the new DB the only speed up there would be gRPC I think
20:31:36 <br-m> <boog900> The pruning on the fly thing was just because the old DB did no pruning at all and always returned full blobs 
20:32:21 <br-m> <boog900> The new does separate pruned/prunable blobs and supports returning just pruned blobs