15:06:34 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in two hours.
17:00:44 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/941
17:00:50 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:01 <rbrunner> hello
17:01:20 <m-relay> <v​tnerd:monero.social> Hi
17:02:38 <m-relay> <h​into.janaiyo:matrix.org> hello
17:03:40 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:04:23 <m-relay> <j​effro256:monero.social> howdy
17:04:39 <m-relay> <h​into.janaiyo:matrix.org> me: working on misc cuprate stuff
17:04:42 <m-relay> <j​effro256:monero.social> finished first draft of Jamtis changes
17:05:08 <m-relay> <v​tnerd:monero.social> Me: still on beefing up LWS tests, this time working on subaddress tests. Found 4 bugs so far, so it's been worth it.
17:05:30 <m-relay> <r​ucknium:monero.social> me: OSPEAD. And I have new data about suspected Exodus _Mobile_ txs with nonstandard fees. Exodus released a Mobile wallet fix on November 11th: https://github.com/Rucknium/misc-research/blob/main/Monero-Nonstandard-Fees/images/Exodus-Mobile-txs-after-fix-release.png
17:06:55 <m-relay> <r​ucknium:monero.social> I'm not sure all the txs in that category are Exodus Mobile. But the number of those txs fell a lot. In total about 5% of Monero txs were using fees in that range.
17:07:16 <m-relay> <r​ucknium:monero.social> 3) Discussion. What do we want to discuss?
17:07:32 <rbrunner> A bit surprising how widespread use of Exodus seems to be
17:07:37 <m-relay> <s​gp:magicgrants.org> hello
17:08:07 <m-relay> <r​ucknium:monero.social> I am not surprised.
17:10:44 <m-relay> <j​effro256:monero.social> I wanted to discuss the threat models of using multisig now for the CCS versus giving control to one entity. Multisig is still experimental in its current state. However, does the likelihood of multisig having some vulnerability that will be leveraged by one multisig signer outweight the likelihood that a singular entity with a non-multisig wallets loses the funds in a conventiona<clipped messag
17:10:44 <m-relay> <j​effro256:monero.social> l way (getting hacked, theft, etc)?
17:11:42 <m-relay> <r​ucknium:monero.social> Here is luigi1111's proposal: https://github.com/monero-project/meta/issues/935#issuecomment-1841052378
17:11:59 <m-relay> <r​ucknium:monero.social> "For a longer term solution [after March 1, 2024], I do think a community multisig could work (ideally non-experimental, of course)."
17:13:32 <m-relay> <r​ucknium:monero.social> More people having a multisig key to the wallet means that the probability that at least one of the multisig keys is compromised by an adversary IMHO.
17:14:24 <m-relay> <r​ucknium:monero.social> So...maybe multiply the probability of compromise by the probability that the adversary would find an exploit in the experimental multisig or sell the multisig key to someone who did develop an exploit.
17:14:26 <m-relay> <h​into.janaiyo:matrix.org> assuming multisig is ready by march, luigi would "only" hold 3 months of CCS raised funds at the maximum
17:15:05 <m-relay> <r​ucknium:monero.social> Isn't it hard to do multisig with an airgapped machine? That's another thing.
17:15:11 <rbrunner> For me, really hard to say. I tend towards multisig from a security regarding theft point of view. But there are many other ways you can mess up something when using multisig, e.g. too many signers lose keys.
17:15:22 <m-relay> <r​ucknium:monero.social> I like multisig for CCS, but just thinking through the threats.
17:15:54 <rbrunner> Not sure whether airgappend multisig is possible at all. Would somehow surprise me, frankly.
17:16:39 <m-relay> <h​into.janaiyo:matrix.org> i'm assuming a multisig setup would preclude the need for airgapped machines
17:16:51 <rbrunner> Maybe we even don't know, because so far nobody tried that :)
17:17:50 <m-relay> <j​effro256:monero.social> It's possible but definitely a hassle with current wallets. There's not really an app *built* for that use-case, but nothings stopping you from doing it now technically
17:18:28 <rbrunner> Amazing.
17:18:46 <plowsof> We should sponsor hours via the CCS (specifically for jeffro256 / tobtoht to continue working on the ux/other problems?)
17:18:47 <m-relay> <j​effro256:monero.social> It would take twice as many trips as a normal hot/cold airgapped wallet and the messages being passed around would be much bigger
17:19:56 <rbrunner> Then please clone jeffro256 so he can work on multisig and the Seraphis wallet at the same time ...
17:20:18 <m-relay> <j​effro256:monero.social> With Seraphis though, it would be the same number of trips which is nice since you don't need to combine partial key images
17:20:33 <m-relay> <j​effro256:monero.social> lol
17:21:09 <m-relay> <v​tnerd:monero.social> is the expected work in the UI or the underlying multisig code? I thought there was some push to move it closer to MRL-009 ?
17:22:00 <m-relay> <v​tnerd:monero.social> and MRL-009 has security proofs, but none for extensions that compute the viewkey
17:22:10 <rbrunner> As far as I understand the situation, tobtoht intends to work on the UI/UX side only
17:22:31 <m-relay> <v​tnerd:monero.social> thats probably not a deal-breaker (the viewkey)
17:22:41 <m-relay> <t​obtoht:monero.social> Yes, I'm going to focus on UI/UX and make changes to the MMS, not the multisig code itself.
17:22:44 <rbrunner> Replacing PyBitmessage by something modern, and make the whole UI graphical instead of command line like the MMS in the CLI wallet now
17:22:45 <m-relay> <v​tnerd:monero.social> yes, we still dont have a great system to replace PyBitmessage
17:24:05 <rbrunner> Working on the "fundamentals" of multisig would certainly be nice, but I am in the camp of the people who think the "experimental" state is "good enough" for our use case
17:24:13 <rbrunner> given how dire the alternatives look, at least
17:25:05 <m-relay> <t​obtoht:monero.social> vtnerd: I intend to replace PyBitmessage with a centralized self-hostable message relay. It is radically simple, which is why I feel it has a good chance allow us to ship _something_  sooner rather than later.
17:25:07 <m-relay> <t​obtoht:monero.social> No PoW. No distributed storage. No extra client dependencies. No forced reliance on flaky anonymity networks.
17:25:27 <m-relay> <t​obtoht:monero.social> Federation? Distributed storage? It increase complexity exponentially and with that development time. Not saying these aren't lofty goals but let's start with the basics here.
17:25:56 <rbrunner> But there will be *some* spam protection, I guess?
17:26:24 <m-relay> <v​tnerd:monero.social> yes, we have to get the authentication and message exchanges down first
17:27:00 <m-relay> <t​obtoht:monero.social> rbrunner: Yes, through traditional means. Basic access control, rate-limiting, automatically closing abusive channels.
17:27:09 <m-relay> <v​tnerd:monero.social> well this is the issue, you need an authentication system I think, otherwise anyone can jumpin and hijack the messages
17:27:45 <rbrunner> That probably won't make many friends, or will it?
17:27:47 <m-relay> <t​obtoht:monero.social> MMS already encrypts messages for each participant.
17:28:19 <m-relay> <v​tnerd:monero.social> tobtoht: correct, but how does it even know who the participants are in the first place?
17:28:24 <rbrunner> Yeah, reading messages is not the problem.
17:28:51 <rbrunner> Message decrypts = it's the right participant.
17:28:58 <m-relay> <v​tnerd:monero.social> I don't recall how the MMS is encrypted, but
17:29:14 <rbrunner> Private view key
17:29:17 <m-relay> <v​tnerd:monero.social> theres a chicken and egg problem here
17:29:40 <m-relay> <v​tnerd:monero.social> otherwise anyone could jump-in the first round
17:30:03 <m-relay> <v​tnerd:monero.social> after establishing all participants, yes its easier, but the first round doesn't even know participants iirc
17:30:18 <m-relay> <r​ucknium:monero.social> For the CCS wouldn't the private view key be published publicly? Maybe an edge case, but important for the CCS.
17:30:24 <m-relay> <j​effro256:monero.social> The way I envisioned it was that the centralized service could choose to verify thru email, PGP keys, or interactive secure channel auth like Matrix
17:30:59 <rbrunner> It's the private view keys of the wallets before they go "multisig". Not the private view key of the multisig address
17:31:21 <m-relay> <v​tnerd:monero.social> yeah I was thinking PGP myself, hopefully that isnt too hard to setup
17:33:10 <rbrunner> But well, to establish all that before March 1, seems to be ... optimistic.
17:33:55 <m-relay> <v​tnerd:monero.social> and we haven't identified who the participants are either
17:34:04 <rbrunner> And well, all participants running bleeding edge master branch code instead of an official interim release ... phew
17:34:49 <rbrunner> This is tempting faith
17:36:31 <rbrunner> You can do 2/3 multisig "by hand", if you don't have to do too often, and *after* establishing the wallets
17:37:10 <rbrunner> If you go higher, things get hairy
17:38:23 <rbrunner> This is all a bit depressing ...
17:38:53 <m-relay> <t​obtoht:monero.social> I remain optimistic
17:39:17 <rbrunner> But anyway, not sure what kind of successor solutions Luigi had in mind that we could establish in a mere 2 months
17:40:33 <rbrunner> Ok, nearly 3 months
17:40:55 <m-relay> <h​into.janaiyo:matrix.org> tobtoht: how confident are you this could be ready (at least for our use cases) by march 1st 2024?
17:41:20 <m-relay> <t​obtoht:monero.social> 80%
17:42:05 <rbrunner> :)
17:42:31 <rbrunner> We probably still should talk a bit about the case it won't be ready after all. Maybe not today, but soon
17:42:40 <luigi1111> It was supposed to be 3 months. It's not hard and fast. Just meant to spur discussion and changes needed for longer term solutions quickly. 
17:44:05 <luigi1111> Even if multisig was in a good state now it will still take weeks to find the right signers and them to be happy with their setups 
17:44:43 <rbrunner> Yes, would need several rounds of training for everybody to get acquanted with multisig
17:45:16 <rbrunner> Or maybe tobtoht succeeds to come up with a really good UI/UX
17:46:49 <rbrunner> Or better said, user-friendly, simple and easy
17:47:35 <m-relay> <t​obtoht:monero.social> Yes, but still, have all signers practice with a dummy CCS wallet before 'the real deal', collect feedback, integrate changes, etc
17:47:59 <rbrunner> Yup
17:50:42 <plowsof> Definitely , its all fun and games until several people.actualy try it 
17:51:13 <rbrunner> And then go on to manage funds to the tunes of tens of thousands of dollars.
17:52:22 <rbrunner> "Only numbers on screen, don't get nervous" :)
17:56:47 <m-relay> <j​effro256:monero.social> I was also thinking of a certain funding scheme (which albeit is a little less friendly for the donator), which doesn't allow the escrow to lose the funds, but doesn't give the money to the proposer without approval from the escrow. It would work like this: donator and CCS create 2/2 multisig wallet together. Donator sends funds to the 2/2 multisig wallet, then donator partially s<clipped messag
17:56:47 <m-relay> <j​effro256:monero.social> igns a transaction to the proposers' address, then a refund address they the donator owns. If the escrow determines that a proposer completed their milestones, then they add a signature to the proposer partially signed tx, and if not, add a signature to the refund partially signed tx and broadcast
17:58:17 <m-relay> <j​effro256:monero.social> Doesn't require interaction from proposer and doesn't require interaction from the donator after the inital setup
18:00:51 <m-relay> <o​frnxmr:monero.social> Think of this:
18:00:51 <m-relay> <o​frnxmr:monero.social> many projefts accept donations in crypto, such as graphene. 
18:00:51 <m-relay> <o​frnxmr:monero.social> if graphene wanted folks to partially sign tx, theyd likely lose 100% of retail donors
18:01:05 <m-relay> <h​into.janaiyo:matrix.org> would multisig be needed? can't donators just send return address + donated tx id?
18:01:37 <m-relay> <j​effro256:monero.social> This way escrow can't send funds to themselves
18:02:01 <m-relay> <j​effro256:monero.social> They don't have the ability to cryptographically (assuming multisig code is secure)
18:02:24 <m-relay> <r​ucknium:monero.social> I like it. Getting more creative, at least.
18:02:27 <m-relay> <h​into.janaiyo:matrix.org> ahhh i see - either back to donator or to proposer
18:02:37 <plowsof> I donate 100% then i spend the output after ? 
18:02:59 <plowsof> 1 week later? Day before milestone completed?
18:03:00 <m-relay> <j​effro256:monero.social> Well you wouldn't necessary make it mandatory, but have it be the option  for those so inclines ig
18:03:50 <m-relay> <j​effro256:monero.social> Donator couldn't spend output without approval from CCS since its a 2/2 multisig wallet
18:04:23 <m-relay> <r​ucknium:monero.social> BCH has a special wallet + webpage setup for Flipstarters to create partially signed AnyoneCanPay txs for crowdfunding. Works differently because the threshold for sending to the worker is just that the funding goal amount is reached. It's not a multisig (I think).
18:04:42 <plowsof> Sounds similar to BCH's collective funding method which wont(?) Be possible with seraphis (but could be?) Rucknium knows more about that
18:06:15 <m-relay> <r​ucknium:monero.social> I brought up Flipstarter because it has a "smooth enough" special interaction between a wallet (Electron Cash) and a web page. IIRC they improved the UX recently so you don't need a special wallet plugin, but they had it before.
18:06:36 <plowsof> Interesting jeffro256
18:07:23 <m-relay> <o​frnxmr:monero.social> thats a lot of wallets
18:07:38 <m-relay> <h​into.janaiyo:matrix.org> although escrow wouldn't be able to divert funds, they can still 1. deadlock forever 2. lose the keys, right?
18:07:55 <m-relay> <o​frnxmr:monero.social> and a lot of seeds for (someone) to have the keys for
18:07:57 <m-relay> <j​effro256:monero.social> Yeah a wallet plugin which makes an ephemeral 2/2 multisig wallet (perhaps with `monero-javascript`) could make the UX actually really smooth
18:08:04 <m-relay> <o​frnxmr:monero.social> hintos #2 is what im getting at
18:09:15 <m-relay> <r​ucknium:monero.social> The escrow agent can loose the keys, but you can have multiple escrow agents with the same key. There is less security risk in this setup. The multiple agents would also have to have the partially signed txs.
18:09:23 <m-relay> <r​ucknium:monero.social> lose*
18:09:32 <m-relay> <h​into.janaiyo:matrix.org> this scheme + some deadman switch to auto send funds after a period of time would be interesting
18:09:59 <m-relay> <j​effro256:monero.social> yes escrow could choose to deadlock funds or lose the keys still, but now there isn't a financial incentive to hack the wallet or "steal" coins. Since it is not possible to steal coins, the escrow can focus more on making the keys redundant
18:10:30 <m-relay> <j​effro256:monero.social> With a normal wallet, the more redundant you make the keys, the larger your attack surface is to get hacked
18:10:38 <m-relay> <o​frnxmr:monero.social> I see no reason to burden a donor with creating wallets or any speciak anything
18:10:53 <m-relay> <o​frnxmr:monero.social> They need only send funds. The rest is our problem
18:10:56 <m-relay> <j​effro256:monero.social> But now the effects of someone else having knowledge of the keys is minimized
18:11:04 <m-relay> <o​frnxmr:monero.social> Dont need a refund address, dont need to sign anything
18:11:07 <m-relay> <o​frnxmr:monero.social> Just deposit and walk away
18:11:21 <m-relay> <h​into.janaiyo:matrix.org> i think we're re-inventing smart contracts :)
18:11:29 <m-relay> <o​frnxmr:monero.social> Yei
18:11:54 <m-relay> <j​effro256:monero.social> Ostensibly they would actually be more inclined to donate if they knew the funds were safer and weren't going to be diverted to some hacker
18:12:17 <m-relay> <o​frnxmr:monero.social> and their opsec is to be trusted?
18:12:30 <m-relay> <j​effro256:monero.social> Whose opsec ?
18:12:49 <m-relay> <o​frnxmr:monero.social> The donators, who partially signed the tx already
18:13:25 <m-relay> <j​effro256:monero.social> They don't need ongoing OPSEC models, they just need to fund the wallet, partially sign, then shred everything and forget about it
18:13:47 <m-relay> <r​ucknium:monero.social> This would not allow repurposing CCS funds, of course. Just return to sender.
18:13:56 <m-relay> <j​effro256:monero.social> They're already custodying their own funds, so if they screw themselves out of funds, that would happen anyways
18:14:10 <m-relay> <r​ucknium:monero.social> Repurposing if the original worker decided to stop working
18:14:57 <m-relay> <o​frnxmr:monero.social> red taping the donation process is backwards to me
18:15:58 <m-relay> <a​ck-j:matrix.org> Not sure if this was brought up yet but since we’re talking about CCS. A 2696 xmr donation was just made to the monero general fund. It could have been the CCS theif returning most of the funds
18:16:20 <m-relay> <o​frnxmr:monero.social> The problem is: were playing with peanuts and accept this as the norm
18:16:21 <m-relay> <r​ucknium:monero.social> We can officially end the meeting here. Feel free to continue. Thanks for trying to fix multisig everyone.
18:16:41 <plowsof> ack-j its been confirmed as real / swept to the general fund 2 wallet by binaryFate some moments ago
18:18:16 <m-relay> <a​ck-j:matrix.org> Confirmed as real meaning we believe it was the thief?
18:19:14 <m-relay> <r​ucknium:monero.social> xmrack: AFAIK, no. "Real" meaning that it wasn't change going back into the wallet.
18:19:37 <m-relay> <j​effro256:monero.social> Thats insane
18:19:48 <m-relay> <r​ucknium:monero.social> Since with view key only you are not sure if an incoming tx is change.
18:22:57 <plowsof> Real as in no further questions required xD
18:27:09 <m-relay> <a​ck-j:matrix.org> Understood. Strange that 2696 was set to GF when only 2675 was stolen. Maybe they are paying interest :D
18:28:47 <m-relay> <o​frnxmr:monero.social> Needed 69 for the wink to show
18:29:33 <m-relay> <j​effro256:monero.social> lol
18:29:57 <plowsof> 😉
18:33:32 <m-relay> <a​ck-j:matrix.org> Lol