multisig: add key exchange round booster #8203

UkoeHB · 2022-03-03T21:48:50Z

This PR adds a small optimization to multisig account creation that is especially useful for 2-of-3 groups (disclaimer: there is a bounty for it here).

Multisig account creation is a series of rounds. Each round consists of sending messages to all the other group members. A member cannot complete a round until they have received a message for that round from each other member.

A standard 2-of-3 setup ceremony looks like this:
Round 1: Members A, B, C send initial messages to all other members.
Round 2: Members A, B, C use the previous round's messages to make their personal shares of the final key. They send a second message to all other members.
Finalization: Once a member has a full set of round 2 messages, they can finish the account.

That setup ceremony requires 2 communication rounds. For 2-of-3 escrowed markets, the buyer party should instead be able to complete the ceremony in one step so they can fund the multisig wallet right away.

With boosting, we can instead have this setup ceremony:

Members A, B send initial messages to each other and to member C.
Members A, B create 'round 2 booster' messages and send them to member C.
Member C completes round 1 immediately. He creates a round 1 and a round 2 message and sends them to members A, B. Member C then uses the booster messages to complete round 2, finalizing his local multisig account in the same step.
Members A, B complete round 1 then make round 2 messages and send them to each other.
Members A, B complete round 2 and finalize the multisig account.

So, by adding rounds to members A and B, member C can complete a 2-of-3 multisig account in one step.

