<loop.ster:matrix.org> > <UkoeHB> @loop.ster oh perfect, doesn't that directly solve monero-project/research-lab #161#issuecomment-5396778447 ? Not sure why CjS77 mentioned it as a problem.

<loop.ster:matrix.org> As I mentioned in the PR comment, I suspected it might, but I hadn't thought it through. So it was just a gut feel, and so I didn't want to assert that the issue was resolved, but kinda left the idea out there to be explored. (I'm CjS77 on GH)

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

@loop.ster ah got it, so the VCOF exploration was for an older version of Greese. Practically speaking would applications really need to adopt nanotransactions like you describe? I'd think a minor level of trust would allow payment in advance for aggregations of those payments.

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

<jeffro256> Howdy

<rucknium> 1. Greetings

Hello

Hi

<jpk68:matrix.org> Hello

<vtnerd> Hi

Hello

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

mx25519 and polyseed maintenance/updates

I'm working on adding Carrot math to P2Pool - I'll be likely done in 1-2 weeks, after that P2Pool will be ready for stressnet testing

<jberman> waves

<rucknium> me: Updated the IP package to work with the latest version of R: github.com/Rucknium/IP . It has been accepted to go back onto the Comprehensive R Archive Network (CRAN). Also working with monerosim. (Thanks to @gingeropolous:monero.social for fixing the issues I found so far github.com/Fountain5405/monerosim/issues ).

<vtnerd> Me: tracked down a regression in lws, updated several monerod prs with serialization almost ready to push, and another zmq thing with yet more serialization changes

FYI: mx25519 optimizations from the past week made the amd64x implementation about 20% faster (98k cycles per scalar mult on Zen2).

<jberman> PR reviews mostly, and started back working on Serai

<jeffro256> me: working on people's reports for Carrot, updating the Carrot spec for tevador's suggested changes, and working on j-berman's hot-cold feedback

<jeffro256> And upstream shtuff

<jpk68:matrix.org> Me: reviews, fixing some bugs, beginning work on Tor Control integration

<rucknium> 3. 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/pt6mxKQLWXJsNVVj ]

<jberman> On Research Task audits: Request for quotes on circuits + gadget + fcmp-plus-plus lib has gone out, we've gotten some responses but nothing major to report yet

<rucknium> Another thing: I plan to upgrade the Matrix room version of this room to version 12 after the end of the meeting. If anyone thinks I shouldn't do that, speak now.

<jberman> On tasks: next major item is hot/cold wallet integration @jeffro256:monero.social mentioned above, in the final cycles now on that task

<jberman> Here's the latest upstream PR for FCMP++ integration: github.com/monero-project/monero/pull/10361

<rucknium> Thanks, @jberman:monero.social . Anything more on this item?

<rucknium> Come to think of it, I should probably coordinate with DataHoarder[m] on the Matrix room upgrade since we will have to switch the IRC-Matrix bridge bot to the next version room.

do it anytime.

<rucknium> DataHoarder: Sounds good. Thanks.

I automated that part and it'll follow the tombstone with all IRC puppets and relay.

<rucknium> Well you are ahead of me :)

me: reviews, pending_tx sanity checker nonsense

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

<jberman> u/CjS77 expressed hesitation in building with them until the feature would be confirmed included in Monero

<jberman> > I guess I'd like to take the temperature on the level of support before committing to anything.

<jeffro256> What about its viability as it relates to Grease?

<jberman> I responded that I have a hard time seeing significant resistance to the feature if the protocol is fully specced + there's a developemnt path to utilizing the feature

<jberman> monero-project/research-lab #161#issuecomment-5396778447

<jberman> Sounds like it would be a major change to their protocol

Classic chicken-egg, but shipping the consensus code for the lock is probably way less work than designing the actual PC protocol.

<jberman> If someone was actually interested in designing the actual PC protocol, then I think it would make sense to seek funding for that design, rather than funding for a protocol that relies on trust

<jberman> Doesn't make sense to me that they wouldn't be interested in that work personally

<jberman> I mean, I guess it's not a major risk to include that change to consensus either way, but it would be nice to have a concrete path to using it established first

One thing that's still TBD is the lock length since we can only ship one value. 1 week would have some advantages for PCs compared to 1 day, but maybe 3 days is a good compromise.

