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

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

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

hi

Hello

<t​obtoht:monero.social> hi

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

<t​obtoht:monero.social> Wanted to report that I made some initial progress on my multisig UI/UX work. MMS now speaks JSON instead of XML and I adapted it to connect to a totally bare-bones and (currently) insecure backend that uses FastAPI + Redis. Set up a 2/3 multisig wallet using the CLI and sent a transaction.

<r​ucknium:monero.social> me: OSPEAD.

<t​obtoht:monero.social> For now I'm going to assume the participants have an out-of-band secure channel (like an encrypted matrix group chat) which a coordinator can use to distribute a shared secret (and channel link) that is used for encrypting the intial setup. All participants must confirm the multisig primary address matches after setup.

<t​obtoht:monero.social> The fact that you can only do one transaction signing attempt per multisig info sync is a very easy failure mode to hit and will need to find a clever way to mitigate this as much as possible.

<h​into.janaiyo:matrix.org> me: serai+cuprate stuff

tobtoht: Sounds like good progress

me: Im still stuck in subaddress testing in LWS. I think macOS is hitting a stack overflow, as the tests fail intermittently, and address sanitize is complaining loudly about longhash overflowing

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

<r​ucknium:monero.social> People knowledgeable about multisig want to comment on tobtoht 's work?

Sounds good. I think that's a very pragmatic approach how they develop, and that's good. Not becoming victim of the "not invented here" syndrom and starting from scratch also gives hope.

Looking forward to see something like "MMS in GUI" :)

Although you can probably abstract higher and not bother the user with individual messages, at least not during normal workflow

<h​into.janaiyo:matrix.org> r​brunner: did you make the decision the use XML? if yes, were there specific reasons?

<t​obtoht:monero.social> Yes, I'll start with something like MMS+GUI and slowly work it away to where the user (mostly) doesn't have to interact with it directly.

The API to PyBitmessage is based on XML. I would have opted for JSON, XML for something like this is a bit strange

<h​into.janaiyo:matrix.org> ah, that's what i assumed

There once was a time where XML was the future, for everything, according to hype

Anybody remember SOAP ...

<h​into.janaiyo:matrix.org> a question i had about seraphis: assuming JSON-RPC remains, how big would the changes be to the daemon interface?

Never thought about that in detail, but I would guess that the daemon doesn't need many changes in its RPC interfaces

Maybe in pool handling details because there are some other things "to know" about Seraphis transactions

<h​into.janaiyo:matrix.org> great - i'll probably be responsible for porting the current daemon RPC to cuprate and was wondering if i'd have to rewrite it all when seraphis arrives :)

Ah, I see :)

<r​ucknium:monero.social> Does anyone have an estimate for the average time between when a tx is constructed (specifically when `monerod` sends back data to the wallet from a `get_output_distribution` RPC request) and when a mining pool would see it? I am analyzing ring members from the first spendable block after the 10 block lock.

<r​ucknium:monero.social> The parts are maybe: 1) Data comes back to wallet 2) Do most wallets ask users to confirm between tx construction and broadcast? 3) Dandelion++ stem phase, then fluff phase.

<r​ucknium:monero.social> Maybe sech1 would know.

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

<h​into.janaiyo:matrix.org> yes to 2, default is to ask on cli/gui

<t​obtoht:monero.social> I think most (all?) wallets do 2. You would want to show the user the tx fee before broadcast.

Never gave that much attention and just waited

Time from tx leaving the wallet until pools see it? It can be 5-40 seconds, depending on Dandelion++ luck

The wallet asks for confirmation before sending, and it display the fee to be used, so I guess tx is fully constructed at this point

<r​ucknium:monero.social> Thanks, sech1. Maybe I can look at the D++ code and see what the average expected number of hops and delays would be.

"luck" meaning having quick and responsive daemons to pass the tx on for each hop?

Yes, and passing through major pool nodes in the stem phase

<r​ucknium:monero.social> rbrunner: D++ is a random process. Each node broacasts it to fluff with some probability. And waits to send as a stem phase (if stem phase is randomly chosen) with a random small delay. (AFAIK from the D++ paper).

<r​ucknium:monero.social> And if stem fails due to black hole attack or just nodes not broadcasting for some non-malicious reason, the original node eventually broadcasts the tx in fluff phase after a long time

Yes, I start to remember discussions from the implementation phase.

<r​ucknium:monero.social> Long = more than a second and less than a minute.

I think all nodes in the stem will eventually broadcast with random delays

If they don't see it broadcasted

D++ covers many different scenarios and tries its best

<h​into.janaiyo:matrix.org> `tx-proxy` may need to be accounted for too (unless its statistically irrelevant here, what is the % of tor/i2p txs?)

So maybe it won't be exactly easy to come up with a good average

<r​ucknium:monero.social> If someone has a good argument for why tor/i2p txs would be more than 5%, please say it. IIRC tor/i2p txs do not use D++, so they may be faster.

<r​ucknium:monero.social> If those are less than 10%, I could ignore them in a rough calculation.

<r​ucknium:monero.social> This isn't the only way to try to measure this, by the way. wallet2 has a uniform distribution added to the recent spend window. At the end of the recent spend window, the probability mass drops like a cliff to just the gamma distribution. So you can see if the cliff is aligned where it should be.

<r​ucknium:monero.social> But more information and ways to check this is always better.

If the node being used has "disable_noise" then d++ wont be used to broadcast tor/i2p tx's

<h​into.janaiyo:matrix.org> anecdotal but, tor is almost always slower by a order of magnitude than clearnet for me

Will be faster than clrarnet^

<r​ucknium:monero.social> You can see the cliff in the probability distribution in the plot in the last page here: overleaf.com/read/ndbtkwrbrdjq

<r​ucknium:monero.social> Anecdote and theory contradict each other 😅

<r​ucknium:monero.social> hinto: Do you know if you disable_noise?

<r​ucknium:monero.social> Is this a remote connection through Tor, or a local node that broadcasts txs through Tor?

<h​into.janaiyo:matrix.org> no, disable_noise is not enabled, so i guess tor + d++

<h​into.janaiyo:matrix.org> both remote/local are slower

Selsta / ofrnxmr put me onto the advantages of disable_noise for broadcasting anon tx's

<h​into.janaiyo:matrix.org> i'm maybe outting my tx's here :)

<h​into.janaiyo:matrix.org> maybe i'm hitting some insane world-hopping tor circuit every single time

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

<h​into.janaiyo:matrix.org> me/boog would appreciate some discussion on the more trivial parts of cuprate, e.g Cuprate/cuprate #46 (closes a nearing 2 year monero issue)

<h​into.janaiyo:matrix.org> the actual binary name of the application is up for debate as well, current options are `cuprate` and `cuprated`

<v​tnerd:monero.social> Rucknium: tor/i2p still uses d++ amon the remote hidden service side

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

<r​brunner7:monero.social> I couldn't find an issue for that. Does this name debate already have a location?

<b​oog900:monero.social> this PR: Cuprate/cuprate #42

<r​brunner7:monero.social> Thanks!