the sending-from-multisig problem

[markblundeberg]

When a multisig input is used to generate a stealthy transaction, there are serious issues due to the ability for co-signers to re-sign, replace other signers, etc.

Issue: the 'main key' can be re-chosen, causing derivation to completely fail.

Let's say you have a 2-of-3 multisig with pubkeys A, B, C, and the plan is that B and C shall sign. This means that B is the first signer, and B key is used to generate addresses.

Once B or C has signed the transaction, however, then A can come along with a signature and the final transaction will be signed by A, C, or A, B. Now B's pubkey is not the first, and may be not involved at all.

If the recipient directly scans this tx (regardless of prefix matching), they won't detect the payment since they'll be deriving based on A key instead of B.

Solutions?

• No more 'main key'. Recipients must check derivations from all pubkeys, regardless of who was involved in the signing.
  • this is extra CPU work for recipients, but not too much more (the current thing of finding the first signing key requires extra signature verification work, which would not have to be done any longer)

Issue: prefix grinding depends on the last signer

The hash of an input is dependent on all the signatures. So the very last signer is the one who determines the prefix, and must perform proper grinding. And even once the multisig coordination process is finished, someone could maliciously re-sign the transaction to change its prefix.

Solutions?

• Instead of per-input prefix, do a per-signature prefix (from R value). One nominated signer then produces the right-prefixed R value. Still not good enough though:
  • A prefix can get lost if that signer is replaced entirely (if the signing set changes and excludes them).
  • The nominated signer can maliciously re-sign with incorrect prefix.
• Multisig senders are not allowed to have prefixes at all. They are only allowed to send to payment codes with 0 prefix length (e.g., offchain notifications).

Issue: the 'main key' guy derives the shared secret; how can cosigners trust him?

The diffe-hellman shared secret process is designed that you can only compute the result if you know at least one of the private keys involved. If Alice owns the 'main key', how can she convince her cosigner Bob that the derived addresses are correct for the intended reusable address recipient, without revealing her private key? She might give them a fake value for the shared secret hash, in which case they would be sending money to wrong addresses (not findable by the intended recipient) and money could be lost.

Solution!

• There are cryptographic "proofs of discrete logarithm" that are totally doable. Alice can provide the point and a proof that it is the correct diffie-hellman point for her key, without revealing her private key.
  • There is a mild danger in that Bob can try to trick Alice into paying a small sum to a fake payment code, just so he can get her to compute (and share with him) the multiplication of her private key with an arbitrary point of his choosing. Bob can choose this point to be the nonce point of an encrypted message that was sent to Alice earlier on. By doing so, Bob can decrypt messages that were sent to her key (or any related key, e.g. key on a nearby unhardened bip32 path).
• There may be more fancy ZK protocols where Alice can instead provide the final result (bip32 seed value) and then ZK-prove that it is correct; this is useless for someone trying to trick you into decrypting something.

[markblundeberg]

A proposal to make send-from-multisig transactions actually 'secure', in that funds won't be lost due to accidental or malicious malleation by cosigners. Two pieces:

1. Multisig wallets "should" or "must" only send to 0-prefix-length payment codes (or unprefixed when using off-chain notification). This solves the grinding issue.
   • If this is a "must" then consequently, receivers who have indicated a nonzero prefix length and are processing direct on-chain transactions may skip multisig inputs.
2. Receivers must check derivations for all pubkeys in the multisig, regardless of who signed.
   • Although it's a slightly more CPU work, it is simpler since it means the receiver doesn't need to properly implement all the intricacies and edge cases of multisig script verification, to identify the main key. This way there is no main key.