<r​ucknium:monero.social> MRL meeting in this room in two hours. We might discuss multisig again.

<a​js_:matrix.org> would also like to plug CfP MoneroKon 2024

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

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

<v​tnerd:monero.social> Hi

<r​ucknium:monero.social> kayabanerve: Will you join the meeting today?

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

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

<v​tnerd:monero.social> Me: still on adding scanning tests to LWS. Found two bugs so far!

<k​ayabanerve:matrix.org> 👋

<r​ucknium:monero.social> me: OSPEAD. Also, MAGIC Monero Fund fundraisers will likely appear in the next version of Feather wallet, using my API :)

<h​into.janaiyo:matrix.org> working on an air-gapped machine guide malvarma.org

<r​ucknium:monero.social> The (self-)nominations for two seats on the MAGIC Monero Fund committee members will open December 5.

<r​ucknium:monero.social> 3. Discussion. Do we want to discuss multisig again?

<r​ucknium:monero.social> The MAGIC Monero Fund has about 29,000 USD total in its general fund that it could deploy to improve multisig, as a bounty, request for proposals, or a grant. kayabanerve has a plan.

<k​ayabanerve:matrix.org> The discussion present in the most recent MAGIC meeting was about the work necessary to make Monero's multisig proper regarding DKG alignment, signing protocol formalization, and P2P networking.

<k​ayabanerve:matrix.org> The alternative reiterated was to drop multisig from the core repo, and in practice, advocate monero-serai.

<k​ayabanerve:matrix.org> My personal suggestion was to replace PyBitmessage with either the Monero network itself OR Tor hidden services.

<k​ayabanerve:matrix.org> With Arti, Tor now has a library interface. Tor hidden services use an existing P2P network, not requiring additional setup, ensure privacy, blend in, etc.

<r​ucknium:monero.social> Is LibP2P not a good idea, after considering?

<k​ayabanerve:matrix.org> With hidden services, we don't have to program a P2P stack. It's effectively coding a web server that receives multisig messages. We could likely even use IRC as the communication protocol for "how shimmed together can this be"

<k​ayabanerve:matrix.org> *not a recommendation in the slightest, obviously.

<k​ayabanerve:matrix.org> LibP2P, another candidate, was my recommendation for a new P2P network. that'd require basic infra and potentially have privacy issues (leakage of IPs of multisig participants, linkage of network bandwidth usage to recently published TXs)

<v​tnerd:monero.social> Why would we go through the effort of creating another p2p infrastructure?

<k​ayabanerve:matrix.org> I believe a solution based on Arti would still have minimal dependencies, be quite clean, and not require modifying monerod (potentially overloading it). It'd also work quite well with monero-serai which is also in Rust.

<h​into.janaiyo:matrix.org> what is the status on `arti`'s onion support? from what I could tell a few weeks ago they were still in the process of stabilizing and testing against C tor

<r​ucknium:monero.social> How good/bad would onion hidden service UX be for a noob user?

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: For multisig message delivery? Someone has to host a centralized relay server and port forward/manage UPnP, or we need some global P2P net, or to hook into an existing P2P net.

<k​ayabanerve:matrix.org> Arti has burgeoning hidden service support and should happen in H1 24.

<k​ayabanerve:matrix.org> Rucknium @rucknium:monero.social: The idea would be complete abstraction.

<v​tnerd:monero.social> But we already have a p2p mechanism in monerod, why use another? And why arti instead of just leveraging standard tor daemon?

<k​ayabanerve:matrix.org> So no user impact.

<h​into.janaiyo:matrix.org> vtnerd: arti has a client library you can embed in applications, the user wouldn't need to run tor manually

<k​ayabanerve:matrix.org> We'd have to modify Monero's P2P net to relay ephemeral messages.

<k​ayabanerve:matrix.org> They'd need to go through Dandelion to not reveal IPs in a multisig.

<k​ayabanerve:matrix.org> Ephemeral message bandwidth usage would reveal how many multisig TXs are actively in progress.

<k​ayabanerve:matrix.org> This allows presuming some recently published TXs are from multisig wallets.

<k​ayabanerve:matrix.org> It's additional burden on Monero itself with much worse privacy properties and nontrivial implementation complexity. Monero would need to become a private messaging network for it to be proper.

<k​ayabanerve:matrix.org> As in, Monero itself would have to be an onion router for arbitrary messages as a piece of public infrastructure with multifaceted use cases.

<v​tnerd:monero.social> Ok, I get the use case for tor, but not for libp2p. And I'm not sold on embedding arti instead of standard tor daemon

How would that Arti solution from the viewpoint of storing multisig messages, so they "wait for you"? It can be very bad UX wise if all signers have to be online at the some moment in time

<k​ayabanerve:matrix.org> I'm not advocating LibP2P. That was an alternative.

<k​ayabanerve:matrix.org> rbrunner: Everyone would have a message server. As long as one has liveness, all messages can be synced.

<k​ayabanerve:matrix.org> This does presume authentication and humans handle consensus.

<v​tnerd:monero.social> If the project/developers arti disappears, we are left maintaining this lib

<k​ayabanerve:matrix.org> I'm not going to be for having usera download the Tor daemon and/or kludge it in vs including a purpose built library.

<k​ayabanerve:matrix.org> Arti is under the Tor umbrella at this point afaik

<v​tnerd:monero.social> What's wrong with having them install it via package manager? Only windows users are out of luck, and they are few now

<k​ayabanerve:matrix.org> Hundreds of k in funding, wide interest and support, praise for cleaning tech debt and distinct intended use cases

Does that library just speak the Tor protocol for you, so to say?

<k​ayabanerve:matrix.org> Yep

One can wonder then why it took so long to develop such a library, no?

<k​ayabanerve:matrix.org> Instead of remote management of a Tor daemon for a hidden service, requiring an additional service, it's Tor as a lib

<k​ayabanerve:matrix.org> Also, the proposal isn't necessarily to do this in monero

<k​ayabanerve:matrix.org> I believe, due to lack of developer support, the inclination is to NOP monero multisig and focus on out-of-repo multisig

<v​tnerd:monero.social> The repo claims it's not feature complete (arti) - does anybody know the status?

<k​ayabanerve:matrix.org> Hidden services are a WIP with kinda support rn. A proper release is expected within the next few months.

Sounds to me like the best way to lose multisig support altogether, frankly

with "out-of-repo multisig"

"isn't necessarily to do this in monero" For example some standalone messaging daemon, with own repo and codebase?

<k​ayabanerve:matrix.org> So we can integrate Monero's experimental multisig into some UX, using whatever people want for the P2P network, and try to find developers to maintain it.

<k​ayabanerve:matrix.org> We can state there's a lack of developers to work on Monero multisig and encourage third-party solutions which do have developers.

<k​ayabanerve:matrix.org> To be clear, last time this was discussed I said I believe multisig is critical and stated my belief Monero should maintain its multisig. I provided the path forward on that.

<k​ayabanerve:matrix.org> Unless we have developers willing to maintain it, I cannot maintain my position.

<k​ayabanerve:matrix.org> koe stated they wanted it out of repo.

<k​ayabanerve:matrix.org> I also don't personally believe they want to further work on it, though we'd need to double check.

Not sure what exactly you mean with "maintain"

<k​ayabanerve:matrix.org> rbrunner: Do all the work necessary to remove its experimental status.

<v​tnerd:monero.social> I understood the multisig implementation well enough (especially compared to bp++), but have no idea how to stop the fake DKG attack or whatever it's called, without changing to a new algo

<k​ayabanerve:matrix.org> Align the DKG with 0009

<k​ayabanerve:matrix.org> Document the signing protocol

<k​ayabanerve:matrix.org> Get everything audited

<k​ayabanerve:matrix.org> The signing impl was audited. AFAIK, the dkg wasn't, and the signing protocol went unreviewed. We need an actual protocol and to confirm alignment.

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: The DKG in MRL-0009 has the same principle as ours and is proven.

<k​ayabanerve:matrix.org> We just need to ensure alignment, that they're the same protocol, and audit.

