15:01:00 MRL meeting in this room in two hours. 17:00:29 Meeting time! https://github.com/monero-project/meta/issues/1443 17:00:34 1. Greetings 17:00:50 Hi 17:00:52 Hello 17:01:02 waves 17:01:13 Howdy 17:01:35 Hello 17:02:01 hi 17:02:38 Hello 17:02:51 Hello 17:02:54 2. Updates. What is everyone working on? 17:03:16 Not sure if it is relevant to the meeting but I am working on carrot25519, a little experimental C11 allocation-free primitive implementing the raw Montgomery ladder that CARROT uses, with portable/fiat51, ARM64/cc0, x86_64-baseline and BMI2+ADX backends, still need some optimizations, and DataHoarder and Tevador been helping :) 17:03:39 @slowbeardigger:matrix.org: parallel to that I’m pushing the xmr-pay Carrot side (view-key only scanning + settlement/reorg) so compatible payment integrations can be ready for the community as soon as public stressnet or mainnet Carrot lands. (yay) 17:03:56 I'm working on adding Carrot-compatible coinbase transactions to P2Pool (last week I was quite busy IRL, so this work just started) 17:04:01 hello. seeing sech1 move to Carrot/FCMP++ for P2Pool and reviewing anything 17:04:13 Me: attempting to decrease lock contention in monerod 17:05:00 Some upstream PR handling and re-reviewing the Carrot hot/cold wallet PR 17:05:11 me: Testing Dandelion++ privacy protections in monerosim. Not ready to share statistical results yet, but everything looks good so far. I can get precise estimates of spy node effectiveness with just a few dozen simulation runs. Continuing to report issues in monerosim: https://github.com/Fountain5405/monerosim/issues 17:05:21

