Quote from: dexX7 on March 17, 2014, 12:23:11 PM

Actually the multi sig output does include your public key, but in a compressed form, if I'm not mistaken?

See for example:

204e02988b1a7262d90168dfe4574a69b3ab6617dddfc3737e6a296ec4d17b8f:

Input:

Quote

30450221009040ffa1b6ad045d2e6392b53c13e2f10a1b3780a9d25605e20380631c8818b402203 8a03dea5ed01e5a27c27cacbcb2908861a8078293d10d7ed8d2704e95efda8801 04cb53028bef9d48860842d17e86174fd65c913494d148c335bb17a6551a4bcb14d56eccb4cd4ac184b60cd71d1cf83b70ddf5e23198325c6036e06033c5d1d594

Output:

Quote

OP_1 02cb53028bef9d48860842d17e86174fd65c913494d148c335bb17a6551a4bcb14 0225af43e566399b7429bb01463fb69666bb3b24609b6d736bb64327143d655805 OP_2 OP_CHECKMULTISIG

For the sake of clarification:

If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?
Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?
The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?
The mastercoin spec states that a Class B transaction must satisfy the following: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
Is a Class B transaction valid if the multisig output is to an uncompressed public key?
Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?
Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?
With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?
When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.