Well, I always have that chicken-and-egg problem going around in my head. With no multisig that people dare to use, even with caution because experimental, nobody really cares about it

Or, in other words, we wait until it's perfect, we wait forever

<k​ayabanerve:matrix.org> This leads to the fundamental fact:

<k​ayabanerve:matrix.org> - Monero's multisig does not have developers volunteering

<k​ayabanerve:matrix.org> - Third party impls do have developers

<v​tnerd:monero.social> "same principle as ours" - you mean monero-serai or the musig2 implementation in monero

<k​ayabanerve:matrix.org> I mean the ECDH-based DKG premised in MRL-0009 is the same building block as Monero's impl.

<v​tnerd:monero.social> It does feel wrong exporting this outside of monero-project GitHub repo

<k​ayabanerve:matrix.org> We just need to ensure the DKG implemented is MRL-0009 and not some handwaved protocol which also happens to be ECDH-based.

<k​ayabanerve:matrix.org> And then audit it.

<v​tnerd:monero.social> I guess we do that already with stuff in external

<v​tnerd:monero.social> It would be nice if this were it's own repo, like I did with supercop, although that never got used outside monerod and lws really

<k​ayabanerve:matrix.org> My preference is Monero's sovereignty via taking the steps needed on its multisig. Without developers to do that, my forced acknowledgement is to move to something with developers.

<v​tnerd:monero.social> Does monero-serai implement mrl 009?

<k​ayabanerve:matrix.org> If it's out of repo, and no longer in the monero core repo at all, we have greater flexibility, no technical blockers re: upgrades, and greater flexibility.

<k​ayabanerve:matrix.org> No, it's the PedPoP DKG which has O(n**2) complexity, not O(n!)

This is all much too theoretical for me, I have to say. No way we will make it perfect first, then use it. But I think I have to carefully write an issue to argument

<k​ayabanerve:matrix.org> As for signing, it's an extension over FROST hooking into an actual FROST lib. I think Monero's multisig can be argued as a Musig2 extension?

Can't do that here, ad-hoc

<k​ayabanerve:matrix.org> Unless someone steps up to actively work on multisig, my recommendation is we stop endlessly discussing how that's what we want and expecting to eventually drop experimental.

<k​ayabanerve:matrix.org> We Ack it's experimental indefinitely, and we focus our time and effort on solutions which have developers making them non-experimental.

<v​tnerd:monero.social> Ok, so that's something to think about too. I could realistically attempt a mrl009 implementation, but it already has drawbacks, and I'm duplicating what could be leveraged by monero-serai. The downside is that critical crypto code is no longer controlled by monero-project

<k​ayabanerve:matrix.org> Someone either has to step up or we have to drop the discussion. That's my take.

<v​tnerd:monero.social> I'm saying I could step up, but I'm just duplicating work, no? Outside of the one nice to have of it being in monero proper

<k​ayabanerve:matrix.org> (the discussion being dropping the experimental flag from Monero's impl. It's clear what the blocker is and talking ad infinitum doesn't remove it)

<k​ayabanerve:matrix.org> I mean, MRL-0009, IMO, is definitively worse

<k​ayabanerve:matrix.org> It's not just duplication but worse results

You know what, that may be a bit shocking, but that "experimental" does not really worry me. The whole thing, Monero is "experimental" if you apply the same strict measure

<k​ayabanerve:matrix.org> Also, cc Rucknium @rucknium:monero.social: to jump back in after having me step up and then staying silent for the next 30m :p

If enough people "experiment" with Monero multisig because it's fun, support will materialize

<k​ayabanerve:matrix.org> rbrunner: That I vehemently disagree with. I don't know any Monero developer who'd argue there's as likely a risk to lose coins with Bulletproofs as there is multisig.

<k​ayabanerve:matrix.org> I may have to drop out in a few minutes due to battery issues, sorry.

<v​tnerd:monero.social> kayabanerve: that's what I mean, I'm duplicating the functionality of this other lib when it has worse complexity in error case. It's mainly just whether we think it's worth having multisig controlled by monero-project. rbrunner, thoughts on that?

Well, I think a "serious" coin must have multisig out of the box. And as I said, take it out of the core repo, it dies, to say it provocantly.

<r​ucknium:monero.social> kayabanerve: This is cryptography + software engineering. I understand neither well. My opinion/concern is that the main proposal on the table to restart CCS is to escrow it with single-signer wallet managed by the same escrow agent as when the theft occured (luigi). We could have a better setup with multisig.

That's just the last excuse that people need to get rid of it :)

<c​harutocafe:matrix.org> is removing from mainnet but keeping in stagenet/testnet an option even worth discussing?

For doing what with it then on these "play coin" nets?

<v​tnerd:monero.social> Rucknium @Rucknium:libera.chat: that's another issue. This needs to be handled asap, the ccs is already backlogged with ideas that are now stalled

<r​ucknium:monero.social> I don't really agree with rbrunner's reasoning. It is like en.wikipedia.org/wiki/Normalization_of_deviance . "Nothing catastrophic has happened yet, so it's safe enough."

That you don't agree doesn't surprise me :)

