How does the sender know the receiver's public keys in a m-of-n transaction?

Question

Assume that Alice is controlling an address that requires multisig to spend bitcoins. Someone wants to send Alice bitcoins and this sender needs to create a scriptPubKey as part of the output paying Alice.

The scriptPubKey in the sender's transaction should look like this:

m pubKey_1, pubkey_2, ...pubKey_m n OP_CHECKMULTISIGVERIFY

How does the sender know the public keys to send funds to Alice? And further more, how does the sender know the value of m? Isn't it more logical that Alice determines what the minimal number of signatures is?

If I understood correctly this output format is not used anymore, but I still want to understand how it worked.

Answer 1

Any address that a spender will send to is provided by the receiver. As the owner of the address, the receiver knows these details and will be able to provide the correct sending instructions to the spender. This holds true even for the outdated original multisig construction that required the spender to know the pubkeys, but today most multisig transactions actually make use of pay-to-script-hash (p2sh), so the receiver would simply provide a standard p2sh address to the spender.

Answer 2

In modern times, this problem is solved using P2SH (and later P2WSH). It means the sender only needs to know a hash of the actual script the receiver wants to use, which has its own address format so it's easy to convey.

If your question is how was this done before P2SH: the answer is simply that multisig was not used in practice. Note that P2SH was introduced in 2012; Bitcoin was relatively young at the time and not as much was built on top. There were probably a few experiments that used multisig, but I doubt anything practical.