Seraphis wallet workgroup meeting #65 - Monday, 2024-04-08, 18:00 UTC

<rbrunner7> Meeting time. Hello! https://github.com/monero-project/meta/issues/987
<SNeedlewoods> hey
<rbrunner7> Matrix / matrix.org problems persist. Thus please beware.
<one-horse-wagon> Hello
<jberman> hello
<dangerousfreedom> Nah, that should work for all systems. I messed something that works only for me probably. SNeedlewoods  also tested and worked. I will try a few things here and let you know.
<rbrunner7> Thanks, dangerousfreedom
<dangerousfreedom> Hi :)
<rbrunner7> Do we also have jeffro256 around? Maybe after some gentle ping :)
<rbrunner7> So what is there to report from the week that passed?
<SNeedlewoods> yes wallet3_transfer_demo2 worked for me on linux mint 21.2
<rbrunner7> I didn't do much, just belatedly trying to compile danger's wallet demo, which seems to have a problem on my system
<SNeedlewoods> fixed all failing tests and feel stupid because it took so long, but I'm glad I solved it on my own lol
<jberman> woot, congrats
<rbrunner7> Nice. Doing it yourself probably has the best learning effect :)
<SNeedlewoods> there is still one TODO left https://github.com/UkoeHB/monero/pull/40/files#diff-26e5d9b89856333eb9c4e55b0c4a24341d7a41528c56d1de4502d5e323f7d38bR103, koe suggested to pipe the tx era, but I don't know from where (only found `TxEraSp`)
<rbrunner7> If hard-earned
<SNeedlewoods> my first idea to just compare current block index with hard-coded block height from RingCT hardfork doesn't work (see linked TODO) and this method would also mess with the tests
<SNeedlewoods> so before I start to introduce even more code I'd like to hear your feedback
<dangerousfreedom> Nice! What was it? Did you push the updates? I spent half a day last week trying to solve and could not find the problem :p
<jberman> me: async scanner is now ready for review (link: https://github.com/UkoeHB/monero/pull/23), finishing up benchmarks atm
<SNeedlewoods> df you can see in this commit https://github.com/UkoeHB/monero/pull/40/commits/09972fc8516286fbbd07d1e71aad55420bbe2f0a that I unwrapped to `LegacyContextualEnoteRecordV1` where I actually should unwrap to V2
<rbrunner7> I guess that's quite a tough piece of code for review?
<rbrunner7> (that async scanner)
<SNeedlewoods> I "reviewed" the first three commits of the async scanner, will take a while until done
<rbrunner7> SNeedlewoods: And nowhere was anything where the compiler didn't like what you did? Sounds somehow surprising.
<jberman> the first 11 commits are fairly tame. The 12th commit that intros the actual async scanner is probably the most difficult to review
<dangerousfreedom> From my side, I was trying to figure out what we can do to get as fast as possible to regtest. I guess it would be possible to play with the rpc client/server and add some methods to the lmdb database so we can store blocks with seraphis txs.
<rbrunner7> Can you please quickly explain what exactly you mean with "regtest"? I somehow can't get a handle on this.
<SNeedlewoods> (not seraphis related) I also reviewed https://github.com/monero-project/monero/pull/9151 thanks to rbrunner for the bump it now has 4 reviews
<SNeedlewoods> and did my first PR to monero-project/monero
<rbrunner7> I guess to much of this the answer is "introduce the new transaction class", no?
<rbrunner7> From there much should automatically just work in the daemon, I would suspect
<SNeedlewoods> "And nowhere was anything where the compiler didn't like what you did? Sounds somehow surprising." it's quite possible I missed some warnings
<dangerousfreedom> Well, I believe we have a basic code to transfer enotes between wallets but I'm using a MockLedger. The idea is to save these txs into the lmdb database (from which I can also get legacy enotes) and play transfer any enote between the wallets.
<dangerousfreedom> I dont know yet exactly it should be done but I know things could be fairly easily serialized and stored in the db (which I was imagining to be much more difficult).
<dangerousfreedom> Yes, I believe the best would be to create some kind of transaction class that handles both
<rbrunner7> I think jeffro256 worked already towards that to quite some degree
<dangerousfreedom> Yes, jeffro256 would do a lot of the hard work :p
<rbrunner7> Alright then :)
<rbrunner7> Decided, next meeting point ...
<dangerousfreedom> Well, I believe we have a basic code to transfer enotes between wallets but I'm using a MockLedger. The idea is to save these txs into the lmdb database (from which I can also get legacy enotes) and transfer any enote between the wallets.
<dangerousfreedom> I dont know yet exactly how it should be done but I know things could be fairly easily serialized and stored in the db (which I was imagining to be much more difficult).
<jberman> If I had a vote on this, I'd vote try to shoot for the wallet2 replacement first before Seraphis regtest, but the regtest is work that has to be done eventually too
<jberman> The daemon eventually has to recognize, verify, store, and serve Seraphis txs. Agree a new transaction class would do heavy lifting for that, but not the only piece there
<jberman> I will also add: over the medium term, I'm leaning toward switching personal coding focus to kayabaNerve's proposal for FCMP's
<rbrunner7> Say again how you people arrive at the term "regtest". I think I am missing something trivial.
<rbrunner7> What is "reg" standing for?
<dangerousfreedom> https://monero.stackexchange.com/questions/13668/what-is-regtest
<rbrunner7> Ah, ok, I see.
<dangerousfreedom> Basically what jberman is doing by testing the scanner. Mining blocks to a specific wallet in a regtest (local) network.
<jberman> I think what I will try to do over the next week is dig deeper into the task of replacing wallet2 with the Seraphis lib enote store, and reusing the CLI/RPC/wallet API
<jberman> Hopefully I can make headway that makes it clearer how that can be moved forward with by others too while I'm focused on FCMP's
<rbrunner7> If nobody has any pressing general subject to discuss today, I would like to learn about the sentiment, and the plans of the attending people regarding their future engagement in the light of the arrival of FCMP implementation work.
<rbrunner7> jberman already kind of announced, not very surprisingly, that he will lean soon towards that work instead of Seraphis work.
<jberman> I'll still do PR review over here and participate in discussions / meetings
<dangerousfreedom> I first need to understand it. I would love to do so and to contribute but I cant in the short term. I fully support its development. Luckly everything can be done in parallel.
<rbrunner7> So for you this may develop into some "Odysseus an the sirens" situation? I am convinced that FCMPs can be a very fascinating subject, and the work to bring them to Monero very interesting
<SNeedlewoods> I plan to mainly contribute to seraphis and maybe get more into monero, so far this takes up all my capacities and I don't know much about FCMPs and nothing about rust, therefore no intentions to switch for now
<rbrunner7> Anyway, I myself will probably try to continue with my role as "project manager" here. Somebody has to do it, even if in terms of work hours it's quite modest so far. This might chance if things progress of course, which I hope they will still do.
<rbrunner7> *change
<rbrunner7> Maybe jeffro256 will chime in later with a short statement. I somehow hope that we won't "lose him to FCMPs" ...
<rbrunner7> But of course things are very much in flux. Pretty much nothing ins guaranteed.
<dangerousfreedom> Anyway, FCMP is just one part of the transaction... we are proposing, with jamtis and seraphis, to change everything. So, of course our work has to be done.
<rbrunner7> For example I wonder how it will turn out if "we" turn the wallet upside down by giving `wallet2.h` a new underpinning, and the FCMP people likewise need larger modifications there.
<dangerousfreedom> Impossible in the long term
<rbrunner7> Maybe it's too early to have answers here.
<rbrunner7> Yes, in the long term everything coverges into a single wallet code of course. I was thinking about the way there.
<rbrunner7> I guess we will see early enough. Also depends on the speed the two groups will move forward.
<dangerousfreedom> Yes. I hope the theoretical stuff will be layed down soon so kayaba and jberman wont build FCMP on something dubious
<one-horse-wagon> Are there enough people immediately available to  effectively code FCMP?
<rbrunner7> Well, kayabanerve is a true workhorse. I don't know whether that guy has to sleep at all. Together with jberman you probably have already quite some implementation team.
<rbrunner7> Much is coded already anyway in the core of it, if I understood correctly.
<rbrunner7> This still may take some wind out of our sails here at the Seraphis team, as the saying goes
<rbrunner7> Although it seems it won't be too bad, from the statements we had here today
<dangerousfreedom> I like your comparisons with sailing
<rbrunner7> Yeah, sometimes it's about sentiment and motivation, things that nerds may forget a bit too easily
<dangerousfreedom> rbrunner7: I will pm you so we can try to solve your compilation problem so you can hopefully give me some feedback later :p
<rbrunner7> Alright, no stress :)
<rbrunner7> Anything left for today's meeting?
<jberman> with tevador also seemingly keen to help with performant lower level arithmetic for FCMP's as well, I'm feeling optimistic about having the people needed for implementation myself included
<dangerousfreedom> Not from me. I will keep cleaning up things in the wallet demo and thinking about the next tasks.
<rbrunner7> Does not look like it then. Thanks everybody for attending, read you again next week!
<dangerousfreedom> Thanks rbrunner7
<one-horse-wagon> Thank you.
<SNeedlewoods> from me neither, will try to continue with reviews
<SNeedlewoods> thanks everyone
<jberman> thanks all
monero-project / meta

Seraphis wallet workgroup meeting #65 - Monday, 2024-04-08, 18:00 UTC #987
