Get desktop application:
View/edit binary Protocol Buffers messages
* A transaction body for sending the public TSS encryption key.
* The raw bytes of the public TSS encryption key of the node sending the transaction. <p> This value MUST be set.<br/> This value MUST NOT be empty.<br/>
* A transaction body to to send a Threshold Signature Scheme (TSS) Message.<br/> This is a wrapper around several different TSS message types that a node might communicate with other nodes in the network. - A `TssMessageTransactionBody` MUST identify the hash of the roster containing the node generating this TssMessage - A `TssMessageTransactionBody` MUST identify the hash of the roster that the TSS messages is for - A `TssMessageTransactionBody` SHALL contain the specificc TssMessage data that has been generated by the node for the share_index.
* A hash of the roster containing the node generating the TssMessage.<br/> This hash uniquely identifies the source roster, which will include an entry for the node generating this TssMessage. <p> This value MUST be set.<br/> This value MUST NOT be empty.<br/> This value MUST contain a valid hash.
* A hash of the roster that the TssMessage is for. <p> This value MUST be set.<br/> This value MUST NOT be empty.<br/> This value MUST contain a valid hash.
* An index to order shares. <p> A share index SHALL establish a global ordering of shares across all shares in the network.<br/> A share index MUST correspond to the index of the public share in the list returned from the TSS library when the share was created for the source roster.
* A byte array. <p> This field SHALL contain the TssMessage data generated by the node for the specified `share_index`.
* A transaction body to vote on the validity of Threshold Signature Scheme (TSS) Messages for a candidate roster. - A `TssVoteTransactionBody` MUST identify the hash of the roster containing the node generating this TssVote - A `TssVoteTransactionBody` MUST identify the hash of the roster that the TSS messages is for - If the candidate roster has received enough yes votes, the candidate roster SHALL be adopted. - Switching to the candidate roster MUST not happen until enough nodes have voted that they have verified a threshold number of TSS messages from the active roster. - A vote consists of a bit vector of message statuses where each bit corresponds to the order of TssMessages as they have come through consensus. - The threshold for votes to adopt a candidate roster SHALL be at least 1/3 of the consensus weight of the active roster to ensure that at least 1 honest node has validated the TSS key material.
* A hash of the roster containing the node generating this TssVote.
* A hash of the roster that this TssVote is for.
* An identifier (and public key) computed from the TssMessages for the target roster.
* A signature produced by the node. <p> This signature SHALL be produced using the node RSA signing key to sign the ledger_id.<br/> This signature SHALL be used to establish a chain of trust in the ledger id.
* A bit vector of message statuses. <p> #### Example <ul><li>The least significant bit of byte[0] SHALL be the 0th item in the sequence.</li> <li>The most significant bit of byte[0] SHALL be the 7th item in the sequence.</li> <li>The least significant bit of byte[1] SHALL be the 8th item in the sequence.</li> <li>The most significant bit of byte[1] SHALL be the 15th item in the sequence.</li> </ul> A bit SHALL be set if the `TssMessage` for the `TssMessageTransaction` with a sequence number matching that bit index has been received, and is valid.<br/> A bit SHALL NOT be set if the `TssMessage` has not been received or was received but not valid.