<r​ucknium:monero.social> Yes, probably the CCS will be single-signer escrow again soon, but I hope that will not be permanent.

<h​into.janaiyo:matrix.org> this seems like an "evolve or die" situation

I juggle with probabilities. What is, for example, the probability there is a gaping whole after koe rewrote much of the code and thought things through? It exists, but is small, IMHO

*gaping hole

<h​into.janaiyo:matrix.org> wouldn't moving this functionality _outside_ of the core repo be desired? after all the core already is stuffed - makes maintenance and upgrades hard

<v​tnerd:monero.social> The issue kayabanerve: mentions likely won't be too bad given the low number of signers for ccs

For me it's not the sheer size of the repo that makes things hard. It's complex code, that makes it hard. But, IMHO, not too much of it.

<a​js_:matrix.org> Rucknium: if there is w return to the status quo, it is unlikely there will be much motivation to look for better alternatives

<r​ucknium:monero.social> AFAIK, koe wants to keep the "experimental" flag on the current multisig implementation. I guess koe thinks the probability of a gaping hole is high enough to keep the label.

I agree. No problem. I take the experimental multisig. Rino at least seems to think along the same lines.

<r​ucknium:monero.social> RINO's threat model is different

Experimental multisig based web wallet better than no-multisig web wallet. Simple, no?

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: Not in error case. Always.

<k​ayabanerve:matrix.org> I support Monero having multisig. I don't support it enough to do it myself. I'd love if you'd do it, vtnerd. I'd ask you if you find it worth it.

<v​tnerd:monero.social> I don't understand, always what?

<r​ucknium:monero.social> ajs_: A lot of community members are in favor of multisig for CCS. That's the motivation. And to not be complacent, lose XMR again, and damage reputation further.

<k​ayabanerve:matrix.org> I found a vuln in the rewrite PR.

<k​ayabanerve:matrix.org> Any TX leader could burn the multisig.

<k​ayabanerve:matrix.org> Monero always has worse complexity, not just in the error case

I see that we approach things in quite fundamentally different ways. With all points of view having worth of course. I don't possess the truth.

<r​ucknium:monero.social> Threat of burn in multisig could be analyzed as an ultimatum game in game theory I think: en.wikipedia.org/wiki/Ultimatum_game

Well, it's funny to worry about a bad first signer burning if the final signer that reaches the threshold can simply steal. Funny at least to me. A bit.

I guess that theoretically minded people versus, well, maybe call it pragmatist.

<k​ayabanerve:matrix.org> rbrunner: It allows for millions in damages with just tens of thousands of dollars in losses in collaborative funding schemes.

<v​tnerd:monero.social> kayabanerve: the bug you mentioned, this prevents one particular sign attempt, or permanently locks funds?

Yes. Not downplaying things. Attempting to put them into perspective.

Funding schemes dealing with millions can be robbed by the final signer. Just as bad.

At least if they need simple multisig

*if they use

<h​into.janaiyo:matrix.org> on a more practical note - usage of multisig will definitely extend contributor payout delay even more :)

<k​ayabanerve:matrix.org> The bug I found which survived the rewrite PR which enables burning the multisig.

