Seraphis wallet workgroup meeting #78 - Monday, 2024-07-15, 18:00 UTC

<rbrunner7> Meeting time. Hello! https://github.com/monero-project/meta/issues/1038
<sneedlewoods> hello
<jberman> *waves*
<dangerousfreedom> Hello
<kayabanerve> *waves*
<jeffro256> howdy
<rbrunner7> Nice to have you here, it's not yet the big summer lull :)
<rbrunner7> What is there to report from last week?
<dangerousfreedom> Sorry, I was basically three weeks away but will work full-time in the next 4 weeks. Lately, things happened very fast in Monero, as usual, so my immediate goal is to give my work some unity and do something that makes sense.
<dangerousfreedom> AFAIK, SNeedlewoods  is putting a lot of efforts in making the API independent from the wallet2, is that correct? What is the goal here? Have a modular wallet, as similiar as possible to wallet2? So it would be easier to integrate all the upcoming updates (enote-scanner, fcmp, etc)? 
<dangerousfreedom> I guess jberman  and jeffro256  are very busy with the structural part of the protocol since many things changed lately and the wallet is not the priority for them now, right?
<dangerousfreedom> From my side, I am still figuring out what makes sense to do (after these 3 weeks break which in one hand made me forget some stuff and on the other hand the project evolved). Does it still make sense to base my new wallet on the koe/seraphis_lib? Will the enote scheme be updated by jeffro256  or the plan is to use kayabanerve  library somehow (if it is already possible to create
<dangerousfreedom> txs under the new scheme in C++)? Does anyone have an idea or can foresee how a protowallet would look like if we put all the pieces that we are building together? AFAIU from @rbrunner posts, building a new wallet is still relevant and we are using the seraphis_lib for that, right? So I will continue in the direction that I wrote in my last CCS and I will be talking to jeffro and
<dangerousfreedom> jberman to see how the blockchain integration is going and what I can do to help them. This is what makes more sense to me now. What do you think?
<jeffro256> me: Jamtis RCT library support for legacy addresses is almost complete
<jeffro256> there were a lot of kinks to iron out
<jberman> me: started on the migration of cryptonote outputs into the merkle tree
<jberman>  "I guess jberman  and jeffro256  are very busy with the structural part of the protocol since many things changed lately and the wallet is not the priority for them now, right?" -> that's correct on my end, been basically exclusively focused on fcmp integration
<sneedlewoods> Still working on the API, but due to many distractions not as far done as I'd like to be.
<kayabanerve:matrix.org> The plan is still wallet2 for the initial FCMP++ fork AFAIK.
<rbrunner7> "The plan is still wallet2 for the initial FCMP++ fork AFAIK." Well, I opined in my last wiki entry that we should try to avoid that, and try to go into that already with the new wallet. But I did not hear any feedback regarding that particular point. Opinions?
<jeffro256> > I guess  jberman (@jberman) and  jeffro256 are very busy with the structural part of the protocol
<jeffro256> To be clear, I'm not working on the FCMP++ consensus protocol at the moment, just the addressing protocol. But once I'm done with that, I'd be happy to help with FCMP++ if @jberman or @kayabanerve can find anything for me to do integration-wise
<jeffro256> I agree. We should try to write the FCMP++ scanning code as completely independent from wallet2 as possible, and then tie it in modularly if we still have wallet2 by that time
<dangerousfreedom> How would the enote_scanner be integrated in that case?
<jberman> once the tree is done, sections 6.9 and 6.10 are tasks that would be particularly sweet to get help on (enabling wallets to fetch decoy paths in the merkle tree using a gamma distribution across all unified coinbase, pre-rct and post-rct outputs) 
<kayabanerve:matrix.org> Sorry, I didn't mean to advocate against your view rbrunner7. If the new wallet is ready in time, which means a similarly timed PR and a drop-in API, I have no objections to its use.
<kayabanerve:matrix.org> The FCMP++ scanning code is identical to the classic scanning code if we don't modify the key derivation (as desirable for forward secrecy).
<sneedlewoods> dangerousfreedom currently I'm aiming to make the API feature complete, so it does everything that's needed by monero-wallet-cli, monero-wallet-gui and monero-wallet-rpc, while still relying on `wallet2` for the first step.
<dangerousfreedom> +1
<rbrunner7> "drop-in API" would now in that case be the "Wallet API" that SNeedlewoods is currently making feature-complete compared to wallet2
<jberman> on wallet2 versus the new wallet, I would lean towards sticking with wallet2 for speed of implementation and deployment, and then shifting focus to the new Seraphis-lib backed wallet
<jberman> so basically ya depends on how far along the Seraphis-lib backed API is
<rbrunner7> Well, I think an important unknown is the amount of changes in wallet2 code that would be needed for FCMPs. If they are substantial, it would be pity to have to work with the old spaghetti code, right?
<dangerousfreedom> jberman: are you using at all the seraphis_lib in your implementations?
<kayabanerve:matrix.org> Scanning is currently proposed as identical, as are addresses.
<kayabanerve:matrix.org> We're using the RPC for path fetching initially (comparable to requesting decoy info).
<kayabanerve:matrix.org> That leaves which RingCT signatures we prove as the distinction.
<jberman> I'm still pretty far away from wallet-side stuff
<jberman> so no
<jberman> I'm using Seraphis lib style code though
<jeffro256> jberman: Do you prefer the gamma distribution fetching of paths versus keeping a pruned scanned tree in wallet storage ?
<dangerousfreedom> So, at this point, where is the seraphis_lib used at?
<rbrunner7> jberman, but your scanner is mostly seraphis lib based?
<rbrunner7> "Scanning is currently proposed as identical, as are addresses." Hmm, no new long addresses after the first hardfork? Or do I misunderstand?
<sneedlewoods> jberman I took a quick look at your code and it's very pleasant for the eye, so +1 for style choice
<jberman> the wallet scanner I was working on is on hold, it's unrelated to fcmp's, it's a scanner that would replace wallet2's scanner today
<kayabanerve> The full tree would be multiple GB. A pruned tree would have a reorg limit (causing a rescan on limit break, unless you fetch the missing context from a node at time of necessity which would be a whole thing) yet would only be log(t) * o size, where t is the tree size and o the amount of outputs.
<jberman> my proposal for the seraphis lib is separate from fcmp's: that we use the seraphis lib to replace wallet2. I prioritize fcmp's higher than that task personally, but still consider it something we should include in our roadmap
<kayabanerve> For the reorg depth limit of 50, it'd be however many outputs in the past 50 blocks * some log scaling factor.
<rucknium> Is there an explanation somewhere (besides the FCMP++ pdf in sections 6.9 and 6.10) of what role the decoy selection plays in privacy with FCMP? Is it to protect a wallet from a malicious daemon? Why is gamma needed instead of uniform, for example?
<jeffro256> Yes to malicious daemon
<reuben> +1
<rbrunner7> I think it would be a good idea for you, dangerousfreedom , to have detailed chats with all people involved, to see what is there, and then come up with a roadmap of sorts how to go forward. I think you are in the best position to do that, and well, if it takes a full week, so be it. Extremely important work, if you ask me.
<jeffro256> Gamma is used for same reason as decoy selection: people spend recent outputs more often than old
<rucknium> Ok so OSPEAD can still be implemented to protect against a malicious daemon when the FCMP hard fork occurs.
<jeffro256> People would then likely naturally  request recent paths vs older paths
<jeffro256> Yup!
<jeffro256> I think
<rucknium> The only "problem" that OSPEAD would have then is that it couldn't be updated after FCMP goes into effect since the FCMP hides all the age information in the actual tx data on the blockchain
<rucknium> That is actually fine since updating it is tedious.
<kayabanerve> Until we move to locally stored trees. It's not infeasible, it's just prior not been scheduled for the first hard fork.
<rucknium> +1
<dangerousfreedom> Well, yes. That is my immediate goal as I said. If nobody is prioritizing building a new wallet, maybe it doesnt make sense to do it. So it answers your question above. I still personally dont know the best to go for yet.
<kayabanerve> Since decoy selection now only matters for the RPC, I don't see why we couldn't update it. Definitely at HF boundaries, but even outside of boundaries.
<jeffro256> +1
<jeffro256> I think it would be a good idea to have a consensus rule that the miner tx holds the current tree hash in tx extra. Its basically free for validators, very low cost for miners, but would help verifiably recover the tree much much faster during a deep reorg yeah?
<rucknium> Anyway, the code that's being written for the FCMP "decoys" can easily be adapted to a new distribution by switching out the gamma for something else (or just changing the gamma parameters). Should be a few lines of code to change, later
<rottenwheel> +1
<kayabanerve> The tree hash should go in the header.
<kayabanerve> It's already specified to do so.
<rbrunner7> dangerousfreedom: You are thinking that maybe it would be best to you to switch and join FCMP efforts in some way?
<kayabanerve> *pretty sure it is at least
<rucknium> Technically, it can be updated, but not in practice since there would be no updated data to base a new fitted distribution on.
<kayabanerve> Also, upon reorg, knowing historical roots doesn't help as you can't grow from a root.
<dangerousfreedom> I dont know, I have to see what makes more sense to do. It is pretty sad also to see the seraphis_lib being thrown in the trash.
<jeffro256> Should it go in the header? I think that would cause a lot of unnecessary changes to the block fornat. Also that would make headers significantly heavier and thus slower to sync . Additionally, what if we change proofs in the future and its no longer needed ?
<rucknium> How many FCMP decoys would a wallet request from a daemon?
<rbrunner7> dangerousfreedom: Alright, let us hear the results of your consultations and deliberations in one week :)
<dangerousfreedom> +1
<kayabanerve> The plan is to not throw out the seraphis lib. Solely not rush it to this HF, unless it isn't rushing it.
<kayabanerve> jeffro256: we're already making header changes for PoW reasons.
<kayabanerve> Rucknium: As many as arguable for a reasonable level of security. I'd presume whatever the ring len is at time of move.
<jberman> the idea for the wallet to store a pruned tree when scanning (i.e. the right-most edge of the tree) is very interesting and I think is sounding like a plausible stronger alternative to needing to fetch decoy paths from the tree
<rbrunner7> kayabanerve: Still wondering about your comment: "Scanning is currently proposed as identical, *as are addresses*" Does that mean no long addresses yet after the first FCMP hardfork?
<kayabanerve> Correct
<kayabanerve> Using the seraphis lib, and using JAMTIS, are additional discussions
<rbrunner7> Oh, that's a bit surprising, at least to me
<rbrunner7> But well, if that's still a working and sensible hardfork, and we don't hardfork again only about 3 months later, so maybe not that bad
<rbrunner7> Maybe your use and my used of the word "propose" are a bit different ...
<jberman> I think the way more grow_tree impl is currently implemented, it wouldn't be too much work for wallets to lean on the same functions to build that pruned tree locally. I think most of the heavy-lifting can be done external to wallet2 (e.g. prove(), get_tree_extension() when scanning), which means the changes to wallet2 would be minimal
<jeffro256> Yes but PoW change this has the benefit of making header syncing more DoS resistant, especially for deep syncing. I don't think content hashes should go in the header as they are not useful to someone who is just syncing headers
<kayabanerve> They benefit doing proofs off of that data.
<kayabanerve> also, cramming things in extra needs to be deprecated.
<rottenwheel> +1
<rbrunner7> Don't fully understand, but not cementing tx_extra further has my full support!
<jeffro256> Wallets would be downloading miner transactions during wallet sync anyways though
<rbrunner7> If it's part of some core mechanism, it's sure not "extra"
<jeffro256> Actually IIRC theres actually an option to skip scanning miner txs, but that seems like a premature optimization to me. Also, for wallets who DO  want to build the tree up wallet side, they will have to scan all transactions
<kayabanerve> That doesn't impact any of my comments at all.
<kayabanerve> That means the bandwidth doesn't change. Cool.
<kayabanerve> Placing the root in headers allow SPV without downloading any blocks.
<kayabanerve> It doesn't further use extra. It does grow the header (already being modified for DoS resilient).
<kayabanerve> We can place it in the block (in extra or a new field), yet that'd make proofs worse and most use cases won't save bandwidth.
<rbrunner7> I think you mentioned it somewhere, but I forgot: that "root" in the header, how many bytes do we speak about?
<jeffro256> How does this allow doing SPV without downloading any blocks? How would you know the paths of your owned enotes  without downloading blocks?
<kayabanerve> +32 bytes
<kayabanerve> jeffro256: That's not how SPV works.
<kayabanerve> If you have the complete header, someone can prove an output to you is in the output tree.
<rbrunner7> Did you detail this aspect somewhere. Sounds somehow hard to believe, seen from the outside by a noob.
<kayabanerve> Headers are currently 46 bytes. Adding 32 bytes for the PoW reason will make it 78. Adding 32 bytes for the tree root will make it 110 bytes.
<kayabanerve> Considering I think the keccak256 block size is ~64 bytes, we'd not add a keccak256 block. The PoW change already would.
<kayabanerve> rbrunner7: We're adding a merkle tree root to the header in this idea. Anyone can make a merkle tree proof to prove a leaf is present.
<kayabanerve> The leaf in this case is an output to you.
<jeffro256> I what you're saying, sorry I confused SPV with another term. However, I think the overhead of one block download (which can be reused) versus the verification time for one FCMP is pretty small . also I'd rather the SPV verifiers take on the cost of the block download versus block header syncers take on the disproportionate burden
<rbrunner7> Let me throw in a quick question whether we still have something closely wallet related left for this meeting?
<jeffro256> We can discuss this later though
<jeffro256> We should make a GH issue
<sneedlewoods> not from my side rbrunner
<kayabanerve> Sorry, keccak256 is weird with its block size definition. I think I'm correct this won't add a block size.
<rbrunner7> Ok, let's close the meeting proper then. Thanks for attending, nice to see how many things move in parallel in the codebase right now. Read you again next week!
<jeffro256> Thanks everyone !
<sneedlewoods> thanks everyone, cu
monero-project / meta

Seraphis wallet workgroup meeting #78 - Monday, 2024-07-15, 18:00 UTC #1038
