Monero Research Lab Meeting - Wed 06 December 2023, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Discuss: How to confirm security of Monero's multisignature protocol? Do we need mathematical security proofs, and can we get them? Info:

• Brandon Goodell and Sarang Noether (2018) "Thring Signatures and their Applications to Spender-Ambiguous Digital Currencies"
• Monero multi-signature patch review by Inference
• Rust alternative implementation by @kayabaNerve

3. Discuss: Exploring Trustless zk-SNARKs for Monero's payment protocol. What are the bottlenecks for potential implementation?

4. Improvements to the decoy selection algorithm ( Decoy Selection Algorithm - Areas to Improve, Binning PoC, OSPEAD ) @j-berman @Rucknium

5. Seraphis. ( UkoeHB's Seraphis Proof of Concept work, Seraphis repo ).

6. MRL Meta: "Cat herding", i.e. prioritization of research areas and features. Active recruitment of technical talent, MRL structure, funding (@Rucknium & others) MoneroResearch.info repository of Monero-related research papers, Reddit discussion

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#938

[plowsof]

Logs

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

< r​ucknium:monero.social > Meeting time! #941

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

< rbrunner > hello

< v​tnerd:monero.social > Hi

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

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

< j​effro256:monero.social > howdy

< h​into.janaiyo:matrix.org > me: working on misc cuprate stuff

< j​effro256:monero.social > finished first draft of Jamtis changes

< 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.

< 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

< 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.

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

< rbrunner > A bit surprising how widespread use of Exodus seems to be

< s​gp:magicgrants.org > hello

< r​ucknium:monero.social > I am not surprised.

< 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

< j​effro256:monero.social > l way (getting hacked, theft, etc)?

< r​ucknium:monero.social > Here is luigi1111's proposal: #935 (comment)

< 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)."

< 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.

< 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.

< h​into.janaiyo:matrix.org > assuming multisig is ready by march, luigi would "only" hold 3 months of CCS raised funds at the maximum

< r​ucknium:monero.social > Isn't it hard to do multisig with an airgapped machine? That's another thing.

< 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.

< r​ucknium:monero.social > I like multisig for CCS, but just thinking through the threats.

< rbrunner > Not sure whether airgappend multisig is possible at all. Would somehow surprise me, frankly.

< h​into.janaiyo:matrix.org > i'm assuming a multisig setup would preclude the need for airgapped machines

< rbrunner > Maybe we even don't know, because so far nobody tried that :)

< 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

< rbrunner > Amazing.

< plowsof > We should sponsor hours via the CCS (specifically for jeffro256 / tobtoht to continue working on the ux/other problems?)

< 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

< rbrunner > Then please clone jeffro256 so he can work on multisig and the Seraphis wallet at the same time ...

< 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

< j​effro256:monero.social > lol

< 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 ?

< v​tnerd:monero.social > and MRL-009 has security proofs, but none for extensions that compute the viewkey

< rbrunner > As far as I understand the situation, tobtoht intends to work on the UI/UX side only

< v​tnerd:monero.social > thats probably not a deal-breaker (the viewkey)

< t​obtoht:monero.social > Yes, I'm going to focus on UI/UX and make changes to the MMS, not the multisig code itself.

< rbrunner > Replacing PyBitmessage by something modern, and make the whole UI graphical instead of command line like the MMS in the CLI wallet now

< v​tnerd:monero.social > yes, we still dont have a great system to replace PyBitmessage

< 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

< rbrunner > given how dire the alternatives look, at least

< 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.

< t​obtoht:monero.social > No PoW. No distributed storage. No extra client dependencies. No forced reliance on flaky anonymity networks.

< 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.

< rbrunner > But there will be some spam protection, I guess?

< v​tnerd:monero.social > yes, we have to get the authentication and message exchanges down first

< t​obtoht:monero.social > rbrunner: Yes, through traditional means. Basic access control, rate-limiting, automatically closing abusive channels.

< v​tnerd:monero.social > well this is the issue, you need an authentication system I think, otherwise anyone can jumpin and hijack the messages

< rbrunner > That probably won't make many friends, or will it?

< t​obtoht:monero.social > MMS already encrypts messages for each participant.

< v​tnerd:monero.social > tobtoht: correct, but how does it even know who the participants are in the first place?

< rbrunner > Yeah, reading messages is not the problem.

< rbrunner > Message decrypts = it's the right participant.

< v​tnerd:monero.social > I don't recall how the MMS is encrypted, but

< rbrunner > Private view key

< v​tnerd:monero.social > theres a chicken and egg problem here

< v​tnerd:monero.social > otherwise anyone could jump-in the first round

< v​tnerd:monero.social > after establishing all participants, yes its easier, but the first round doesn't even know participants iirc

< 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.

< 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

< rbrunner > It's the private view keys of the wallets before they go "multisig". Not the private view key of the multisig address