<v​tnerd:monero.social> This bug occurs in the setup phase then?

More like an exploit, seems to me. If nobody is malicious, I don't expect it happens, right?

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: It happened during signing. The TX leader could propose a TX which would.

<k​ayabanerve:matrix.org> @rbrunner That's a bad threat model

<k​ayabanerve:matrix.org> If you assume compromise=0, multisig offers recovery, not security

I was just arguing about calling this a "bug", not something more fundamental

<v​tnerd:monero.social> Which would permanently lock funds? This seems like something wrong with the implementation then

<v​tnerd:monero.social> I could see how that would happen, one user goes into a spent state, even though the TX is dead

Our multisig transactions do not burn themselves just because full moon falls on a Monday, I mean

<v​tnerd:monero.social> No, he is talking about a threat model. In the worse case someone gets hacked, and the hacker proposes a signature which locks funds

Agree with that, yeah. Would be nicer if that wasn't possible of course, no doubt.

<k​ayabanerve:matrix.org> It's by the leader's prior ability to select the R used for the change address, which enabled triggering the burning bug.

But see: You are already hacked before that can happen. If you are hacked, tons of other bad things can happen instead if that burning is not possible.

<k​ayabanerve:matrix.org> It was a comment on the rewrite PR having further findings still identified.

<v​tnerd:monero.social> Yeah but we might as well do no multisig if that's that argument

Yes, that's why it's still experimental, and rightly so

There is some logic in that :)

<t​obtoht:monero.social> I'm integrating multisig in Feather. It's mostly an exercise in designing practical ms UI/UX. I'm taking experimental multisig 'as-is', sticking a big not-for-production-use disclaimer on it, rewriting the MMS so it connects to a centralized self-hosted message relay (optionally over some user configurable SOCKS5-proxy). The thinking is: show users 'what could be possible' -> crea<clipped message>

<t​obtoht:monero.social> te more demand for a better multisig implementation.

Couldn't have it said better, tobtoht.

Just don't program yourself into a burnout, do you ...

That's a lot of work

<h​into.janaiyo:matrix.org> > centralized self-hosted message relay

<h​into.janaiyo:matrix.org> what would this be exactly?

<v​tnerd:monero.social> Why so confident that monero-serai has no such issues? I realize it follows a different standard, but it could have unknown bugs too.

<r​ucknium:monero.social> kayabanerve: ^

<t​obtoht:monero.social> A service that stores encrypted messages and allows participants to retrieve them. Thinking about using FastAPI + Redis for an MVP.

<r​ucknium:monero.social> The meeting is over. Feel free to continue discussing multisig :)

<a​js_:matrix.org> MoneroKon 2024 Call for Presentations/

<a​js_:matrix.org> Workshops open

<a​js_:matrix.org> apply.monerokon.org

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: It doesn't use a novel DKG.

<k​ayabanerve:matrix.org> It's DKG has reviewed security proofs.

<k​ayabanerve:matrix.org> The DKG was audited to conform.

<k​ayabanerve:matrix.org> The signing protocol underlying it has security proofs and review.

<k​ayabanerve:matrix.org> The extension is trivial, and using the API of our audited FROST lib for core functionality.

<k​ayabanerve:matrix.org> It's not a leader protocol. Once an intent is declared, the only decided by any individual is their own data which has proofs for integrity.

<k​ayabanerve:matrix.org> It didn't rewrite all the TX code yet cleanly hooked into the existing TX construction code.

<v​tnerd:monero.social> kayabanerve: what DKG protocol does serai use?

<v​tnerd:monero.social> bad news, from the MRL-009 paper : The thresholdizing heuristic described in Section 3.2 extends naturally to a system with this one-time key extension, but our proofs of security properties do not immediately apply to these extensions without some further work.Establishing the unforgeability of an implementation of LSTAG thring signatures using Cryptonote-styled one-time keys wit<clipped message>

<v​tnerd:monero.social> h a view key extension remains an open task.

<k​ayabanerve:matrix.org> vtnerd @vtnerd:monero.social: PedPoP from the FROST paper.