<rucknium> Does anyone have a way to contact @fiatdemise:matrix.org ? IMHO, XMRChat.com is the most obvious first use case for payment channels. Maybe that could get some momentum behind the payment channels idea.

<rucknium> Maybe I will try to email the XMRChat support email address.

<jberman> Another thing u/CjS77 raised in that issue is the issue of requiring O(n) state growth for channel updates, and UkoeHB sketched a potential way to avoid it? I know bitcoin would need a consensus change to achieve it on their end (eltoo), so seems like another open area to consider

<fiatdemise:matrix.org> Hi, I'm not familiar with payment channels or their benefit, but I'll take a look at an email with more info.

I sketched some requirements for one way to avoid it, and Cjs77 pointed out the speculative/experimental VCOF from greese v1 aims at the same problem. But no guaranteed solve.

<rucknium> @fiatdemise:matrix.org: Hi! If users are getting frustrated with the 10 block lock, payment channels could solve that, at the cost of more complexity. I will email you later.

I think O(n) channels are acceptable. One state is maybe 300 bytes?

<rucknium> The BTC Lightning Network is based on aggregating many payment channels

<jberman> > Not an issue for moderately active channels (n < 1000), but for some of the applications that I would love to see for channels that involve many thousands of updates (fine-grained streaming content for example)

<jberman> I think that was a solid point

Let's aim for incremental improvements

Don't we need a perfect design for payment channels to be useful

<rucknium> Anyone aware of BTC Lightning being used for fine-grained streaming content?

Don't think*

It's better to have non-perfect relative locks with non-perfect (but working) payment channels than nothing.

<jberman> point remains it would be nice to have a fully developed protocol prior to shipping a consensus change that has these sort of kinks ironed out and understood (and provably functioning payment channels)

Then we're back to the chicken egg problem

Didn't tevador post a sketch of such a protocol? And if yes, isn't that at least a starting point?

<jberman> Ya, I really don't think u/CjS77 would have an easier time getting funding after this change is merged versus before, so I really don't think this is actually a chicken egg problem

can we add one more point to the agenda? is monero-project/monero #11155 or monero-project/monero #11152 preferred? or both? we need to decide for the next release. maybe jeffro can explain.

<rucknium> selsta: Yes. I can add it at the end.

<rucknium> More discussion on relative locks for now?

<jberman> In any case, I don't think the change needs to be held back. I think it's ok. At the same time, I'd like to see a concrete development path for it

Re: relative locks I propose we keep pushing forward with PR to add the basic rule. So far there seem no strong/direct objections, just jberman preferring a protocol be more fleshed out.

It seems the Greese team isn't prepare to flesh that out, so idk if any progress will be made on that front.

<jberman> we can share this convo with them and see what happens on that front

<rucknium> Maybe one of the authors of those Monero payment channel papers can write a new paper with relative locks :)

<rucknium> I mean, maybe they could be contacted. Could be worth a shot. But probably a 9 month wait on something like that.

<jberman> ya I wouldn't veto this change pending a 9 month wait, I personally do think it's ok

If we are 9mo out from hf, that would be good timing for a paper for someone to pick up and implement.

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

as mentioned before, I assume this also brings up the changes from the fcmp staging branch onto v3?

<jberman> Hot/cold PR is the major lingering item (I haven't updated that checklist)

<jberman> DataHoarder: yes, and latest master

👍

<jeffro256> I'm working on responding to some reports, and then I'll be on top of finishing hot/cold

<rucknium> 6. Validating key images. monero-project/monero #11155 monero-project/monero #11152

yes, does it make sense for the release to just merge 11152 while 11155 being merged to master?

<jeffro256> SGTM

<jberman> both look fine

<rucknium> Any more discussion on this topic?

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

room upgrade time. Which version is it?

<jeffro256> Thanks everyone!

<rucknium> DataHoarder[m]: We are on version 6 now. Intend to upgrade to version 12

Room version 6 -> 12?

Lounge as well? We can move discussion there if anything needs to be said.

<rucknium> I'm not Matrix admin in Lounge.

<rucknium> I mean, I can't upgrade #monero-research-lounge:monero.social because I am not an admin there.

👍️ > <@rucknium> I mean, I can't upgrade #monero-research-lounge:monero.social because I am not an admin there.

<rucknium> Matrix users will need to click/tap a button below to go to the upgraded room.

awaiting the upgrade