anchor.diff:  
   === Block Consensus Hash
   
  -This is a hash of all consensus data for all currencies in existance at a specific block height.
  +This is a hash of all consensus data for all currencies in existence at a specific block height.
   
   === Currency Delta Consensus Hash
   
  -A hash of only the changes to balances of a specific CurrencyID that occured during the specific block.  This has may not be very useful and/or may be difficult to compute. 
  +A hash of only the changes to balances of a specific CurrencyID that occurred during the specific block.  This has may not be very useful and/or may be difficult to compute.
   
   === Block Delta Consensus Hash
   
  -A hash of the changes to balances of a all currencies that occured during the specific block.  This has may not be very useful and/or may be difficult to compute. 
  +A hash of the changes to balances of all currencies that occurred during the specific block.  This has may not be very useful and/or may be difficult to compute.
   
   == Notes on Hash Algorithms
   
  
positive.code: 
  == Background
  
  The Omni project has historically used "Consensus Checking" as a method of validating the correctness of Omni Protocol implementations. Checking consensus for a Omni Protocol currency (such as MSC, TMSC, or any user currency) means asking two or more implementations of the Omni Protocol to generate a list of every address that contains a balance in that currency and the balance amount. To check for valid consensus the total balance and the reserved balance at each address containing that currency are compared.
  
  One problem with this method of validation is that it is becoming less useful as we focus our efforts on the Omni Core reference implementation. When a new feature that could affect address balances is added to the reference implementation it is not possible to consensus check against a second implementation until the new feature is added to the second implementation.
  
  A secpmd problem with consensus checking is that a valid comparison requires that both implementations return consensus data for the same block height. If an implementation can only return a consensus snapshot for the current block height and one implementation is lagging behind another in parsing transaction data, then an accurate comparison is not possible unless consensus data from the more up-to-date implementaiton is saved until the second implementation catches up.
  
  Although it would be possible to save consensus data for each new block as it is processed by an implentation, the amount of storage required quickly becomes prohibited.
  
  It is for these reasons that we propose using a hashing function to create hashes representing consensus data. These hashes can be stored for long periods of time, perhaps indefinitely and can be used for comparison purposes.
  
  
negative.code: . It is a well-known algorithm
  . All Bitcoin and Omni Protocol implementations have an implementation available
  
  Because Consensus Hashing is neither used nor required by the specification for determining balances or for validating transactions, it is not strictly necessary to use a cryptographically secure algorithm, nor are there any direct security implications of this proposal.
  
  
  