Hi 17:06:00 me: spent time updating serialization code (still not pred), updated/tested racy code in epee/levin, and now working on updating all my prs to work against head master version 17:06:07 me: implemented tevador's suggestion for PQ turnstile indistinguishability: https://github.com/seraphis-migration/monero/pull/456. Reviewing upstream PRs 17:07:40 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (https://github.com/jeffro256/carrot/issues/10). 17:09:27 PR for K^j_v implementation here: https://github.com/seraphis-migration/monero/pull/456. API for scanning coinbase enotes changed slightly, requiring the user to pass their main address view pubkey, but otherwise the API didn't need updating 17:10:44 If we go with the above change, I'll need to update the Carrot spec 17:12:25 Would the change require anything to be re-audited or receive external review again? 17:12:26 Carrot spec already needs update due to the personalization string / Generator T changing 17:12:47 And https://github.com/seraphis-migration/monero/pull/424 17:12:57 I don't think so, because actually the first Carrot spec audit had d_e bind to K^j_v, so it's actually already been audited 17:13:39 DataHoarder: You're right about the T generator, but #424 doesn't require changes to the spec 17:14:51 It's a big API overhaul, but it didn't change anything with the protocol itself 17:15:35 Oh, fair, I guess we just pick the values differently. I do remember a few tweaks were also done for the PQ turnstile to work for coinbase outputs, cannot remember if those were brought back to spec 17:16:05 Yes, the PQ stuff should already be in the latest version of the spec 17:18:41 More on this topic? Should it appear on the agenda next week, too? 17:19:12 If tevador isn't here, then there's not too much to discuss 17:19:25 I think that the rest of the discussion could happen on that Github issue 17:20:03 I will take it off the agenda next week unless someone requests it to be placed on the agenda. 17:20:22 4. FCMP++ to-do list status. Programming tasks (https://github.com/seraphis-migration/monero/issues/53). Reviews and audits (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). FCMP++ Integration Audit Overview (https://github.com/seraphis-migration/monero/issues/294). Network upgrade [... too long, see https://mrelay.p2pool.observer/e/yLqkpKILb3IwaHJr ] 17:22:20 Next major item: Re-reviewing @jeffro256:monero.social's hot/cold wallet PR now, which is also currently a dependency for UkoeHB 's multisig work. Hot/Cold wallet stuff is very close I think 17:23:13 RFQ is going out for gadgets + circuit + fcmp-plus-plus audit, nothing to report on there yet 17:23:41 Licensing discussion still ongoing in https://github.com/monero-project/monero/pull/10964 for mx25519. Tevador proposed an interesting solution: effectively make the core API+portable impl licensed permissively, and the fast assembly backends (where the magic happens) copyleft 17:23:52 I was hoping that he'd be here today, oh well 17:25:50 Thanks, @jberman:monero.social and @jeffro256:monero.social . More on this topic? 17:25:58 That "trick" probably won't extend to the much simpler Polyseed library? 17:26:00 I was wondering if it would be worth it to work on a quick license library to fetch license text to display in-binary for applicable licenses 17:27:03 Unless tevador chooses to re-license, then Polyseed remains under LGPL 17:27:32 @jeffro256: How would that work? 17:27:48 What about, relicensing the mx25519 to MPL-2.0 pls split the library? 17:27:48 like BSD-3 the core + C portable implementation, MPL-2.0 the assembly backends 17:27:48 Compilation flags included on the fast assembly[... more lines follow, see https://mrelay.p2pool.observer/e/mP--pKILQjhCa2N2 ] 17:28:01 I think Trevador said he likes a way like that 17:28:37 That's exactly the solution tevador suggested. 17:28:45 yeah 17:28:54 if you ask me, that seems to be the “easiest” way 17:29:16 The licensing issue raisees many questions for dicussion. 17:29:41 Gets the thing done in a couple of commits, and not a lot of drama 17:29:41 less friction way imo 17:29:52 I am just looking at the Github 17:29:55 @tobtoht: It would look like a license command in daemon/wallet CLI/wallet RPC etc which pulls text from an in-binary array, which is inserted during build time based on a maintained license file 17:31:39 So when we add a new dependency which requires distrubuting source code information alongside the binary, a contribuor would append applicable info to the license file, which gets added into the binary during build time 17:32:18 Not sure there's much point to the licensing section of the CoC if it can just be ignored 17:32:51 Even without mx25519/Polyseed we should probably do this because we are out of compliance with some BSD-3 licensing 17:34:07 Our biggest licensing issue right now is our GPLv3'd readline dependency 17:34:26 I suggested replacing it with linenoise from Redis 17:35:09 It would also be a drastic reduction in LoC for that functionality 17:35:19 FWIW, R and python have a license text that can be printed with license(). 17:35:22 Would this license content mechanism be available to smartphone wallet apps as well? 17:35:36 @jpk68:matrix.org: Yep, would also drop ncurses. 17:37:09 rbrunner: We could expose it in wallet api? 17:37:27 Sounds reasonable. 17:40:15 5. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161). 17:41:17 Last meeting, UkoeHB said he would put review of https://github.com/seraphis-migration/monero/pull/445 on his list 17:44:07 Any discussion of this for now? If not, I will move on to the next item. 17:45:11 6. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). Version 3 launch checklist (https://github.com/seraphis-migration/monero/pull/415). 17:46:17 Re: relative locks, I just commented on the original issue here: https://github.com/monero-project/research-lab/issues/161#issuecomment-5345884915 17:46:32 oh boy 17:46:32 :) can’t wait 17:47:00 I think it could potentially help strengthen the case for them if the Grease people want to run with that primitive 17:48:16 Re: beta stressnet. Discussed with @jeffro256:monero.social and we're going to aim to have the hot/cold wallet changes in for beta v3 as well. So desired order of operations is hot/cold wallet changes then rebase on top of latest master 17:49:21 The hot/cold wallet changes bring a pretty significant change to the wallet, and I think it'll be good to have it sorted out in that order 17:49:45 I have shut down all my tx spammers and switched my nodes back to regular testnet. 17:50:51 So right now working on my re-review of the hot/cold wallet PR and hopefully we'll have that ready by next week. I know I said hoping by next week last week, but hot/cold wallet stuff does make sense to get in first for reasons above (which I wasn't considering when I said that) 17:51:35 And making sure hot/cold wallets are ready for the fork is obviously a requirement for the fork anyway 17:52:46 Did not review that PR yet 17:53:08 ukoe is the hot/cold PR sort of a prereq for some of the multisig stuff? 17:53:31 Multisig branch is on top of that branch 17:54:18 IIRC it's just tx_builder that's a dep 17:55:17 One thing I've been thinking that would be nice is to have some good concrete testing of the new wallet/daemon software before the fork. We don't need to spam during that period (that would spam current testnet), but a concerted effort at testing during that period would be nice 17:56:21 Maybe we'd want to consider an initial fork from current testnet that just separates networks, but maintain current rules pre-fork, that would allow people to spam 17:56:59 @jberman: You could have cuprate on stressnet for that time, too. 17:58:40 More on stressnet? 17:58:51 nothing from me 17:59:45 7. PoW-Admitted Zero-Fee Transactions for P2Pool (https://gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353). 18:00:06 sech1. And maybe DataHoarder[m] 18:01:00 nothing from me here at this point 18:04:47 sech1 was here at the beginning of the meeting. 18:07:02 I created https://github.com/monero-project/monero/pull/11102 to make life easier for P2Pool when handling these transactions 18:08:25 This item can be removed from agenda for the next meeting, because I'll be working on general FCMP++/Carrot support for P2Pool, and zero-fee transaction support will be added after all that. 18:09:16 More discussion on this item? 18:11:52 We can end the meeting here. Thanks everyone. 18:12:06 Thanks, have a good one y'all 18:49:42 apologies for missing the meeting 18:53:05 Polyseed could also be made optional, since we need to keep old seed code for backwards compatability anyway, it could be disabled during compile time and old seed code is used. For those niche cases where copyleft code is not acceptable it should be fine to not have Polyseed. A relicense to MPL 2.0 like mx25519 would still be good. 18:59:42 selsta: What would be an example niche case where copyleft code is not acceptable? 19:02:15 Yes, Polyseed is definitely optional. Wallets that don't support Polyseed can still be used to import Polyseed converted to a legacy seed (it's a one way conversion). 19:05:31 BTCPay Server for example would have extra compliance obligations when integrating Monero, they could disable Polyseed since it's not required for accepting payments. 19:06:15 (I did not research this example so it's possible it would not be an issue for them anyway) 19:08:58 BTCPay Server is open source, so where exactly the problem would be? https://btcpayserver.org/ links to their github, which, IMO, counts as "reasonable means" to provide the source code per the MPL-2 license. 19:10:07 "Polyseed could also be made optional" Not soure how you mean that. People who build on Monero code but don't want the license burden would compile the code without Polyseed inclusion? Or would we public 2 different versions of the CLI wallet app, one with Polyseed and one without? 19:11:08 ^ I think optional here means there is a compile-time switch to disable it. 19:11:19 yes, for the public there would only be one version 19:12:35 tevador: I don't think including MPL 2.0 code would be an issue for BTCPay Server, but tobtoht had reservations and I don't know enough about licensing to judge myself. It appears a compile time switch is a compromise everyone agress on. 19:13:43 Well, if I think about the many, many places where I put in code to handle Polyseeds ... if the way to go is #if ... #endif around all of them, I don't know whether that idea would really fly ... 19:14:27 Or would we link in a dummy Polyseed library? 19:14:43 All the methods, but no code behind it? 19:18:14 What is the benefit of Polyseed using a copyleft license? I can't think of any optimizations one would want to be open-sourced, which the author would be forced to reveal under a "weak" copyleft license such as the LGPL 19:18:25 Dependency injection could also be used to circumvent it to some extent 19:22:05 Maybe some significant extensions, like using the checksum polynoms to restore a single missing word (as I think to remember that is technically possible)? 19:23:27 We can do a cleanroom reimplementation in C++ and license it under BSD-3. We already have a BSD-3 polyseed implementation written in Dart, could use that as a template. No licensing drama, no additional obligations, and our entire downstream gets to benefit from polyseed. 19:24:31 Speaking of the dart implementation: https://github.com/cake-tech/polyseed_dart/issues/7 19:25:23 There is a Rust impl too: https://github.com/monero-oxide/monero-wallet-util/tree/main/polyseed 19:26:59 I don't claim that to be clean room but it wasn't a translation and was written from scratch. The most copied would solely be the definition of constants. 19:31:24 cc tevador if they want to clarify at first glance, if they believe it's derivative (re: GPL requirements) and/or would prefer any acknowledgement/statements. 19:32:24 TBH, I'd prefer polyseed, the spec, be copyleft but the impls be BSD-3 or comparable. I don't think that is feasible under current legal constructs, even if it can be stated as a request within respectful society. 19:33:02 Ah, how conducive to the spirit of open source. Let's impound ourselves with more bureaucracy and legal requirements 19:33:07 As in, use or derivative designs have to specified, stated, and published, but my impl of Polyseed would be MIT while citing it is an impl of this spec licensed as follows. 19:33:51 ^ ramblings, feel free to ignore, but I do welcome any opinions from tevador on if my Rust library is respectful or not. I'm willing to make adjustments to ensure it is, even if I don't believe I'd be legally obligated to. 19:37:34 @jpk68:matrix.org: This is off-topic for Lab so for my last message on this: People can want to abolish copyright. That doesn't change if I publish something with a request, people should reasonably respect my request. I should be allowed to say, if you use this spec, please declare so and state changes, even though your impl [... too long, see https://mrelay.p2pool.observer/e/hM-aqKILUG5jX2Ns ] 19:37:54 The rust version doesn't look like a translation at first glance, at least not to the extent that the dart one does. 19:40:11 But it's all up to tevador as it's tevador's thing. This was just my hat in the ring on what could be a good choice of license and requirements to ensure respect, but what's respectful is following what they request or choosing not to engage with them and their work. Free choice in association and all that. 19:40:24 @kayabanerve:matrix.org: Sure, people can do that all they want. I wasn't really taking issue with what you said; having the spec be copyleft and the implementation be permissive would even be preferable, IMO 19:40:35 tevador: Cool. I won't insist that's a binding legal opinion. Lmk at any time if I can do anything to better acknowledge you :) 19:41:59 Yes, polyseed is missing a formal specification. That's something that should be fixed. 19:42:15 However, a license is more than just an acknowledgment to respect someone's work - not sure if I can agree with something that would potentially let the state punish someone for "copying" source code. Does that not sound a bit dissonant to what the point of digital cash is? 19:47:42 I think it would be quite hard to violate MPL just by copying code. You'd have to either remove the copyright notices (this would also violate most permissive licenses) or make it closed-source. 20:25:46 DataHoarder: I misspoke about the T generator, those changes are already in the spec 20:28:49 unbiashed hash to point is changing, so that'd be changed to dc42e1d3307b2d4b3b02729abe577e231d79478141cb5b310ca9fa6e127616a3 20:29:11 (it'd use blake2b with the Monero personalization string) 20:30:34 you changed the representation here, https://github.com/monero-oxide/monero-oxide/pull/188 which changes the derived T value 20:32:07 Durrr you're right, I copy and pasted the wrong value from that PR 20:32:27 Hp^2 also needs to get updated with the new target commit ids, or maybe not, as H64 was indicated for use and it just ended up with Monero personalization being good everywhere 20:33:26 also, on master I don't see any pushes since 4 months ago so maybe you are talking about a different local repo? 20:36:10 I am looking at https://github.com/jeffro256/carrot unless there's somewhere else with the Carrot spec 21:28:22 Fwiw, i think they ship the stock monero binary, so i dont think it has to include anything? > BTCPay Server for example would have extra compliance obligations when integrating Monero, they could disable Polyseed since it's not required for accepting payments. 21:30:38 also, btcpayserver doesnt ship or support monero upstream, btcpay-monero ships a plugin, and its that plugin that ships prebuilt monerod and monero-wallet-rpc. Also dont think they use seeds 21:35:17 (Just imported view-only wallets) 21:48:59 IIUC, if they download pre-built release binaries and Polyseed/mx25519 is licensed under LGPL, they will indeed have to include licenses 21:49:06 That may not be the case for MPL, however