SIP: 20 Layer: Core Title: The Validation Matrix Author: Brian BurrellComments-Summary: No comments yet. Comments-URI: https://github.com/neonatura/shioncoin/doc/standards/Comments:sip20.wiki Status: Final Type: Standards Track Created: 2018-10-13 License: PD
The numeric information in the "validation matrix" is composed of a running hash split into 9 cells which is directly based on the preceeding block-chain. The validation matrix acts as a redundant security measure in order to ensure that the block-chain is viewed in a consistent manner between all nodes. Note that the validation matrix does not provide in itself anything more than an additional checksum mechanism to the existing block-chain.
In addition to providing a supplemental level of integrity to the block-chain in the form of a "redundant merkle hash", the validation matrix is also used to initiate a sequence of events that potentially lead to a new dynamic checkpoint being established. This is performed by a consensus vote led by active partipants (referred to as notaries) on the block-chain.
Each node which generates a "validation matrix" becomes a candidate to become a "notary". When enough notaries are available the validation matrix which use a multi-sig output which contains the pubkeys from all participating notary nodes.
A "notary transaction" has a single input; the latest validation matrix transaction. It is signed by each node (in order) until the transaction is finalized and complete. Once, and if, completed, a dynamic checkpoint will be made for the block which contained the "validation matrix" transaction. Note that only the last validation matrix block on the block-chain will be considered as a potential checkpoint.
The output of the notary transaction is a "null return" which will result in the original coin being transformed back into a claimable miner transaction fee (less a small amount for additional ensued transaction fees).
The output of a validation matrix coinbase transaction can either be OP_RETURN or a multi-sig redeem script which includes a minimum consensus of notary pubkey addresses.
Here is an example of a notary transaction:
{ "txid":"f51d4c04a6ab1483a6562960140d1eee83a0f8d7ff91b4e68375c952c1a5bcb0", "vin":[{"txid":"2788f12789b27c9167b56a34c696dc117bb5939d00b70a3474aae451cbed3962","vout":0,"scriptSig":"0 3045022100bba304fb584f1ace2f101fd7ada1d36475da8f3ad9178e99029a020614e3208202204e9ae644ea6a6d5d184097f4ce4ba6a17cf92201936aa37d15637f8ee32d0fd601","sequence":4294967295}], "vout":[{"value":0.00000000,"n":0,"scriptpubkey":"OP_RETURN","reqSigs":1,"type":"return"}] }
An incomplete "notary tx" is submitted and each node with a public signature included in the transaction's multi-sig redeem script will sign the transaction, and then submit it again. This is done in the order of the pubkeys listed in the multi-sig redeem script.
At no point will a incomplete "notary tx" be added to the transaction memory pool and the "input sequence" to a non-final value until all signatures have been squired. Nodes which do not have a public key address listed in the multi-sig redeem script will still relay the transaction even if it's incomplete. In order to avoid redundancy, a node will only sign the "notary tx" if it's own public is the next in line that has not been signed pertaining to the multi-sig pubkey order.
At this point, a new checkpoint will be established for the block containing the validate matrix transaction providing the following three criteria are met: