06:53:06 <br-m> <loop.ster:matrix.org> > <UkoeHB> @loop.ster oh perfect, doesn't that directly solve https://github.com/monero-project/research-lab/issues/161#issuecomment-5396778447 ? Not sure why CjS77 mentioned it as a problem.
06:53:06 <br-m> <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)
15:01:58 <br-m> <rucknium> MRL meeting in this room in two hours.
16:44:12 <UkoeHB> @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.
17:00:20 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1448
17:00:24 <br-m> <jeffro256> Howdy
17:00:31 <br-m> <rucknium> 1. Greetings
17:00:34 <sech1> Hello
17:00:47 <tevador> Hi
17:00:50 <br-m> <jpk68:matrix.org> Hello
17:01:05 <br-m> <vtnerd> Hi
17:01:12 <rbrunner> Hello
17:02:12 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:07 <tevador> mx25519 and polyseed maintenance/updates
17:03:21 <sech1> 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
17:03:22 <br-m> <jberman> waves
17:03:35 <br-m> <rucknium> me: Updated the IP package to work with the latest version of R: https://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 https://github.com/Fountain5405/monerosim/issues ).
17:04:38 <br-m> <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 
17:05:02 <tevador> FYI: mx25519 optimizations from the past week made the amd64x implementation about 20% faster (98k cycles per scalar mult on Zen2).
17:05:05 <br-m> <jberman> PR reviews mostly, and started back working on Serai
17:06:25 <br-m> <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 
17:06:33 <br-m> <jeffro256> And upstream shtuff 
17:06:50 <br-m> <jpk68:matrix.org> Me: reviews, fixing some bugs, beginning work on Tor Control integration
17:07:19 <br-m> <rucknium> 3. 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/pt6mxKQLWXJsNVVj ]
17:08:35 <br-m> <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
17:08:55 <br-m> <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.
17:10:08 <br-m> <jberman> On tasks: next major item is hot/cold wallet integration @jeffro256:monero.social mentioned above, in the final cycles now on that task
17:11:25 <br-m> <jberman> Here's the latest upstream PR for FCMP++ integration: github.com/monero-project/monero/pull/10361  
17:12:59 <br-m> <rucknium> Thanks, @jberman:monero.social . Anything more on this item?
17:14:22 <br-m> <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.
17:14:30 <DataHoarder> do it anytime.
17:14:46 <br-m> <rucknium> DataHoarder: Sounds good. Thanks.
17:14:48 <DataHoarder> I automated that part and it'll follow the tombstone with all IRC puppets and relay.
17:15:10 <br-m> <rucknium> Well you are ahead of me :)
17:15:33 <UkoeHB> me: reviews, pending_tx sanity checker nonsense
17:15:55 <br-m> <rucknium> 4. Relative locks with FCMP++ (https://github.com/monero-project/research-lab/issues/161).
17:17:51 <br-m> <jberman> u/CjS77 expressed hesitation in building with them until the feature would be confirmed included in Monero
17:18:04 <br-m> <jberman> > I guess I'd like to take the temperature on the level of support before committing to anything.
17:18:41 <br-m> <jeffro256> What about its viability as it relates to Grease?
17:18:58 <br-m> <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
17:19:22 <br-m> <jberman> https://github.com/monero-project/research-lab/issues/161#issuecomment-5396778447
17:19:44 <br-m> <jberman> Sounds like it would be a major change to their protocol
17:20:19 <tevador> Classic chicken-egg, but shipping the consensus code for the lock is probably way less work than designing the actual PC protocol.
17:21:33 <br-m> <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
17:21:55 <br-m> <jberman> Doesn't make sense to me that they wouldn't be interested in that work personally
17:23:51 <br-m> <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
17:25:43 <tevador> 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.
17:26:30 <br-m> <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.
17:27:10 <br-m> <rucknium> Maybe I will try to email the XMRChat support email address.
17:27:56 <br-m> <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
17:29:24 <br-m> <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.
17:30:57 <UkoeHB> 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.
17:31:54 <br-m> <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.
17:32:19 <tevador> I think O(n) channels are acceptable. One state is maybe 300 bytes?
17:33:12 <br-m> <rucknium> The BTC Lightning Network is based on aggregating many payment channels
17:34:08 <br-m> <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)
17:34:20 <br-m> <jberman> I think that was a solid point
17:35:05 <tevador> Let's aim for incremental improvements
17:35:10 <UkoeHB> Don't we need a perfect design for payment channels to be useful
17:35:11 <br-m> <rucknium> Anyone aware of BTC Lightning being used for fine-grained streaming content?
17:35:39 <UkoeHB> Don't think*
17:36:25 <tevador> It's better to have non-perfect relative locks with non-perfect (but working) payment channels than nothing.
17:36:50 <br-m> <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)
17:37:49 <tevador> Then we're back to the chicken egg problem
17:38:19 <rbrunner> Didn't tevador post a sketch of such a protocol? And if yes, isn't that at least a starting point?
17:38:50 <br-m> <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 
17:40:07 <selsta> can we add one more point to the agenda? is https://github.com/monero-project/monero/pull/11155 or https://github.com/monero-project/monero/pull/11152 preferred? or both? we need to decide for the next release. maybe jeffro can explain.
17:40:43 <br-m> <rucknium> selsta: Yes. I can add it at the end.
17:43:11 <br-m> <rucknium> More discussion on relative locks for now?
17:43:32 <br-m> <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
17:44:04 <UkoeHB> 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.
17:45:03 <UkoeHB> It seems the Greese team isn't prepare to flesh that out, so idk if any progress will be made on that front.
17:46:01 <br-m> <jberman> we can share this convo with them and see what happens on that front
17:46:03 <br-m> <rucknium> Maybe one of the authors of those Monero payment channel papers can write a new paper with relative locks :)
17:46:54 <br-m> <rucknium> I mean, maybe they could be contacted. Could be worth a shot. But probably a 9 month wait on something like that.
17:47:53 <br-m> <jberman> ya I wouldn't veto this change pending a 9 month wait, I personally do think it's ok
17:48:36 <UkoeHB> If we are 9mo out from hf, that would be good timing for a paper for someone to pick up and implement.
17:49:47 <br-m> <rucknium> 5. FCMP beta stressnet (https://github.com/seraphis-migration/monero/releases/). Version 3 launch checklist (https://github.com/seraphis-migration/monero/pull/415).
17:50:35 <DataHoarder> as mentioned before, I assume this also brings up the changes from the fcmp staging branch onto v3?
17:50:57 <br-m> <jberman> Hot/cold PR is the major lingering item (I haven't updated that checklist)
17:51:09 <br-m> <jberman> DataHoarder: yes, and latest master
17:51:15 <DataHoarder> 👍
17:53:16 <br-m> <jeffro256> I'm working on responding to some reports, and then I'll be on top of finishing hot/cold 
17:55:26 <br-m> <rucknium> 6. Validating key images. https://github.com/monero-project/monero/pull/11155 https://github.com/monero-project/monero/pull/11152
17:56:09 <selsta> yes, does it make sense for the release to just merge 11152 while 11155 being merged to master?
17:57:13 <br-m> <jeffro256> SGTM 
17:58:54 <br-m> <jberman> both look fine
18:00:26 <br-m> <rucknium> Any more discussion on this topic?
18:01:59 <br-m> <rucknium> We can end the meeting here. Thanks everyone.
18:02:50 <DataHoarder[m]> room upgrade time. Which version is it?
18:02:53 <br-m> <jeffro256> Thanks everyone!
18:03:31 <br-m> <rucknium> DataHoarder[m]: We are on version 6 now. Intend to upgrade to version 12
18:03:31 <DataHoarder[m]> Room version 6 -> 12?
18:04:06 <DataHoarder[m]> Lounge as well? We can move discussion there if anything needs to be said.
18:05:31 <br-m> <rucknium> I'm not Matrix admin in Lounge.
18:06:25 <br-m> <rucknium> I mean, I can't upgrade #monero-research-lounge:monero.social  because I am not an admin there.
18:06:35 <DataHoarder[m]> 👍️ > <@rucknium> I mean, I can't upgrade #monero-research-lounge:monero.social  because I am not an admin there.
18:10:20 <br-m> <rucknium> Matrix users will need to click/tap a button below to go to the upgraded room.
19:18:44 <DataHoarder> awaiting the upgrade