15:03:08 MRL meeting in this room in two hours. 17:01:12 Meeting time! https://github.com/monero-project/meta/issues/944 17:01:20 1) Greetings 17:01:25 hi 17:01:51 Hello 17:01:57 hi 17:03:22 2) Updates. What is everyone working on? 17:03:59 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. 17:04:06 me: OSPEAD. 17:04:12 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. 17:04:55 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. 17:04:55 me: serai+cuprate stuff 17:06:43 tobtoht: Sounds like good progress 17:07:25 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 17:07:54 3) Discussion. What do we want to discuss? 17:08:02 People knowledgeable about multisig want to comment on tobtoht 's work? 17:09:22 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. 17:12:44 Looking forward to see something like "MMS in GUI" :) 17:13:20 Although you can probably abstract higher and not bother the user with individual messages, at least not during normal workflow 17:15:17 r​brunner: did you make the decision the use XML? if yes, were there specific reasons? 17:16:23 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. 17:16:28 The API to PyBitmessage is based on XML. I would have opted for JSON, XML for something like this is a bit strange 17:17:02 ah, that's what i assumed 17:17:54 There once was a time where XML was the future, for everything, according to hype 17:18:12 Anybody remember SOAP ... 17:21:14 a question i had about seraphis: assuming JSON-RPC remains, how big would the changes be to the daemon interface? 17:22:23 Never thought about that in detail, but I would guess that the daemon doesn't need many changes in its RPC interfaces 17:22:49 Maybe in pool handling details because there are some other things "to know" about Seraphis transactions 17:23:51 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 :) 17:24:19 Ah, I see :) 17:26:40 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. 17:27:59 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. 17:29:29 Maybe sech1 would know. 17:29:44 Anything else to discuss? 17:29:50 yes to 2, default is to ask on cli/gui 17:29:59 I think most (all?) wallets do 2. You would want to show the user the tx fee before broadcast. 17:30:14 Never gave that much attention and just waited 17:30:22 Time from tx leaving the wallet until pools see it? It can be 5-40 seconds, depending on Dandelion++ luck 17:31:15 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 17:31:17 Thanks, sech1. Maybe I can look at the D++ code and see what the average expected number of hops and delays would be. 17:31:21 "luck" meaning having quick and responsive daemons to pass the tx on for each hop? 17:31:37 Yes, and passing through major pool nodes in the stem phase 17:32:53 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). 17:33:50 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 17:34:02 Yes, I start to remember discussions from the implementation phase. 17:34:12 Long = more than a second and less than a minute. 17:34:16 I think all nodes in the stem will eventually broadcast with random delays 17:34:21 If they don't see it broadcasted 17:34:52 D++ covers many different scenarios and tries its best 17:34:58 `tx-proxy` may need to be accounted for too (unless its statistically irrelevant here, what is the % of tor/i2p txs?) 17:35:11 So maybe it won't be exactly easy to come up with a good average 17:36:39 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. 17:37:06 If those are less than 10%, I could ignore them in a rough calculation. 17:38:55 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. 17:39:24 But more information and ways to check this is always better. 17:39:37 If the node being used has "disable_noise" then d++ wont be used to broadcast tor/i2p tx's 17:39:43 anecdotal but, tor is almost always slower by a order of magnitude than clearnet for me 17:39:59 Will be faster than clrarnet^ 17:40:55 You can see the cliff in the probability distribution in the plot in the last page here: https://www.overleaf.com/read/ndbtkwrbrdjq 17:41:27 Anecdote and theory contradict each other 😅 17:41:46 hinto: Do you know if you disable_noise? 17:42:20 Is this a remote connection through Tor, or a local node that broadcasts txs through Tor? 17:43:05 no, disable_noise is not enabled, so i guess tor + d++ 17:43:26 both remote/local are slower 17:43:32 Selsta / ofrnxmr put me onto the advantages of disable_noise for broadcasting anon tx's 17:43:40 i'm maybe outting my tx's here :) 17:44:50 maybe i'm hitting some insane world-hopping tor circuit every single time 17:46:17 Thanks. Anything more to discuss? 17:48:16 me/boog would appreciate some discussion on the more trivial parts of cuprate, e.g https://github.com/Cuprate/cuprate/issues/46 (closes a nearing 2 year monero issue) 17:48:57 the actual binary name of the application is up for debate as well, current options are `cuprate` and `cuprated` 17:49:07 Rucknium: tor/i2p still uses d++ amon the remote hidden service side 17:51:35 We can end the meeting here. Thanks everyone. 19:54:50 I couldn't find an issue for that. Does this name debate already have a location? 20:00:33 this PR: https://github.com/Cuprate/cuprate/pull/42 20:05:40 Thanks!