Enforcing 'n' signatories & signing order for m-of-n P2SH Vs. Multisig

[No_2]

So if we have a 3-of-5 multisig P2SH output, and can provide sigs A, C and D to satisfy it, would the following be written to the redeeming transaction's output:

Code:

<OP_0> <sigA> <sigC> <sigE><redeemScript> <OP_HASH160> <redeemScriptHash> <OP_EQUAL>

I.e. would the set of signing private public keys be written in full on the blockchain for all to see? And the private public keys be stored in full on the blockchain, not as hashes?

[amaclin]

I.e. would the set of signing private keys be written in full on the blockchain for all to see?
And the private keys be stored in full on the blockchain, not as hashes?

public keys. not private keys

[Cryddit]

I just wanted to post here giving props to DeathAndTaxes for his or her patience, detailed knowledge, and willingness to help. 

D&T, you are a huge asset to the community.

I do not normally consider MultiSig or bare Pay-To-Script transactions; to me it always boils down to an "address", either P2SH or P2PKH.  I have sort of been aware that MultiSig transactions can be done otherwise, but they always come to me simply as P2PKH addresses that require multiple keys to spend.

Spending a P2SH txOut from a previous tx requires a script that was decided when that tx was created. This script must match the script hash that is stored with the txOut.  In every case where the tx whose output was being spent is a standard tx, the script will contain public keys needed to verify signatures that are also contained in the script.  Those signatures are made with corresponding private keys that are never disclosed, but the public keys (and the signatures, and the rest of the script) wind up on the block chain (public) because they are needed to verify that spending that txOut was valid.  And that is true for EVERY P2SH txOut that is being spent in a transaction.  A spend script must be provided for each.

Spending a P2PKH txOut from a previous tx requires a public key that matches a hash that was created when that tx was created.  And that key winds up on the block chain because it's needed to verify the spend of that txOut.  And that is true for EVERY P2PKH txOut that is being spent in a transaction.  A pubkey must be provided for each.

And all of this, the scripts and pubkeys required to make a valid spend of the inputs, is an entirely separate consideration from the question of what txOuts your new transaction has.  You can make txOuts from the new transaction be MultiSig, or P2PKH, or P2SH.   Or a few of each. 

Every significant part of a tx must be signed by one or more of the people spending the coins in order for the tx to be valid.  But if there is more than one input to a tx, they can each sign just the ones that they're contributing: that is, if Bob and Alice are both spending one txOut from previous transactions to make the current transaction, it's perfectly fine to have Bob provide the script and/or signature for the txOut he's spending, and Alice provide the script and/or signature for the txOut she's spending.  Usually both or all of them will provide signatures that cover all the outputs of the new tx, but this isn't a requirement.  You might have Alice signing only the input she's providing and one of the new txOuts and Bob signing two other inputs and all of the new txOuts.

I don't think this is clearer than what D&T was saying, but maybe it boils things down a bit or presents it from a different perspective that may help.