<rucknium> MRL meeting in this room in two hours.

<rucknium> Meeting time! monero-project/meta #1443

<rucknium> 1. Greetings

<vtnerd> Hi

<slowbeardigger:matrix.org> Hello

<jberman> waves

<jeffro256> Howdy

Hello

<articmine> hi

<jpk68:matrix.org> Hello

Hello

<rucknium> 2. Updates. What is everyone working on?

<slowbeardigger:matrix.org> 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 :)

<slowbeardigger:matrix.org> @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)

I'm working on adding Carrot-compatible coinbase transactions to P2Pool (last week I was quite busy IRL, so this work just started)

hello. seeing sech1 move to Carrot/FCMP++ for P2Pool and reviewing anything

<jpk68:matrix.org> Me: attempting to decrease lock contention in monerod

<jberman> Some upstream PR handling and re-reviewing the Carrot hot/cold wallet PR

<rucknium> 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: github.com/Fountain5405/monerosim/issues

<ack-j:matrix.org> Hi

<vtnerd> 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

<jeffro256> me: implemented tevador's suggestion for PQ turnstile indistinguishability: seraphis-migration/monero #456. Reviewing upstream PRs

<rucknium> 3. PQ turnstile spend enables a Carrot/Jamtis distinguisher (privacy leak) (jeffro256/carrot #10).

<jeffro256> PR for K^j_v implementation here: seraphis-migration/monero #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

<jeffro256> If we go with the above change, I'll need to update the Carrot spec

<rucknium> Would the change require anything to be re-audited or receive external review again?

Carrot spec already needs update due to the personalization string / Generator T changing

And seraphis-migration/monero #424

<jeffro256> 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

<jeffro256> DataHoarder: You're right about the T generator, but #424 doesn't require changes to the spec

<jeffro256> It's a big API overhaul, but it didn't change anything with the protocol itself

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

<jeffro256> Yes, the PQ stuff should already be in the latest version of the spec

<rucknium> More on this topic? Should it appear on the agenda next week, too?

<jeffro256> If tevador isn't here, then there's not too much to discuss

<jeffro256> I think that the rest of the discussion could happen on that Github issue

<rucknium> I will take it off the agenda next week unless someone requests it to be placed on the agenda.

<rucknium> 4. FCMP++ to-do list status. Programming tasks (seraphis-migration/monero #53). Reviews and audits (cryptpad.fr/sheet/#/2/sheet/view/yP…9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed). FCMP++ Integration Audit Overview (seraphis-migration/monero #294). Network upgrade [... too long, see mrelay.p2pool.observer/e/yLqkpKILb3IwaHJr ]

<jberman> 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

<jberman> RFQ is going out for gadgets + circuit + fcmp-plus-plus audit, nothing to report on there yet

<jeffro256> Licensing discussion still ongoing in monero-project/monero #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

<jeffro256> I was hoping that he'd be here today, oh well

<rucknium> Thanks, @jberman:monero.social and @jeffro256:monero.social . More on this topic?

That "trick" probably won't extend to the much simpler Polyseed library?

<jeffro256> 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

<jeffro256> Unless tevador chooses to re-license, then Polyseed remains under LGPL

<tobtoht> @jeffro256: How would that work?

<slowbeardigger:matrix.org> What about, relicensing the mx25519 to MPL-2.0 pls split the library?

<slowbeardigger:matrix.org> like BSD-3 the core + C portable implementation, MPL-2.0 the assembly backends

<slowbeardigger:matrix.org> Compilation flags included on the fast assembly[... more lines follow, see mrelay.p2pool.observer/e/mP--pKILQjhCa2N2 ]

<slowbeardigger:matrix.org> I think Trevador said he likes a way like that

<tobtoht> That's exactly the solution tevador suggested.

<slowbeardigger:matrix.org> yeah

<slowbeardigger:matrix.org> if you ask me, that seems to be the “easiest” way

<articmine> The licensing issue raisees many questions for dicussion.

<slowbeardigger:matrix.org> Gets the thing done in a couple of commits, and not a lot of drama

<slowbeardigger:matrix.org> less friction way imo

<articmine> I am just looking at the Github

<jeffro256> @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

<jeffro256> 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

<jpk68:matrix.org> Not sure there's much point to the licensing section of the CoC if it can just be ignored

<jeffro256> Even without mx25519/Polyseed we should probably do this because we are out of compliance with some BSD-3 licensing

<tobtoht> Our biggest licensing issue right now is our GPLv3'd readline dependency

<tobtoht> I suggested replacing it with linenoise from Redis

<jpk68:matrix.org> It would also be a drastic reduction in LoC for that functionality

<rucknium> FWIW, R and python have a license text that can be printed with license().

Would this license content mechanism be available to smartphone wallet apps as well?

<tobtoht> @jpk68:matrix.org: Yep, would also drop ncurses.

<tobtoht> rbrunner: We could expose it in wallet api?

Sounds reasonable.

<rucknium> 5. Relative locks with FCMP++ (monero-project/research-lab #161).

<rucknium> Last meeting, UkoeHB said he would put review of seraphis-migration/monero #445 on his list

<rucknium> Any discussion of this for now? If not, I will move on to the next item.

<rucknium> 6. FCMP beta stressnet (github.com/seraphis-migration/monero/releases). Version 3 launch checklist (seraphis-migration/monero #415).

<jberman> Re: relative locks, I just commented on the original issue here: monero-project/research-lab #161#issuecomment-5345884915

<slowbeardigger:matrix.org> oh boy

<slowbeardigger:matrix.org> :) can’t wait

<jberman> I think it could potentially help strengthen the case for them if the Grease people want to run with that primitive

<jberman> 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

<jberman> 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

<rucknium> I have shut down all my tx spammers and switched my nodes back to regular testnet.

<jberman> 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)

<jberman> And making sure hot/cold wallets are ready for the fork is obviously a requirement for the fork anyway

Did not review that PR yet

<jeffro256> ukoe is the hot/cold PR sort of a prereq for some of the multisig stuff?

Multisig branch is on top of that branch

IIRC it's just tx_builder that's a dep

<jberman> 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

<jberman> 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

<rucknium> @jberman: You could have cuprate on stressnet for that time, too.

<rucknium> More on stressnet?

<jberman> nothing from me

<rucknium> 7. PoW-Admitted Zero-Fee Transactions for P2Pool (gist.github.com/SChernykh/aae5b2d414095e742437134ab20d4353).

<rucknium> sech1. And maybe DataHoarder[m]

nothing from me here at this point

<rucknium> sech1 was here at the beginning of the meeting.

I created monero-project/monero #11102 to make life easier for P2Pool when handling these transactions

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.

<rucknium> More discussion on this item?

<rucknium> We can end the meeting here. Thanks everyone.

<slowbeardigger:matrix.org> Thanks, have a good one y'all

apologies for missing the meeting

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.

<articmine> selsta: What would be an example niche case where copyleft code is not acceptable?

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).

BTCPay Server for example would have extra compliance obligations when integrating Monero, they could disable Polyseed since it's not required for accepting payments.

(I did not research this example so it's possible it would not be an issue for them anyway)

BTCPay Server is open source, so where exactly the problem would be? btcpayserver.org links to their github, which, IMO, counts as "reasonable means" to provide the source code per the MPL-2 license.

<rbrunner7> "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?

^ I think optional here means there is a compile-time switch to disable it.

yes, for the public there would only be one version

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.

<rbrunner7> 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 ...

<rbrunner7> Or would we link in a dummy Polyseed library?

<rbrunner7> All the methods, but no code behind it?

<jpk68:matrix.org> 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

<jpk68:matrix.org> Dependency injection could also be used to circumvent it to some extent

<rbrunner7> Maybe some significant extensions, like using the checksum polynoms to restore a single missing word (as I think to remember that is technically possible)?

<tobtoht> 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.

Speaking of the dart implementation: cake-tech/polyseed_dart #7

<boog900> There is a Rust impl too: github.com/monero-oxide/monero-wallet-util/tree/main/polyseed

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> 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.

<jpk68:matrix.org> Ah, how conducive to the spirit of open source. Let's impound ourselves with more bureaucracy and legal requirements

<kayabanerve:matrix.org> 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.

<kayabanerve:matrix.org> ^ 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.

<kayabanerve:matrix.org> @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 mrelay.p2pool.observer/e/hM-aqKILUG5jX2Ns ]

The rust version doesn't look like a translation at first glance, at least not to the extent that the dart one does.

<kayabanerve:matrix.org> 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.

<jpk68:matrix.org> @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

<kayabanerve:matrix.org> 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 :)

