For the sake of clarification: (...)
Great you ask. This topic
was recently discussed in the dev thread. I'll try to say something to each point:
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?
Masterchain.info doesn't compress the key; the Masterchest wallet does currently compress the public key - with the intention of saving space and creating smaller transactions. Zathras (Masterchest creator) recently mentioned he may drop the compression, because this may confuse the user. What do you think about this?
Compressed or uncompressed - both share the same private key and are both redeemable by the owner. In neither of those cases any coins will be lost, but ...
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?
Bitcoin-Qt/bitcoind is not able to recognize multi signature inputs as spendable and to my best knowledge there is no (graphical) client available that is capable of doing so. This means those inputs are neither added to the balance or even shown at all. I'm not sure about the input selection of masterchain.info which uses libbitcoin as backend, but the Masterchest wallet currently relies on the input selection by bitcoind via RPC and thus does not spend those outputs. Spending those is nevertheless possible, if raw transactions are handcrafted and I'm very, very sure that the wallets will soon be able to do so. - It's not really dark magic, but rather low priority at the moment, I guess. This is also possible via RPC and all it needs is some logic to find those unspent outputs.
If you like, send me a PM with your address(es) or transactions and I'll fire up my custom dust collector that I'm using for the faucet (
example transaction).
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?
As mentioned, compressed or uncompressed doesn't really matter - both should be redeemable. I think the way to go in the future is to have an intelligent input selection that redeems some of that dust whenever there is some space left to the next fee level (currently 0.0001 BTC per 1 KB, up rounded).
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?
All cases are considered as valid by the three implementations and it appears that the spec is currently worded too strict.
Changes were proposed (
also related) to cover those scenarios more accurately, but the final wording is not yet finalized. No historical transaction or balance will be affected due to this. Baseline: transactions should include the input public key - either compressed or uncompressed - for redemption purposes, but are not enforced to.
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?
Correct.
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?
This will be addressed, that's for sure. At the same time I think this is something the user shouldn't care about, but rather a problem for the wallet to solve under the hood. What is your opinion about this? Would you prefer low-level control of inputs or maybe even a dedicated app to collect dust? Input on this is very welcome.
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?
With Bitcoin 0.9 OP_RETURN transactions will be considered as standard transactions, but very recently the allowed payload size
was reduced to 40 byte. If this is final, the size won't be enough for all Mastercoin transaction types and I tend to favor the data encoding within multi signature outputs. - They are widely accepted, redeemable, don't consume much more size and also very important in my opinion: very, very long payloads are possible.
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.
In general the spec is defined first and implementation comes next, but I noticed over the last weeks that this is more an iterative process. In some very rare cases like this one the implementations are ahead of the spec, because, as you mentioned, if there is no one who actually notices this and raises his voice, such "conflicts" appear which require additional adjustments.
(TL;TR:) There is no bloat and transactions are created in a way that dust outputs are spendable, but due to the general inability of Bitcoin clients to deal properly with multi signature outputs, the current Mastercoin wallets don't redeem them yet. This will change and thanks to posts like yours this may happen rather sooner than later.
---
Magic bytes in the payload is just simply a much better way of identifying transactions. It's cheaper, it's truly decentralised, and it doesn't send J.R. any of your money for bogus hand-wavy reasons like "DOS protection", which Bitcoin obviously handles itself through standard BTC TX fees.
What if someone steals the private key to the Exodus address from J.R.? What if he loses it? Why take the chance?
It doesn't matter, if someone has access to the Exodus address in the context of identifying transactions nor does the identification mechanism has any implications related to (de-) centralization.
Agreed, in terms of transaction costs the approach of magic bytes makes XCP transactions cheaper for the user. If it's much better? Well, I think that's rather a matter of personal opinion than something that can be generalized. All you can represent is your opinion and it seems I have a different one. This is probably the reason why you stick to XCP and I primarily prefer MSC. The trade off was already outlined: cheaper transactions vs. resilience and contributing to further improvements. And I'll bite: what happens, if a XCP bounty fund raiser loses the private key to the bounty wallet?
I'm not 100 % sure what you are addressing right now - that there is an output to the Exodus address or that JR holds the keys to the coins that were raised to fund Mastercoin?
