Requirements / Definitions
Enumerated, small, testable descriptions of data structures and functionality, guided by the Core Principles, and mixed with implementation decisions that, while not specifically required to fulfill the core principles, do serve to fulfill the requirements and provide a defined solution.
- R1: A signature is a data collection which includes:
- R1a: A key identifying the type of signature.
- R1b: The cryptographic signature*Signature to be computed according the the algorithm identified in the R1a key.of the entire data item or collection being signed plus time of signature as follows:
- R1b1: Key of the data item/collection being signed
- R1b2: Data items in a collection being signed appear in the same order as the collection which the signature references with R1d.
- R1b3: All separable items are replaced by R3 hashes of the potentially separated items prior to computation of the signature.*In the event that an item is separated, it must be replaced with this same hash which was used to compute the signature. Hashing algorithm to be used is specified by the R1a key.
- R1b4: The R1c AO_TIME_OF_SIG time the signature was generated, appended.
- R1c: The R1b4 AO_TIME_OF_SIG time the signature was generated.
- R1d: A reference to what is being signed, for example: a participant index in an assignment agreement.
- R2: An R1 signature may be computed using any cryptographic signature algorithm*As specified by the signature's key type definition, for instance the AO_ECDSA_SIG key indicates an ECDSA signature using brainpool256 curve and Sha2-256 hash replacements for separable items.recognized by the protocol implementation.
- R2a: Ⓐ1 protocol recognizes ECDSA brainpool-256 and RSA3072 signature types.
- R2b: Ⓐ1 protocol expects all signature types to use Sha2-256 hash for separable items.*Future protocols may identify different signature keys which still use the same ECDSA and RSA signature computations but use a different hash for separable items.
- R3: A hash may be computed using any*As constrained by the item key type's definition, for instance the AO_ECDSA_SIG key indicates an ECDSA signature using brainpool256 curve and Sha2-256 hash replacements for separable items.cryptographic algorithm recognized by the protocol implementation.
- R3a: A hash of a data item*or data collectionconsists of:
- R3a1: A key identifying the hashing algorithm used.
- R3a2: The computed hash value of the entire data item, including its key.
- R3a: Ⓐ1 protocol recognizes Sha2-256 and Sha3-512 hash types.
- R4: Assignment agreements are structured into AO_AUTHORIZATION collections as described in the linked document, including:
- R4a: Valid AO_AUTH_SIG signature data collections as described in R1 for every participant in the R4b1 AO_ASSIGNMENT, signing the AO_ASGN_HASH from R4b2 plus the time of signing.
- R4b: An AO_ASSIGN_COMPLETE data collection, including:
- R4b1: an AO_ASSIGNMENT containing:
- R4b1a: All Giver participants, which include:
- R4b1a1: AO_ID_SEQ_NUM of the giver*A reference to the public ID of the giver, as well as the AO_AMT of shares that ID controls, and the current UTXO database should indicate if those shares are still available for assignment onward.
- R5b1a2: AO_INDEX unique identifier of the participant within this transaction*for later matching with their signature in the authorization.
- R4b1b: All Receiver participants, which include:
- R4b1b1: A unique*unique meaning not used before in this blockchain, definitely not appearing in the existing list of keys indexed by AO_ID_SEQ_NUMpublic key identifying the receiver
- R4b1b2: AO_AMT number of shares being received in this assignment.
- R4b1b3: AO_INDEX unique identifier of the participant within this transaction*for later matching with their signature in the authorization.
- R4b1c: AO_RECORDING_BID - all receiver AO_AMTs plus the AO_RECORDING_BID must match the amount of shares referred to by the Givers' AO_ID_SEQ_NUM.
- R4b1d: AO_RECORDING_DEADLINE - time by which this assignment must be recorded to be binding.
- R4b1e: AO_LISTSIZE - number of givers and receivers in the assignment (redundant, check info).
- R4b1f: AO_INDEX values in R4b1a2 and R4b1b3 range from 0 to R4b1e AO_LISTSIZE-1, with no gaps. R4b1b receivers of shares all have lower AO_INDEX values than givers of shares.*Starting the AO_INDEX of receivers of shares at 0 makes it easier to translate the AO_INDEX values into AO_ID_SEQ_NUM values when the AO_AUTHORIZATION is recorded on the blockchain.
- R4b2: AO_ASGN_HASH contains an R3 hash of the AO_ASSIGNMENT in R4b1:
- R5: A data item consists of a key, plus data:
- R5a: A data item key is a 63 bit integer, stored as a variable byte code.
- R5a1: The data item key identifies what the data item data represents
- R5a2: The data item key also identifies the size of the following data in one of the following ways:
- R5a2a: Fixed size. Keys which represent fixed size data are always followed by the same number of bytes, defined by the key in R7d.
- R5a2b: Variable size data. Other key types are followed by a variable byte code which specifies the size of the following data.*following data which is all the data contained in the data item, meaning of the data defined by the key.
- R5a2c: Variable byte code. Some key types are followed by a single variable byte code which is the data.
- R5b: data item data, meaning and size as described by the R5a key.
- R6: A data collection is an R5a2b variable size data item which contains zero or more data items.
- R6a: When avoidable, the order of data items in a collection is not important.
- R6b: When being cryptographically R3 hashed or R1 signed, the order of items in a collection must not be changed.
- R7: A single byteCodeDefinitions.json file describes all R5a data item key definitions for an Ⓐ protocol, including:
- R7a: key code value
- R7a1: a bitmask in the key code value identifies whether or not an item is separable
- R7b: acronym - used in programatic #defines
- R7c: plain text description
- R7d: R5a2 size
- R7e: object type plus any other convenient implementation definitions.
- R8: All timestamps must represent valid sequencing
- R8a: A block must not contain signature timestamps after the block's creation time.
- R8b: A block's creation time must not preceed the creation time of any block in the chain it is appending to.
- R8c: An assignment giver's signature timestamp must not preceed the creation time of the block which recorded receipt of the shares being given.
Assign Onward
13 August 2018
MIT License
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.