01:58:25 0​xfffc:monero.social: I have been busy with personal stuff past few days. Missed the discussion.
01:58:26 0​xfffc:monero.social: What is the consensus on a total (re)implementation of FCMP++ with C++?
09:14:46 r​brunner7:monero.social: What consensus? :) As far as I understand, discussion is ongoing. Maybe something that we could discuss further in today's meeting here?
13:59:18 r​euben:firo.org: Any reason ?
14:28:52 j​babb:cypherstack.com: to remove Rust dependency and to have another implementation to reference as far as I understand
16:59:45 r​brunner7:monero.social: Meeting in 1 hour
17:59:51 r​brunner7:monero.social: Meeting time. Hello! https://github.com/monero-project/meta/issues/1347
18:00:12 j​berman:monero.social: *waves*
18:00:28 s​needlewoods_xmr:matrix.org: Hey
18:01:19 j​effro256:monero.social: Howdy
18:01:44 v​tnerd:monero.social: Hi
18:02:21 r​brunner7:monero.social: Alright, on to the reports for last week. Me: Completed my analysis of Polyseed use in Monero wallets and wrote a report: https://github.com/tevador/polyseed/issues/13#issuecomment-3980281619
18:02:46 r​brunner7:monero.social: Unsure how to proceed
18:04:33 s​needlewoods_xmr:matrix.org: Began to look deeper into the exceptions in wallet-rpc and so far it looks like most of them don't need special attention.
18:04:33 s​needlewoods_xmr:matrix.org: My idea was to add a member `m_exceptionPtr`, but didn't come far enough for a nice writeup like rbunners proposal, or even compare the proposals.
18:04:47 s​needlewoods_xmr:matrix.org: here is the idea quickly thrown into a pseudo patch https://paste.debian.net/hidden/d34a0690
18:05:33 s​needlewoods_xmr:matrix.org: rburnners proposal: https://github.com/monero-project/monero/issues/10343
18:05:45 j​berman:monero.social: We got a minor refactor of FCMP++ type organization / dependency mgmt merged, I continued on upstream FCMP++ crypto PR's in prep for an audit, and reviewed beta FCMP++ scaling & implemented the new "max" fee priority category wallet-side
18:06:00 j​babb:cypherstack.com: I should do you a favor and figure out exactly what Stack Wallet does... we use Cake Wallet's monero_c with some customizations but not polyseed_dart iirc
18:06:20 j​babb:cypherstack.com: s/figure out/remember what we did and look it up
18:06:24 s​needlewoods_xmr:matrix.org: rbrunner* sorry, butchered your name twice
18:06:50 r​brunner7:monero.social: Josh Babb: I did look already at Stack Wallet and didn't see any surprises there. Surprise would have been use of Polyseed "native" encryption.
18:07:06 r​brunner7:monero.social: SNeedlewoods: No problem :)
18:07:10 j​babb:cypherstack.com: Stack Wallet should go in the `B) Apps that only offer basic Polyseed support` category for now
18:07:16 j​effro256:monero.social: Me: talking to an potential auditor atm and reworking the Rust lib for the PQ changes
18:07:25 j​babb:cypherstack.com: I'll see what we can do about the rest sometime
18:07:36 jpk68: I discussed the encrypted Polyseed issue with the Monfluo maintainer
18:08:04 jpk68: We decided on supporting it eventually, but first just implementing some UI thing to notify the user
18:08:58 r​brunner7:monero.social: Josh Babb: Yes, I would say B) currently for Stack Wallet is correct
18:10:32 j​berman:monero.social: Question: so Cake Wallet doesn't support creating a new wallet with a polyseed + seed offset? But it *does* support restoring such a wallet?
18:11:09 r​brunner7:monero.social: Yes.
18:11:47 r​brunner7:monero.social: That's one way to do it, I guess.
18:12:11 j​babb:cypherstack.com: that's likely how Stack Wallet would do it
18:12:11 j​babb:cypherstack.com: we're averse to showing the user too many ways to lose their funds, but if they need to restore it it should be available
18:12:47 j​berman:monero.social: For any wallet2 wallet, I would think the seed offset is the more critical feature to support, since the wallet already does encrypt the keys file where the seed lives using the wallet password
18:13:08 r​brunner7:monero.social: I guess it depends on your view of Polyseed encryption, whether you "like" it, or whether you see problems with plausible deniability ...
18:14:24 j​babb:cypherstack.com: as an advanced user I love it. but I, too, have lost funds due to forgetting passphrases I didn't store with seeds
18:14:35 r​brunner7:monero.social: If you want to support both encryption and seed offset at wallet creation, you have to ask the user a potentially confusing question.
18:15:12 j​berman:monero.social: > B) simply ignore the feature bit, with the very unfortunate result that they take the encrypted bits as the private key to use and restore an altogether different wallet without warning, which is dangerous and can lead to confusion.
18:15:13 j​berman:monero.social: This sounds like a clear bug in those wallets :/ the feature bit AFAIU should be a totally distinct bit from what's used for entropy in deriving the seed
18:15:36 j​berman:monero.social: ah wait, I misunderstood, I see
18:15:59 j​babb:cypherstack.com: how so? that's my understanding
18:16:01 j​berman:monero.social: the entropy bits in the seed are already encrypted, and are meant to be decrypted with the seed's passphrase
18:16:29 j​berman:monero.social: so it's not using the encryption feature bit as entropy, rather just using the encrypted entropy bits as private key
18:16:45 j​berman:monero.social: but yes still a clear bug
18:16:57 r​brunner7:monero.social: I have a strong opinion that for *restore* all wallets should standardize on Cake Wallet's method, that can restore everything, except combinations that don't make sense
18:17:24 r​brunner7:monero.social: What they do on wallet *create* is another story, and I wouldn't mind author's personal preference influencing that
18:18:27 j​berman:monero.social: "except combinations that don't make sense" -> what's an example of a combo that doesn't make sense?
18:19:25 s​needlewoods_xmr:matrix.org: With "combinations that don't make sense" you are referring to seed offset + Polyseed encryption?
18:19:33 r​brunner7:monero.social: What do people think, do we need a proper "Polyseed spec" discussion first, before I go on and implement anything? Whether we see seed offsets with Polyseeds as "discouraged because out of spec"? Or are we pragmatic here; in any case, a handful of wallets do that now, so ...
18:19:50 r​brunner7:monero.social: jberman: Encrypting *and* seed offset, basically
18:20:40 j​pk68:matrix.org: It would be nice to have a standardized, 'suggested' spec
18:20:48 s​needlewoods_xmr:matrix.org: >Plus, as argued in this thread, plausible deniability can be seen as better with seed offsets.
18:21:25 s​needlewoods_xmr:matrix.org: I thought this argument meant it could make sense to have encryption + seed offset
18:21:32 j​berman:monero.social: I follow. I guess I don't understand why there is the option to either encrypt OR offset. Seems the effect is the same in either case at least from initial look?
18:22:46 r​brunner7:monero.social: Not sure what you mean. The effect of both is an additional level of protection, more or less of the same strength. So the two mechanisms are somewhat redundant, but now Cake Wallet created facts by using encryption, so we probably can't kill that anymore.
18:23:27 r​brunner7:monero.social: If it was a small wallet maybe, but the biggest smartphone wallet is a bit unfortunate
18:24:55 r​brunner7:monero.social: SNeedlewoods: Encryption is "visible" because of the set feature bit. A seed offset is not
18:25:06 j​berman:monero.social: Looks like the polyseed spec didn't define a seed offset because @tevador expected the encryption feature to take its place. Then wallet implementers ended up implementing the offset also
18:25:50 r​brunner7:monero.social: I think so as well, yes. But not sure whether using a seed offset really belongs into the Polyseed spec?
18:26:58 r​brunner7:monero.social: In any case, wallet app writers did not care and went ahead anyway, and the result is at least sensible. Just not right now on the restore side, if you encrypt.
18:28:50 j​berman:monero.social: I personally don't immediately have a strong opinion on best direction here. Need to think more on the discussion
18:30:20 j​berman:monero.social: it seems like it does, because the encryption feature is essentially the same thing
18:31:40 j​berman:monero.social: except that the offset has an additional layer of plausible deniability as pointed out
18:34:45 r​brunner7:monero.social: Alright, a change of subject then:
18:34:54 r​brunner7:monero.social: Are the necessary people here to talk about possible rewrite of FCMP++ in C++, like it came up in conjunction with dangerousfreedom 's proposal to add FCMP+ to this Monero inflation webapp? And does it make sense to talk about it today?
18:35:49 r​brunner7:monero.social: kayabanerve left a lot of interesting info here a few days ago that it should be doable.
18:36:05 r​brunner7:monero.social: I guess it's still quite a job, and not the easiest one ...
18:36:51 j​babb:cypherstack.com: iirc it was deferred because it'd be quicker to get to FCMP++ without reimplementing the helios/selene curve "stack"
18:37:31 r​brunner7:monero.social: Well, "quicker" is not necessarily the main goal if you want to *verify*, and make sure there is no inflation, as I see it
18:37:54 r​brunner7:monero.social: I mean, *really* verify, in an (almost) independent way
18:39:09 j​berman:monero.social: I think it comes down to if dangerousfreedom is interested in attempting it in C++. I agree with boog that a C++ rewrite could be more beneficial because it can actually be used in monerod, but a rewrite in python would also be beneficial (another deep eye on the impl & another impl that could be easier to read than rust)
18:40:17 r​brunner7:monero.social: Does this need somebody who is really *good* with C++? And also knows Rust, to make it not too easy? Or isn't that too hard in the case of the particular code on hand?
18:41:28 j​berman:monero.social: I don't think skill with C++ is nearly close to as relevant as skill with actually implementing the crypto
18:42:24 r​brunner7:monero.social: Hmm, so it's more about quite challenging crypto then, in your opinion?
18:42:40 j​berman:monero.social: I think so
18:42:57 r​brunner7:monero.social: Is FCMP++ currently in the stressnet daemon by binding to Rust code?
18:43:16 j​berman:monero.social: yes
18:44:14 r​brunner7:monero.social: So we would'nt introduce a potentially problematic dependency if dangerousfreedom decides to attack a rewrite, but needs much longer than anticipated
18:44:46 r​brunner7:monero.social: (a time dependency)
18:45:10 j​berman:monero.social: I implemented *some* C++ crypto over here so you can kind of get a taste for some of the C/C++ involved with that: https://github.com/seraphis-migration/monero/issues/294
18:46:02 j​pk68:matrix.org: I'm not very qualified to talk about this, but it is worth noting that the Rust implementation which is being used in the stressnet has several of its own dependencies
18:46:18 j​pk68:matrix.org: Like, more than 5 IIRC
18:47:01 j​pk68:matrix.org: They're from an online registry (crates.io) so there could be some concern over supply chain attacks
18:47:12 j​berman:monero.social: I mean it likely would end up taking some C++/C skill to do. At the end of the day, if there's a python impl, it would maybe make a C++ impl easier to implement too just to have another source to consult on possibly trickier code
18:47:40 j​babb:cypherstack.com: https://github.com/seraphis-migration/monero/blob/fcmp%2B%2B-stage/src/fcmp_pp/fcmp_pp_rust/Cargo.toml
18:48:20 r​brunner7:monero.social: Ok. My advice to him was to open a CCS just for about 2 weeks of intensive study what possibilities there are, and arrive at reasonably good time estimates
18:49:04 b​oog900:monero.social: I wouldn't even say the main monerod repo has to move dangerousfreedom @dangerousfreedom:matrix.org's impl, if it was to be done. I think even a fork of monerod with their impl would be good and better than just doing it in python.
18:49:44 j​babb:cypherstack.com: more useful for actual code/software, potentially less academically beneficial
18:50:19 j​babb:cypherstack.com: a python impl is useful in and of itself as a reference for academics imo--hard to measure those sorts of benefits tho
18:50:23 j​babb:cypherstack.com: but they come in papers later on
18:51:13 r​brunner7:monero.social: Don't want to talk down anybody, or discourage, but when an IQ > 150 guy tells me "It's doable", it doesn't mean yet that *I* can do it as well ...
18:53:01 j​berman:monero.social: It's not going to be an easy task. If danger is much more inclined to implement in python, then I think there would still be wider benefits to doing so
18:53:24 r​brunner7:monero.social: Is Python to Rust any significant problem?
18:53:43 r​brunner7:monero.social: Because as we can see, there a tail of dependencies waiting
18:54:12 r​brunner7:monero.social: from that Cargo.toml that was linked above
18:54:28 j​berman:monero.social: not sure what you mean
18:55:01 r​brunner7:monero.social: If you write core FCMP++ in Python, can you wait with writing Selene of whatever in Python and use that in Rust for the time being?
18:55:39 r​brunner7:monero.social: or the GBP
18:56:13 j​babb:cypherstack.com: yes you can use ffi to bridge things together and defer work but part of the point would be to make the second implementation
18:56:32 r​brunner7:monero.social: Sure, as an end goal
18:56:47 r​brunner7:monero.social: That unfortunately may be out of reach, with some bad luck ...
18:57:01 j​babb:cypherstack.com: that Cargo.toml is a good example of a pretty short dependency list too. its monero-oxide dependency also only use a small amount of deps: https://github.com/monero-oxide/monero-oxide/blob/main/Cargo.toml
18:57:21 j​babb:cypherstack.com: it can be done in c++ and python, just needs some motivation, gumption, and funding
18:57:49 j​berman:monero.social: hrm, I anticipate the python code will end up with dependencies itself too, and it won't necessarily make sense to say we should swap out Rust stuff for python stuff (for a host of other reasons as well, not just on cutting dependencies)
18:58:02 r​brunner7:monero.social: Cool, TIL "gumption" :)
18:58:24 j​berman:monero.social: (speed and safety being the big ones too)
18:58:49 r​brunner7:monero.social: Ok, I see. So everything clear as mud right now, basically
18:59:38 j​berman:monero.social: The core benefits of a python impl: a secondary impl that acts as a sort of review on the crypto code, a reference impl for academics and/or others interested in learning how FCMP++ works
19:00:21 j​berman:monero.social: The core benefits of a C++ impl: a secondary impl that could be used to eliminate dependencies from the Rust code in a C++ monero daemon impl, in addition to a secondary impl that acts as a sort of review on the crypto code
19:01:00 r​brunner7:monero.social: Hmm, yes, but you probably still won't fully get rid of Rust dependencies, for the wallet
19:02:29 j​berman:monero.social: Python impl is likely somewhat easier to implement at the end of the day, but the main hard part imo is probably going to be the math and not making the language do what you want
19:03:33 j​berman:monero.social: well if the whole of helios selene lib & FCMP++ prove / verify is rewritten in C++ then it's theoretically possible to get rid of the Rust deps
19:04:17 j​berman:monero.social: so yes, I should have said monero daemon *and* wallet impl
19:05:02 r​brunner7:monero.social: Ok, nice. But then with regard to problems and optimizations you have to babysit *two* mission-critical implementations
19:05:41 r​brunner7:monero.social: And you can have the opinion that we shouldn't put our energy into producting yet more C++ code ...
19:06:04 j​babb:cypherstack.com: well the python isn't critical and the introduction of a second implementation should be approached with care and with some in depth stressnet (splitnet) style testing to see if we can force chain splits with one or the other impl mining and producing edgecases or being malicious
19:06:05 r​brunner7:monero.social: If we have it already in Rust, I mean
19:06:54 r​brunner7:monero.social: Yes, I mean that's an argument for a Python implementation, to be used primarily for the Monero inflation app, which after all is not mission critical
19:07:02 j​babb:cypherstack.com: more c++, more rust, more python... :) let's get some go and the language of your choice into the mix... the only risk is when alternative implementations aren't faithful to the original (even to its bugs!) and chain splits occur
19:07:30 r​brunner7:monero.social: Touché
19:07:59 j​berman:monero.social: I think it's valid to eventually want monerod/wallet code entirely in C++, and a C++ impl moves closer to that than a python impl. Although yes, it's a whoooooole lot of work to get that code to production ready
19:08:35 r​brunner7:monero.social: Probably even with external code reviews, if we are really serious, right?
19:09:56 r​brunner7:monero.social: Ok, to this grumpy old boomer this all does not look like it will happen anytime soon. But I let developments surprise me.
19:10:45 r​brunner7:monero.social: Ok, discussions can of course continue, but let me close the meeting proper at this point. Thanks everybody for attending, read you again in 1 week!
19:11:06 s​needlewoods_xmr:matrix.org: Final thought on Polyseed, as far as I understand it right now, I like the way Cake did it and IMO you can go for a similar implementation.
19:11:07 s​needlewoods_xmr:matrix.org: So that for creating a wallet you could use Polyseed with the option to either encrypt or not.
19:11:09 s​needlewoods_xmr:matrix.org: If you want to create a new wallet with Polyseed and seed-offset, you would 1. create an unencrypted Polyseed and 2. use that mnemonic to restore the wallet, which sees it's an unencrypted Polyseed, so if you provide a password that will be used as seed-offset.
19:11:25 s​needlewoods_xmr:matrix.org: thanks everyone, good meeting, cu
19:13:46 v​tnerd:monero.social: One small benefit would be to wallets. They now need a c++ and rust runtimes to work. If a c++ impl was available it would remove the rust requirement. And a bug would be less problematic (alhough if funds get locked ...)
19:14:10 v​tnerd:monero.social: Ah Berman basically said same thing