Quote from: dacoinminster on March 20, 2014, 12:09:03 AM

I think the spec is accurate right now, but if you've found something that is out of date, we welcome pull requests

Thanks for weighing in.

I propose that if the specification is accurate then only transactions which are not invalidated (or otherwise specifically validated) by the specification are valid.

I'm going to use the same example as my previous post to demonstrate the effect of this. The specification states, "A single transaction must be constructed satisfying the following requirements:"

Quote

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

Excuse me for quoting myself, but this is what follows:

Quote

Only a compressed key pair can broadcast valid Class B transactions.
There is a mastercoin client that is actively broadcasting invalid Class B transactions.
Since no mastercoin implementation recognizes a Class B transaction with a P2SH output to an uncompressed public key as invalid, there is a growing chain of invalid transactions that is publicly and unanimously identified as valid.

If the specification is accurate it also follows that, because there is no implementation that recognizes Class B transactions with P2SH outputs to uncompressed public keys as invalid, no implementation can be trusted to display the correct mastercoin balance of an address.

Further, a significant sum of bitcoin has been unknowingly traded with parties which may not even know how much mastercoin they have. Given the possibility that this party has a mastercoin balance to cover the trade, there's no guarantee that it was actually sent to the buyer.

It's really tragic for mastercoin if the spec is accurate, because the loss of bitcoin in invalid mastercoin transactions cannot be recovered, and every single wallet/implementation is useless as a method of sending, receiving, trading, or otherwise interacting with the mastercoin network.

I would suggest against maintaining that the specification is accurate.

EDIT: Concerning the invitation to submit a pull request, it's not a matter of the spec simply being outdated. If it's reasonable to consider that the specification can be out of date, the public release of an updated specification can change the validity of mastercoin transactions confirmed in the blockchain prior to the time at which the revision is published. Bitcoin sets a very high standard on the ability to verify the validity of a transaction, and there's no reason that any entity should be able to retroactively change mastercoin balances.

I recognize the invitation as a suggestion to get involved and address items I may have issues with in a structured and accepted manner, however this isn't about redefining a valid Class B transaction. It's about the ability to know an addresses mastercoin balance, to trust that an addresses mastercoin are secure, to feel safe moving or trading mastercoin, and finally to minimize the impact of data storage on the blockchain.

But for the sake of argument, if I did submit a pull request and it was merged, this would just exacerbate the issue I have with my ability to trust the specification as a document that defines mastercoin, and my ability to trust mastercoin as valuable. If the specification does not or cannot define mastercoin (and consequently the security of mastercoin that one owns), I believe it follows that mastercoin is not valuable.

EDIT 2: I expanded my first edit, and clarified a poorly worded sentence.