Yes, polyseed is missing a formal specification. That's something that should be fixed.

<jpk68:matrix.org> 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?

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.

<jeffro256> DataHoarder: I misspoke about the T generator, those changes are already in the spec

unbiashed hash to point is changing, so that'd be changed to dc42e1d3307b2d4b3b02729abe577e231d79478141cb5b310ca9fa6e127616a3

(it'd use blake2b with the Monero personalization string)

you changed the representation here, monero-oxide/monero-oxide #188 which changes the derived T value

<jeffro256> Durrr you're right, I copy and pasted the wrong value from that PR

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

also, on master I don't see any pushes since 4 months ago so maybe you are talking about a different local repo?

I am looking at github.com/jeffro256/carrot unless there's somewhere else with the Carrot spec

<ofrnxmr> Fwiw, i think they ship the stock monero binary, so i dont think it has to include anything? > <selsta> BTCPay Server for example would have extra compliance obligations when integrating Monero, they could disable Polyseed since it's not required for accepting payments.

<ofrnxmr> 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

<ofrnxmr> (Just imported view-only wallets)

<jpk68:matrix.org> IIUC, if they download pre-built release binaries and Polyseed/mx25519 is licensed under LGPL, they will indeed have to include licenses

<jpk68:matrix.org> That may not be the case for MPL, however