<jpk68:matrix.org> What would it take for multisig to be no longer marked as "experimental"?

<jpk68:matrix.org> It'd be nice to be able to add it to the GUI

<jpk68:matrix.org> monero-project/monero-gui #3990#issuecomment-1204406087

wallet2 is not an environment where that can happen IMO. Preferably a third-party has the resources to do it thoroughly and can present a GUI for it.

<jpk68:matrix.org> Why not? There are facilities provided for it which can easily be used in QML over the bridge (libwalletqt)

Because wallet2 is a spaghetti mess and multisig is potentially adversarial tx construction.

Also multisig uses bespoke protocols with no papers and insufficient auditing.

<jpk68:matrix.org> Would it still be acceptable to add it to the GUI if it's only available in "Advanced" mode, and features warnings of it being experimental?

<jpk68:matrix.org> It would be a shame if not :(

That's up to selsta but I'd encourage no since it's currently in maintenance mode.

And adding to the GUI would increase the maintenance surface for a very low-use feature.

<jpk68:matrix.org> I think usage of it (as well as its sort of value prospect, due to ease-of-use) could be increased using GUI support, both for 'traditional' and QR code-enabled workflows

<jpk68:matrix.org> I wouldn't know much about the safety of the implementation though, so thanks for your advice :)

<jpk68:matrix.org> Maybe there can be a flashing red light that says "WARNING" in big letters

<dgently:catgirl.cloud> How many devs have been lost on the shoals of multisig

<jpk68:matrix.org> I have been working on a PoC, and it mostly works already

<jpk68:matrix.org> I did a local 2/2 transaction on stagenet and it seemed to work fine

jpk68: github.com/freigeist-m/monero-multisig-gui/tree/master

<jpk68:matrix.org> Yes, I am using that as a sort of reference

I'm against merging any multisig into GUI before it's marked not experimental.

<jpk68:matrix.org> Good to know. I guess I'm just curious where the distinction is drawn

<jpk68:matrix.org> For example, still having it in the CLI, but not in the GUI, even if it has to be explicitly enabled or something

<rbrunner7> Well, the "addressed public" is different, IMHO, CLI -> more experienced users, GUI -> users that are often less so. I would trust the average CLI user more to be able to judge whether they want to use that, than I would trust the average GUI user.

<rbrunner7> Or, in other words, even with warnings, having multsig in the GUI is in danger of sending the wrong signal

<jbabb:cypherstack.com> ^ it will signal that it’s ready to use and will be supported

<rbrunner7> And whether "experimental" or not, our current multisig technology with its exponentially larger data exchanges with growing numbers of M and N somehow does not really cut it

<jpk68:matrix.org> Kind of sucks, but yeah, I feel like you're right

<rbrunner7> It does certainly such :)

<rbrunner7> *suck

<jpk68:matrix.org> Maybe the PR can still be published as a draft, and those who would find it useful can compile from source.

<jpk68:matrix.org> The work is already done, haha. It took way less time than I had expected

<jpk68:matrix.org> Some here may find it interesting :)

<rbrunner7> Why not, would be interesting how you approached the whole thing.

Can someone explain why this is needed and if it needs to be done for every additional block as well? github.com/seraphis-migration/moner…ts/core_tests/fcmp_pp.cpp#L446-L458

I'm trying to add tests for the relative lock.

<jpk68:matrix.org> @rbrunner7:monero.social Done.

<jpk68:matrix.org> monero-project/monero-gui #4696

<jpk68:matrix.org> Tested by receiving and then sending a transaction to CypherFaucet on stagenet, using a 2/2 setup.