gistfile1.txt

Embedded proof of verification


Current situation:

 - Mastercoin is balance based
 - Advanced system states exist (ongoing crowdsales, accepted orders, ...)
 - Clients reconstruct the view of system by verifying all transactions 
   starting at Exodus according to a client side set of rules
 - Mastercoin transactions are a subset of all Bitcoin transactions
 - Order of transactions down to transaction position in a block matters
 - Reorganzisations can lead to a completely different outcome, since tx 
   position may change
 - No certainty about the "correct" state, e.g. in contrast to "longest 
   chain of blocks = valid chain"
 - No efficient tool to compare consensus with other participants, let alone with 
   all participants
 - Clients may create transactions which are valid in one view and invalid in others
 - Clients are able to knowingly create valid transactions with limited knowledge 
   about the whole system -- minimal requirement: own balance >= spending amount?
 - Transactions created by clients with zero knowledge may still be valid
 - Due to ongoing or upcoming events (crowdsales, accepted orders, ...) absolute 
   knowledge about balances is not sufficient to reconstruct the state
 - Protocol changes likely result in different view of system for old clients 
 
 
Observations:
 
 - Frequent conensus issues between implementations and commits

 
One needs to distinguish:

 - Do I have enough knowledge to accomplish an action which may be valid?
 - Do I have enough knowledge to accomplish an action which will be valid?
 - Do I have enough knowledge to derive the next state?

 
Why a (reserved) balance based conensus check is not enough:

 - No information about ongoing or upcoming events (e.g. ongoing crowdsales, 
   accepted orders, ...)
 
Associated problems:

 - Many

Question:

 - 
 
Idea:

  - Embed order in a transaction
  
Dumb protocol with order knowledge:

 - Tx with embedded data: "This is transaction number #1"
 - Tx with embedded data: "This is transaction number #2"
 - Tx with embedded data: "This is transaction number #3"
 - ...
 - Tx with embedded data: "This is transaction number #n"
 
Transactions are valid, if number is previous number + 1


Idea:
  
  - Embed information about the system in a transaction

 Simple:
 
 - Tx with embedded data: "My current balance derived from previous transactions is x"
 - Tx with embedded data: "My current balance derived from previous transactions is y"
 - Tx with embedded data: "My current balance derived from previous transactions is z"
 
 Advanced:
 
 - Tx: "The root of a tree which reflects the whole state is H1 and this is transaction number #1"
 - Tx: "The root of a tree which reflects the whole state is H2 and this is transaction number #2"
 - Tx: "The root of a tree which reflects the whole state is H3 and this is transaction number #3"