Quote

1. Snapshots

After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!)

Can you point me to discussions had on this subject? I'm interested to know if any discussed ideas allow a snapshot to be referenced without developer involvement.

Ideally a system could be implemented that only requires a single snapshot at the implementation of a specification revision control system, to validate transactions occurring before that point in time. Of course, more may be necessary if a disaster situation ever occurs in which consensus is violated, or a revision has unintended consequences etc. Regardless, I'd imagine that snapshots are far less manageable than a set of rules that could define validity of transactions in prior revisions, and I fear that snapshots may pose scalability issues.

Quote

2. Checkpoints

Snapshots should be explicitly used to verify an application.

I feel like this may be challenging in terms of upkeep, and scalability.

Quote

3. Reference documentation

The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...".

I was thinking about something similar as I was submitting my pull request. Maybe it's not necessary to revise the entire specification if only one or two small changes are made. If different sections are broken out one can submit pull requests for items that don't warrant an entire specification revision, and changes can be discussed in a context more relevant to the issue at hand.

If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.

Maybe a crazy idea, but why not use Master Protocol itself to store the specification? For the sake of opening up a discussion on the subject, consider if a transaction definition could be stored in the blockchain. Not only is it universally publicly accessible and immutable, but a standardized dictionary could theoretically allow a client to programatically and dynamically verify the validity of a transaction based on the relevant definition at the time. I have experience designing and implementing relational databases and would be thrilled to contribute if others think that this may be worth pursuing. I'm not under the impression that it's an easy task, but then again, neither was a distributed exchange.

Quote

4. Define how changes are pushed

Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates.

I agree. The specification feels too easy to manipulate right now, IMO. The revision procedure should detail the steps taken to ensure that the implications of a change are known, and that there are no unforeseen consequences that could compromise funds or security. This would be a great place to discuss results of test cases which you discuss below.

Quote

5. Test cases

With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc.

I think there's a lot of value in a program/script that could scan the blockchain and output a list of x based on parameters y, and z. For example, transactions with outputs to the Exodus address, or more complex, transactions with outputs to Exodus address with a multisignature output that is not definitively spendable by the sending address or 2nd key pair created from associated (hex) private key. A tool of this nature would allow one to determine how "ready" various implementations are to transition to a new transaction definition, for example.

If a functional and usable language could be used to write a query, a tool of this nature could be revolutionary for bitcoin protocol layers, let alone for blockchain data analysis.

Quote

6. Transaction archival

Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.:

Code:

[{
"basetx": "98419d8b3056ce50aa63d1f464555e038ae517996ac6ec13bfd8c26689f5bece",
"input": "1NqkqJkGCA7HJkBQqJrRvJCDCLAnQndw7",
"reference": "1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH",
"datahex": "0000000000000001000000012a05f200"
}, {
"basetx": "cc70f686b1402d092da400f817133b07d774b3d9791564dc6efee8dbd0a54a1d",
"input": "1Foh78nqSDzrAncvTCCqtFSzz143CsGdcz",
"datahex": "00010014000000010000000023c346000000000005e69ec0020000000000003a9801"
}]

IMO, this is unnecessary. I don't see any reason why a properly formed transaction definition shouldn't be able to determine validity of all applicable transactions. Archival could imply more limitations than the benefit gained by ease of gathering examples. Maybe your concern here could be appeased with the ability to prove a transaction types definition at block x?