DISCLAIMER: Kex boosting is expected to be used in conjunction with account force-updating. Extreme care must be taken when designing a system that uses these features to avoid attack vectors that lead to funds getting stuck or possibly stolen (I'd hesitate to use it at all until I or someone else does a write-up on how to do it safely).

TODO

Still need to update simplewallet (and the mms presumably @rbrunner7 ).
This PR is missing functional tests for the expanded wallet2 api (tests/functional_tests/multisig.py). It would be cool if someone who likes Python could help me with this.

Future Work

Try to refactor wallet2 so creating a multisig wallet doesn't involve converting an existing normal wallet's keys. Once a multisig wallet has been created, there should be no way to 'recreate' it using a different M/N configuration. Without that refactor, a user could boost a multisig account using one M/N configuration with a normal account (before converting their normal account to multisig), then later on when they actually convert to a multisig account use a different M/N configuration. If either of those M/N configs was an (N-1)-of-N, then the user will leak their multisig private key shares for that setup when setting up the other configuration (via the key exchange ceremony).

UkoeHB · 2022-03-17T18:20:28Z

This PR should not be merged until after #8220.

gs522084 · 2022-04-17T21:00:51Z

I'm not a programmer, I don't quite understand the logic of this solution, can you explain its benefits in detail? thanks。。。

UkoeHB · 2022-04-17T21:15:57Z

@gs522084 the PR description is written for non-programmers. Not sure what else I can add to it.

UkoeHB · 2022-05-15T01:50:53Z

This PR requires PR #8329.

vtnerd

I don't see one of the functions, so I'm wondering whether there is a missing file or something.

vtnerd · 2022-09-14T16:00:41Z

src/wallet/wallet2.cpp

  epee::misc_utils::auto_scope_leave_caller keys_reencryptor;
  if (m_ask_password == AskPasswordToDecrypt && !m_unattended && !m_watch_only)
  {
    crypto::chacha_key chacha_key;
    crypto::generate_chacha_key(password.data(), password.size(), chacha_key, m_kdf_rounds);
-    m_account.encrypt_viewkey(chacha_key);
-    m_account.decrypt_keys(chacha_key);
+    decrypt_keys(password);


This line didn't have to change, and arguably shouldn't change.

Just trying to remove some code duplication while I'm here

src/wallet/wallet2.cpp

src/multisig/multisig_account_kex_impl.cpp

vtnerd · 2022-09-14T23:55:32Z

src/wallet/wallet2.cpp

+  else
+  {
+    // make_multisig() has not been called
+    // DANGER: If 'num_signers - threshold > 1', but this wallet's future multisig settings


Shouldn't this be a hard error (exception)? Why allow it?

In this case, the user passed in num_signers and threshold manually for a multisig account that doesn't exist yet (e.g. because you are missing one participant's initial kex message - this will happen when boosting round 2 of a 2-of-3 setup where you get the round 1 initial kex message of one participant and then boost round 2 for the other who isn't available). If the manually defined num_signers and threshold are different from the num_signers and threshold that the actual future multisig account gets, then there can be a problem (as described in the code comment).

Yikes. Should the wallet track the values given in the booster request to ensure that they don't change in the future? Downstream projects can enforce this policy, but it seems doing it here if possible is best.

The wallet should not couple multisig and normal wallet code, so that the first step of making a multisig wallet is defining M and N and those values are baked into the multisig core account file (even before initializing key exchange by defining the set of signers). But here we are...

In general, this boosting mechanism is very easy to use incorrectly since it only makes sense to use in combination with force updating the post-kex verification round (which is unsafe if used without nailing down the trust matrix/MPC theory of your use-case), so it should only be used by people who know what they are doing. Maybe we need some kind of gate for this 'enterprise-level' feature...

Updating wallet2 to have safer multisig-wallet-creation semantics is out of scope for this PR. I will mark it as a 'todo potential future PR'.

UkoeHB · 2022-10-19T03:05:46Z

Rebased, should be good to go now

UkoeHB · 2022-10-19T03:36:19Z

Force-pushed again to update the unit test for boosting a multisig wallet so that the boosted wallet uses force-update to finish the post-kex round.

UkoeHB · 2022-10-19T16:57:12Z

src/wallet/wallet2.cpp

+  // expect that self is in the input list (this guarantees that the input list size always equals the number of intended
+  //   signers for the account [when combined with duplicate checking])
+  CHECK_AND_ASSERT_THROW_MES(std::find(signers.begin(), signers.end(), multisig_account.get_base_pubkey()) != signers.end(),
+    "The local account's signer key was not found in initial multisig kex messages when converting a wallet to multisig.");


This is a breaking change. In existing code, adding your own initial message to the make_multisig() command is optional.

vtnerd

The only thing holding me from approving this is whether the error tracking on the uninitialized account can be improved (without too much hassle).

src/wallet/wallet_rpc_server_commands_defs.h

src/wallet/wallet2.cpp

vtnerd · 2022-10-28T16:53:51Z

src/wallet/wallet2.cpp

+  else
+  {
+    // make_multisig() has not been called
+    // DANGER: If 'num_signers - threshold > 1', but this wallet's future multisig settings


Yikes. Should the wallet track the values given in the booster request to ensure that they don't change in the future? Downstream projects can enforce this policy, but it seems doing it here if possible is best.

UkoeHB · 2023-05-16T20:35:55Z

Rebased so I can rebase the seraphis library onto this branch.

selsta · 2024-05-21T14:01:23Z

@UkoeHB needs a rebase

UkoeHB · 2024-05-21T20:28:08Z

Rebased

erciccione mentioned this pull request Mar 4, 2022

Implement efficient generation of multisig wallet addresses [$2500] haveno-dex/haveno#86

Closed

UkoeHB force-pushed the multisig_addr_v2_boost branch from 5f7a13e to 958359d Compare March 4, 2022 19:11

UkoeHB mentioned this pull request Mar 17, 2022

multisig: add post-kex verification round #8220

Merged

rbrunner7 mentioned this pull request Mar 27, 2022

Monero Dev Meeting: v15 network upgrade - Sat 2 April 2022 @ 17:00 UTC monero-project/meta#680

Closed

UkoeHB mentioned this pull request Apr 4, 2022

Monero Multisig for HF #8237

Closed

vtnerd suggested changes Sep 14, 2022

View reviewed changes

UkoeHB force-pushed the multisig_addr_v2_boost branch from 958359d to 6cb5fdd Compare October 19, 2022 03:05

UkoeHB force-pushed the multisig_addr_v2_boost branch from 6cb5fdd to 1a446e8 Compare October 19, 2022 03:35

UkoeHB commented Oct 19, 2022

View reviewed changes

vtnerd suggested changes Oct 28, 2022

View reviewed changes

UkoeHB force-pushed the multisig_addr_v2_boost branch from 1a446e8 to e99b422 Compare May 16, 2023 20:35

vtnerd approved these changes May 6, 2024

View reviewed changes

add key exchange round booster to multisig_account

ddf3af1

UkoeHB force-pushed the multisig_addr_v2_boost branch from e99b422 to ddf3af1 Compare May 21, 2024 20:27

selsta approved these changes May 21, 2024

View reviewed changes

luigi1111 merged commit 15b47b4 into monero-project:master Jul 16, 2024
18 checks passed

UkoeHB deleted the multisig_addr_v2_boost branch August 2, 2024 18:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

multisig: add key exchange round booster #8203

multisig: add key exchange round booster #8203

UkoeHB commented Mar 3, 2022 •

edited

Loading

UkoeHB commented Mar 17, 2022

gs522084 commented Apr 17, 2022

UkoeHB commented Apr 17, 2022

UkoeHB commented May 15, 2022

vtnerd left a comment

vtnerd Sep 14, 2022

UkoeHB Oct 19, 2022

vtnerd Sep 14, 2022

UkoeHB Oct 19, 2022

vtnerd Oct 28, 2022 •

edited

Loading

UkoeHB Oct 28, 2022 •

edited

Loading

UkoeHB Nov 1, 2022

UkoeHB commented Oct 19, 2022

UkoeHB commented Oct 19, 2022

UkoeHB Oct 19, 2022

vtnerd left a comment

vtnerd Oct 28, 2022 •

edited

Loading

UkoeHB commented May 16, 2023

selsta commented May 21, 2024

UkoeHB commented May 21, 2024

multisig: add key exchange round booster #8203

multisig: add key exchange round booster #8203

Conversation

UkoeHB commented Mar 3, 2022 • edited Loading

TODO

Future Work

UkoeHB commented Mar 17, 2022

gs522084 commented Apr 17, 2022

UkoeHB commented Apr 17, 2022

UkoeHB commented May 15, 2022

vtnerd left a comment

Choose a reason for hiding this comment

vtnerd Sep 14, 2022

Choose a reason for hiding this comment

UkoeHB Oct 19, 2022

Choose a reason for hiding this comment

vtnerd Sep 14, 2022

Choose a reason for hiding this comment

UkoeHB Oct 19, 2022

Choose a reason for hiding this comment

vtnerd Oct 28, 2022 • edited Loading

Choose a reason for hiding this comment

UkoeHB Oct 28, 2022 • edited Loading

Choose a reason for hiding this comment

UkoeHB Nov 1, 2022

Choose a reason for hiding this comment

UkoeHB commented Oct 19, 2022

UkoeHB commented Oct 19, 2022

UkoeHB Oct 19, 2022

Choose a reason for hiding this comment

vtnerd left a comment

Choose a reason for hiding this comment

vtnerd Oct 28, 2022 • edited Loading

Choose a reason for hiding this comment

UkoeHB commented May 16, 2023

selsta commented May 21, 2024

UkoeHB commented May 21, 2024

UkoeHB commented Mar 3, 2022 •

edited

Loading

vtnerd Oct 28, 2022 •

edited

Loading

UkoeHB Oct 28, 2022 •

edited

Loading

vtnerd Oct 28, 2022 •

edited

Loading