Hi again.

It's clear to me that there is significantly more emphasis placed on development of features and progress towards functional goals than there is on the fundamentals of the Mastercoin system (is Master Protocol applicable here?). What I mean by this is the development of, for example, the distributed exchange and smart property has been prioritized over providing 1.) comprehensive and accurate documentation, 2.) a method of proof of transaction validity, and 3.) a structure for responsible Master Protocol implementation. I feel like this is primarily a matter of responsibility of the Mastercoin Foundation rather than any particular issue in specific. The funds held by the Mastercoin Foundation place it in an interesting position of responsibility. By creating financial incentive, the Mastercoin Foundation acts like an authority, in certain ways, regarding development and direction. The ability to create (significant) financial incentive in an open source project can have huge benefits, however also appears to carry the implication that potentially critical items, for which incentive is not provided, may not be developed at a satisfactory pace. Thus, a state of fundamental financial security in Mastercoin is deferred to an indefinite point in time because the project has been driven by development, because the specification could not be used as a specification.

This lack of preparedness is now framed by the Mastercoin infrastructure, and all bitcoin used in Mastercoin transactions. The bitcoin developers have been said to be patching the bitcoin-plane in mid flight, if you'll allow me to paraphrase Andreas Antonopoulos. I don't think the state of Mastercoin is far off from this description - in fact may be far worse considering that there is no provable method of transaction validation. The application has far outpaced the fundamentals. As the Shepard to Mastercoin development, it should be the primary goal of the Mastercoin Foundation to establish a structure from which the various implementations and features can flourish. Instead, it seems as if the development of the current implementations was sponsored at the unintentional expense of the core framework.

I've made offers to contribute significant amounts of time towards core work on a structure that defines Mastercoin in a manner that is "hard enforceable." The offers have gone unrecognized, my requests for links to discussion unanswered, and my concerns largely blown off. I recognize that I'm not talking to any single entity that represents Mastercoin, however it stands that the community has largely not responded to any of my concerns in any meaningful fashion. I maintain that I would like to work on a structure that will enable the Mastercoin specification to be "hard enforceable." This is an open offer to enter that conversation with anybody who's interested, and to coordinate with any developers/the Mastercoin Foundation if they find that it may be beneficial.

I've put together the following list to address some items that I believe are currently misrepresenting the state of the project.

• Purpose of the specification The purpose of the specification is not currently clear. There are sections that clearly identify supported/recognized functions, and sections that specify transaction types and requirements. There are also sections that are much more "fluffy," with the apparent intent of appealing to readers, or otherwise painting a picture outside the direct goal of defining the Mastercoin ecosystem. Though it may be nice to have an accessible "overview" of Mastercoin, the specification should be largely technical, with verbiage kept to a minimum so as to maintain a focus on the protocol instead of the opinions of the authors.
• State of the specification With implementation largely driven by the results of coordinated development, the specification does not currently serve the purpose of defining either the various implementations, or determining the validity of a Mastercoin transaction. Despite this, the specification is maintained to a certain degree, however the arbiter appears to be consensus. It should be clearly noted what the intent of the specification is, and what purpose the specification currently serves (i.e. documentation trailing development; not to be confused with the previous bullet).
• The term "specification" The word "specification" does not accurately describe the function of the specification. The document should be titled to fill the purpose it is defined as.
• Definition of consensus Until the specification can fill the role of a specification, the factors that determine the validity of a Mastercoin transaction should be identified and detailed. As far as I understand, this is currently consensus between various implementations. Given the decision to discontinue support for the MyMastercoins Wallet, there may soon be one less entity to participate in this consensus. It may prove valuable to define consensus (including any circumstances in which the Mastercoin Foundation does not recognize that which has achieved consensus), and detail a plan to act on in the event of loss of consensus.
• Specification vs. whitepaper Any item that is not recognized as "enabled" or will not be considered valid should be explored in a document more similar to a whitepaper. The specification should define the Mastercoin ecosystem, though that not currently being the case, should act as reference for that which is recognized as valid.
• Risk given flux in specification Holding or transacting in or with Mastercoin can pose a financial risk, due to the fluid nature of that which is considered "valid." A statement should be made or included in documentation regarding the possibility that a transaction will retroactively change states of validity. This statement should also acknowledge the fact that if validity is determined by consensus, there may be circumstances in which the Mastercoin Foundation (or any other party) may not be able to "fix" actions which represent a financial loss in either that of Bitcoin or Mastercoin.

Thoughts and input are welcome.

EDIT:

Thanks dexX7. I appreciate your discussion and ideas.