< v​tnerd:monero.social > yeah I was thinking PGP myself, hopefully that isnt too hard to setup

< rbrunner > But well, to establish all that before March 1, seems to be ... optimistic.

< v​tnerd:monero.social > and we haven't identified who the participants are either

< rbrunner > And well, all participants running bleeding edge master branch code instead of an official interim release ... phew

< rbrunner > This is tempting faith

< rbrunner > You can do 2/3 multisig "by hand", if you don't have to do too often, and after establishing the wallets

< rbrunner > If you go higher, things get hairy

< rbrunner > This is all a bit depressing ...

< t​obtoht:monero.social > I remain optimistic

< rbrunner > But anyway, not sure what kind of successor solutions Luigi had in mind that we could establish in a mere 2 months

< rbrunner > Ok, nearly 3 months

< h​into.janaiyo:matrix.org > tobtoht: how confident are you this could be ready (at least for our use cases) by march 1st 2024?

< t​obtoht:monero.social > 80%

< rbrunner > :)

< rbrunner > We probably still should talk a bit about the case it won't be ready after all. Maybe not today, but soon

< 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.

< 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

< rbrunner > Yes, would need several rounds of training for everybody to get acquanted with multisig

< rbrunner > Or maybe tobtoht succeeds to come up with a really good UI/UX

< rbrunner > Or better said, user-friendly, simple and easy

< 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

< rbrunner > Yup

< plowsof > Definitely , its all fun and games until several people.actualy try it

< rbrunner > And then go on to manage funds to the tunes of tens of thousands of dollars.

< rbrunner > "Only numbers on screen, don't get nervous" :)

< 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

< 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

< j​effro256:monero.social > Doesn't require interaction from proposer and doesn't require interaction from the donator after the inital setup

< o​frnxmr:monero.social > Think of this:

< o​frnxmr:monero.social > many projefts accept donations in crypto, such as graphene.

< o​frnxmr:monero.social > if graphene wanted folks to partially sign tx, theyd likely lose 100% of retail donors

< h​into.janaiyo:matrix.org > would multisig be needed? can't donators just send return address + donated tx id?

< j​effro256:monero.social > This way escrow can't send funds to themselves

< j​effro256:monero.social > They don't have the ability to cryptographically (assuming multisig code is secure)

< r​ucknium:monero.social > I like it. Getting more creative, at least.

< h​into.janaiyo:matrix.org > ahhh i see - either back to donator or to proposer

< plowsof > I donate 100% then i spend the output after ?

< plowsof > 1 week later? Day before milestone completed?

< j​effro256:monero.social > Well you wouldn't necessary make it mandatory, but have it be the option for those so inclines ig

< j​effro256:monero.social > Donator couldn't spend output without approval from CCS since its a 2/2 multisig wallet

< 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).

< plowsof > Sounds similar to BCH's collective funding method which wont(?) Be possible with seraphis (but could be?) Rucknium knows more about that

< 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.

< plowsof > Interesting jeffro256

< o​frnxmr:monero.social > thats a lot of wallets

< 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?

< o​frnxmr:monero.social > and a lot of seeds for (someone) to have the keys for

< 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

< o​frnxmr:monero.social > hintos #2 is what im getting at

< 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.

< r​ucknium:monero.social > lose*

< h​into.janaiyo:matrix.org > this scheme + some deadman switch to auto send funds after a period of time would be interesting

< 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

< j​effro256:monero.social > With a normal wallet, the more redundant you make the keys, the larger your attack surface is to get hacked

< o​frnxmr:monero.social > I see no reason to burden a donor with creating wallets or any speciak anything

< o​frnxmr:monero.social > They need only send funds. The rest is our problem

< j​effro256:monero.social > But now the effects of someone else having knowledge of the keys is minimized

< o​frnxmr:monero.social > Dont need a refund address, dont need to sign anything

< o​frnxmr:monero.social > Just deposit and walk away

< h​into.janaiyo:matrix.org > i think we're re-inventing smart contracts :)

< o​frnxmr:monero.social > Yei

< 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

< o​frnxmr:monero.social > and their opsec is to be trusted?

< j​effro256:monero.social > Whose opsec ?

< o​frnxmr:monero.social > The donators, who partially signed the tx already

< 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

< r​ucknium:monero.social > This would not allow repurposing CCS funds, of course. Just return to sender.

< j​effro256:monero.social > They're already custodying their own funds, so if they screw themselves out of funds, that would happen anyways

< r​ucknium:monero.social > Repurposing if the original worker decided to stop working

< o​frnxmr:monero.social > red taping the donation process is backwards to me

< 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

< o​frnxmr:monero.social > The problem is: were playing with peanuts and accept this as the norm

< r​ucknium:monero.social > We can officially end the meeting here. Feel free to continue. Thanks for trying to fix multisig everyone.

Automated by this