<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #949

<r​ucknium:monero.social> 1) Greetings

<v​tnerd:monero.social> Hi

Yo

<h​into.janaiyo:matrix.org> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<v​tnerd:monero.social> Took some time off, but should be working on subaddress tests still later this week

<a​ck-j:matrix.org> Hi

<r​ucknium:monero.social> me: I think I will set Dec 31 as the cutoff day for new data to feeding into OSPEAD. There are a few minor unsolved issues, but I now have a system to produce preliminary results. I'll set a tentative internal deadline of Jan 31 to have the results ready regardless of whether I can solve the remaining minor issues.

<h​into.janaiyo:matrix.org> preparing libraries for cuprate usage

Reorganizing some code in the transaction fingerprinting library to be a bit more turnkey

<r​ucknium:monero.social> 3) Discussion. What do we want to discuss?

<h​into.janaiyo:matrix.org> Rucknium: did you make anything of the tor/i2p transaction %?

<r​ucknium:monero.social> No. I cannot really see that in the data. But. Remember that mempool data I was collecting for the blockspace demand analysis, which then turned into the discovery about mining pools delaying tx confirmations unnecessarily? plowsof kept it running on his VPS, so we have the data about when txs first appeared in the mempool for the last 12 months

<r​ucknium:monero.social> That tells us that those txs could be constructed no later than when they appeared in the mempool

<r​ucknium:monero.social> Knowing when txs were constructed is important because the first spendable block after the 10 block lock has the highest probability of having a decoy selected from it. And probably the highest probability of a real spend.

<r​ucknium:monero.social> By the way, Zano is updating their decoy selection algorithm. It has been uniform, which is bad. But they are now fitting a curve like Moser et al. (2018) to de-anonymized txs, I think: blog.zano.org/decoy-selection-algorithm

<r​ucknium:monero.social> I talked with sowle from Zano about a year ago about that. I'm glad they are following through on it.

<r​ucknium:monero.social> Has the discussion about hard fork scheduling moved at all in the last 6 months?

<h​into.janaiyo:matrix.org> interesting stuff - i didn't know the uniform decoy selection was inherited from cryptonote, guess it only makes sense

<r​ucknium:monero.social> IIRC there were suggestions about including BulletProofs++ once reviewed and audited and some PoW changes.

<r​ucknium:monero.social> I think sech1 wanted the PoW changes to be in a release candidate 6 months in advance of a hard fork to give miners a chance to update.

<r​ucknium:monero.social> Diego Salazar said CypherStack has started its review of BP++ libera.monerologs.net/monero-community/20231226#c316342

<d​iego:cypherstack.com> it's true. I said that.

<r​ucknium:monero.social> Thanks, Diego

<d​iego:cypherstack.com> Found a couple issues that we're in contact with the author about. Awaiting a response. Continuing forward in the meantime.

<r​ucknium:monero.social> Thank you for the update 🙏

<r​ucknium:monero.social> Anything more to discuss?

<d​iego:cypherstack.com> Not at the moment. Holidays so things are a bit off and on as you might expect. It'll chug along at a better speed come early January

<r​ucknium:monero.social> Oh. I meant for the meeting in general. I don't mean to rush or expect instant progress :)

<h​into.janaiyo:matrix.org> does bp++ necessitate a new type in monero's codebase?

<h​into.janaiyo:matrix.org> there's already `RCTTypeBulletproofPlus`, so now we'll have `RCTTypeBulletproofPlusPlus`... lol

<r​ucknium:monero.social> I don't know. This is a good point to remind people that Seraphis work and research is happening in #no-wallet-left-behind:monero.social now.

<r​ucknium:monero.social> We can end the meeting here.