Computer implemented systems and methods

Abstract

Using, processing and / or generating at least one blockchain transaction suitable for updating a blockchain token (e.g. transferring a blockchain token between entities). A transaction includes a latch

Description

Field This disclosure relates generally to methods and systems for improving the electronic exchange of blockchain tokens and their associated assets from a first entity to another entity. The improvements relate to the determination of the validity of the blockchain tokens in an efficient manner that enhances security and inhibits double-spending and inhibits counterfeiting. Examples utilise, at least in part, a distributed ledger (blockchain) to facilitate the secure and efficient transfer or control of a blockchain token e.g. this disclosure is particularly suited, but not limited, to use in respect of the exchange or transfer of tokenised assets across a computing network. Background The Bitcoin blockchain ledger as introduced in 2008 by Satoshi Nakamoto’s whitepaper (https: / / bitcoin.org / bitcoin.pdf) is the most widely known blockchain and associated network / platform in use today. Therefore, Bitcoin is referred to m the examples used herein. However, examples of the disclosure are not limited in this regard and alternative blockchain protocols and implementations fall within the scope of the present disclosure. A blockchain transaction is a data structure formed in accordance with a blockchain protocol and comprises at least one input and at least one output. Examples of blockchain transactions having functional and transparent outputs are known from WO2021 / 250037, which is incorporated by reference herein in its entirety. Figure 1 discloses such an example in which a logical subledger of associated tokens issued by the same issuer is implemented on a blockchain ledger e.g. the Bitcoin blockchain. The logical sub-ledger can be referred to as a Token Ledger, and indicates relationships between an establishment transaction, minting transaction and subsequent token exchange transactions. Known blockchain token operations e.g. token protocols on the Bitcoin blockchain suffer from drawbacks since they must piggyback the protocol and must account for temporary delays to an acknowledgment in two-way communications so that it can be hooked with next outgoing data frame, which is not guaranteed by the underlying consensus protocol of the blockchain. Establishing provenance and enforcing valid exchange and / or evolution of blockchain tokens can require operations outside of the Bitcoin network. In a paper - Computationally sound Bitcoin tokens, Bartoletti et al, 2021 (https: / / arxiv.org / abs / 2010.01347) - it was stated that “the blockchain is used just to notarize the actions that manipulate tokens, but not to check that these actions are actually permitted.” This lead to a number of alternative Distributed Ledger Technology (DLT) protocols, such as Ethereum. However, the Bitcoin protocol is Turing complete and is capable of running sub-protocols. Unfortunately, blockchain token operations e.g. protocols operating atop Bitcoin suffer from the same operational drawbacks as their predecessors e.g. off-chain / extra-protocol mechanisms. Validating a blockchain’s entire transactional history back to its issuance e.g. validating “back to genesis” also remains an expensive overhead. Since the trust necessary for such implementations depend on external actions e.g. requesting issuer signatures every transaction or validation from some other database outside of the blockchain and / or bitcoin network itself these protocols are often deemed layer 2 or 3 of the OSI model, and thus inefficient and costly. Summary Aspects and examples of the present disclosure provide techniques, protocols and systems for creating, using, processing, and updating e.g. transferring tokenised assets or resources via a blockchain (ledger), wherein determining provenance and determining the validity of a blockchain token is subject to a conditional exchange that uses a latch mechanism upon a blockchain token. In other words, the latch mechanism can operate in conjunction with, or in tandem with, a blockchain token for providing provenance thereto. The latch mechanism underpins methods of operations and / or protocols that can operate without external off-chain protocol mechanisms or DLTs and instead can rely upon the blockchain consensus protocol e.g. only reply upon the blockchain consensus protocol. The latch mechanism and methods herein, are deemed to be layer-1 protocols. The methods herein are presented, by way of non-limiting example, to the transfer of a token from one entity to another entity. The invention, however, is not so limited and can be applied to (i) an update to a token, and / or (ii) an entity retaining control of the token without a transfer taking place. Therefore, additionally or alternatively to transferring a token, the latch mechanism can be used to manage an update to a token, which can include an update that can at least one of manage assets or resources that can be tracked and / or managed using one or more blockchain transactions in which token-related outputs, representing tokens, and function to determine the status of an asset. The status can, for example, indicate at least one of ownership, access rights to a secured asset, data, instruction, state, operation, configuration and value of an asset or resource, such as an amount of token-units. In particular, the methods herein additionally or alternatively can operate the token like a state machine. While the teaching herein can enable an update e.g. atransfer and an update, the terms ‘update’ and ‘transfer’ can be used interchangeably. The latch mechanism comprises two components: a latching component that applies a ‘latch’ that functions to place a restriction upon a blockchain token, which can be released if conditions are met in a subsequent blockchain transaction e.g. if Alice wishes to transfer a token to Bob she can apply the latch mechanism in the process of transferring the token to Bob that obliges that a condition is met before he can transfer the token; and an unlatch component that is processed to release and / or unlatch the previously applied ‘latch’ and release the restriction. This mechanism can be applied and / or enforced in a chain of latching and / or unlatching token transactions e.g. to subsequently transfer the token to Charlie, Bob must release the latch mechanism by meeting the conditions imposed before being able to make a valid transfer to Charlie. This disclosure relates to at least one of using, processing and / or generating a blockchain transaction, or a group of transactions, for transferring a blockchain token from a first entity to another entity. The transaction, or group, includes a latch mechanism for controlling transfer of the blockchain token to the another entity. The latch mechanism can be applied to a single instance i.e. a single transfer or can be established on creation of the token such that it is used in all token transactions. The latch mechanism operates to apply a latch that restricts transfer of the token unless conditions have been met, and release the latch when said conditions have been met. In use, an entity transferring a token to another entity can release a preceding restriction, said preceding restriction applied in a preceding blockchain transaction and configured to restrict transfer of the blockchain token. There may be no preceding restriction, but either way the entity can apply a subsequent restriction, said subsequent restriction configured to restrict the ability to assign the blockchain token in a subsequent blockchain transaction e.g. by the another entity. The another entity receiving the token and / or a miner processing the transaction for inclusion in a block can process the transaction to determine whether the conditions have been met such that restrictions are removed. The latch mechanism can be described as imposing a conditional transfer of the token. While this can be applied in a single instance, using a transaction or a group of transactions, a latch mechanism can be applied to the entire chain of token transfers, wherein the methods taught herein use the transactional relationship with the previous and subsequent transactions to at least one of: inhibit double spending; and determine the validity of the token using an inductive proof. According to one aspect, there resides a computer-implemented method comprising: at least one of using, processing and / or generating a blockchain transaction, said blockchain transaction processing a blockchain token in an update of the blockchain token; and at least one of using, processing and / or generating at least one of an unlatch-script and a latch-script, said unlatch-script and said latch script being part of a latch mechanism configured to control die update of the blockchain token, wherein the latch mechanism comprises: the unlatch-script, which is configured to release a preceding restriction, said preceding restriction applied in a preceding blockchain transaction and configured to restrict the update of the blockchain token; and / or the latch-script, which is configured to apply a subsequent restriction, said subsequent restriction configured to restrict the ability to update the blockchain token in a subsequent blockchain transaction. According to another aspect, there resides a computer-implemented method comprising: at least one of using, processing and / or generating a blockchain transaction, said blockchain transaction processing a blockchain token in an update e.g. transfer of the blockchain token from a first entity to another entity. Processing can include at least one of, but not limited to, assigning, splitting and merging at least one of the blockchain token, the asset that it represents, the underlying cryptocurrency and another tokenised asset. The method further comprises at least one of using, processing and / or generating at least one of an unlatchscript and a latch-script, said unlatch-script and said latch script being part of a latch mechanism configured to control the update e.g. transfer of the blockchain token to the another entity. The latch mechanism comprises: the unlatch-script, which is configured to release a preceding restriction, said preceding restriction applied in a preceding blockchain transaction and configured to restrict the update e.g. transfer of the blockchain token e.g. to the first entity; and / or the latch-script, which is configured to apply a subsequent restriction, said subsequent restriction configured to restrict the ability to assign the blockchain token in a subsequent blockchain transaction e.g. by the another entity. The latch mechanism can be part of a token i.e. part of the input and output used in a token transaction. Tire latch mechanism can be part of a separate input and output of a transaction including the token. The latch mechanism can a combination thereof i.e. the script defining its functionality can be divided between the token and a separate transaction output and / or input. The latch mechanism can be described as an interlock, wherein a latch mechanism can apply a lock to a token, which can ensure valid update e.g. transfer of a token and / or ensure the conditions for establishing a key, wherein when said conditions are met, the key is determined and can be used to release the lock and enable valid update e.g. transfer of the token. The latch mechanism, or part thereof, can be applied in for a single instance e.g. a single update e.g. transfer. However the latch mechanism can be applied in a chain of transactions - preferably from the point of token creation. When applied to all transactions in a chain, the latch mechanism goes through a latch and release cycle, wherein in an one transaction, or group of transactions, implementing a latch mechanism there can be (i) a dimensional level of security added e.g. a latch is created to determine conditions to be met before a token can be transferred, and (ii) a temporal level of security e.g. the entity seeking to update e.g. transfer a token must first release a restriction applied by a preceding latch script in a preceding transaction, while imposing a restriction upon the another entity receiving the token, which must be processed by the another entity using a subsequent unlatch-script in a subsequent transaction. In a chain of updates e.g. transfers there can be: a preceding latch, latch and subsequent latch operations, as well as: a preceding unlatch, unlatch and subsequent unlatch operations. In any one update e.g. transfer, which includes a transaction or group of transactions, the entity assigning the token can unlatch a previous restriction, determine an assignment, and impose a subsequent restriction using a latch. By way of example, a restriction placed upon a recipient of a token using a latch can impose a condition that requires, upon unlatching, at least one of: a smart contract, or part thereof, to be fulfilled; and an inspection and / or rebuild of the transaction that applied the latch. While the method of at least one of using, processing and / or generating a blockchain transaction can occur in a single instance, the latch mechanism can be an integral component of the preceding blockchain transaction, the blockchain transaction and the subsequent blockchain transaction. In other words, the method of at least one of using, processing and / or generating a blockchain transaction is repeated and perpetuates through the chain of transactions, with each transaction as taught herein updating a blockchain token. In each of the preceding blockchain transaction, the blockchain transaction and the subsequent blockchain transaction the latch mechanism is part of the same transaction, or group of transactions, that updates e.g. transfers the token. The unlatch-script can be configured as an input to the blockchain transaction. Hie latch-script can be configured on the output of the blockchain transaction. The latch-script and / or unlatch-script can be processed together with token script. The latch mechanism can comprise (i) a plurality of unlatch-scripts and / or (ii) a plurality of latchscripts, wherein said unlatch-scripts and / or latch-scripts respectively release and / or apply a plurality of restrictions upon the update e.g. transfer of the blockchain token. In other words, multiple conditions can be placed on the 'latching' of the token update e.g. transfer, said conditions including at least one of, but not limited to: knowing something e.g. having access to or determining digital data; meeting a contractual obligation e.g. fulfilling, at least in part, a smart contract; and a time restriction. The latch mechanism can function like an interlock on the transaction that updates e.g. transfers the token. Beyond the token it places additional conditions / requirements on the ability to use the token in a transaction. The method can be configured such that only the first entity is able to process the unlatch-script to release a preceding restriction, and / or the latch-script is configured to limit removal of the subsequent restriction to the another entity by processing a subsequent unlatch-script. The method can comprise at least one of using, processing and / or generating a group, said group being one of a series of groups of blockchain transactions, said group including the blockchain transaction. The group of transactions can be created and / or broadcast by the entity initiating the update e.g. transfer of the token. The group of transactions can include a first transaction that applies a latch to the token being updated, and a second transaction that updates e.g. transfers the token to the another entity. Tins provides an alternative to applying a latch to the token being updated e.g. transferred and updating the token to the another entity in the same transaction. The group of transactions can comprise: a commitment transaction, in which the first entity commits to assigning the blockchain token to the another entity; and an exchange transaction, in which the first entity assigns the blockchain token to the another entity. The commitment transaction can function to update e.g. transfer control to the another entity once transferred. The commitment transaction can include the latch script. Hie exchange transaction can include the unlatch-script. Processing the latch-script can impose conditions upon the update e.g. transfer of the blockchain token in a subsequent blockchain transaction or group of transactions. Processing the unlatch script can conditionally satisfy conditions imposed, in a preceding blockchain transaction or group, upon the update e.g. transfer of the blockchain token. Conditions can include at least one of: determining that a predetermined amount of time has lapsed; determining that a smart contract, or part thereof, has been fulfilled; determining that trading restrictions have been complied with; determining that a database, or part thereof, has been completed; and determining the state of a state machine. The blockchain transaction, or group of transactions can include at least one of: verification-script configured to determine the presence of a latch mechanism; and / or push-script configured to enforce that a latch mechanism is processed, at least in part, as part of a subsequent transaction or group of transactions. The blockchain transaction, or group thereof, can be one of a chain of transactions, wherein: each transaction includes, at least in part, the latch mechanism; and each latch mechanism, or part thereof, enables the validity of the blockchain token back to Genesis to be determined. The update e.g. transfer of the blockchain token to the another entity can be conditional upon: processing the latch-script, which defines a base step that requires verification that a condition is true in a subsequent blockchain transaction or group; and processing the unlatch script, which defines an inductive step that provides verification that the condition is true in a preceding transaction. The method can impose the inclusion of the latch-script and unlatch-script in each transaction, or group of transactions, such that a recipient of a blockchain token or a miner processing the transaction for inclusion in a block can determine, using an inductive proof, that the token has been validly updated e.g. transferred from the point at which the latch mechanism was applied to the token. If the latch mechanism was applied to the token from its inaugural update e.g. transfer then the validity of the token can be determined back to its Genesis. Determining an inductive proof can include an obligation for the presence of a latch mechanism in a transaction or group of transactions. Determining an inductive proof can include: latching of restrictions, using latching script, to the another entity e.g. the latching to the assignee (base step), which imposes a condition; and releasing a latch and restrictions by complying with conditions e.g. the unlatching by the assignor (inductive step), which must determine that a condition is true. The method can further include processing and / or generating a blockchain transaction, or group of transactions, to include the respective token, which has at least one of: a quantity of token units (TU); a quantity of token-related cryptocurrency (TRC) associated with the respective token (T): and a record of the blockchain transaction (MTx) and index output of the respective token. The blockchain transaction, or group of transactions, can further comprise Issuer-related output (I-UTXO) comprising issuance data (IData) associated with the Token Issuer (TI). The issuance data and / or minting record associated with the minting transaction can be checked to ensure that the token or number of token units transferred is a genuine, authorised token or token unit in accordance with an example of the present disclosure. Techniques and technologies such as Simplified Payment Verification (SPV), Metanet graphs etc can be used in conjunction with one or more examples to further enhance efficiency and speed of verification or transfer, while preserving security. All tokens can be configured to persist their gene-sisOutpoint forever and / or tokens e.g. fungible tokens can persist the issuerPubKey and / or issuerPub-KeyHash. The transaction, or group of transactions, can include authentication information comprises at least one of: the latest outpoint on the ledger of the respective token e.g. parentOutpoint, and / or grandparentOut-point and / or parentTxType and / or grandparentTxType; a piece of data indicating the lastMutationOutpoint (e.g. split / merge etc); a flag indicating the validity of the respective token (T); data that enables the validity of the respective token to be determined e.g. SPV data and / or a Merkle proof that the token Tx was compiled in a specified block; a signature required to process the respective token in a subsequent transaction, wherein said signature validates and / or controls the ability to transfer the respective token; and the full historical raw token transaction(s) and / or the data needed to reconstruct that or those ancestral transac-tion(s). The method can further comprise using, processing and / or generating a subsequent blockchain transaction, said subsequent blockchain transaction comprising a replacement or re-issued respective token having the same authentication information as the previous respective token and / or the capability to parse an issued token protocol upgrade transaction containing a latch mechanism. According to another aspect, there resides a computer-implemented method comprising: at least one of using, processing and / or generating a blockchain transaction, or group of transactions, said blockchain transaction processing a blockchain token that includes in the output: an inaugural latch mechanism, or part thereof; a subsequent restriction requiring the creation of a latch mechanism; and an update e.g. transfer of the blockchain token from a first entity to another entity; and at least one of using, processing and / or generating a latch-script, said latch script being part of a latch mechanism configured to control update e.g. transfer of the blockchain token to the another entity. The inaugural latch mechanism, or part thereof, can be applied by an issuing authority, or their agent, and impose that a latch mechanism is present in each token update e.g. transfer or by some other period.. According to another aspect, there resides a computer-implemented method comprising receiving and at least one of using, processing and / or generating the blockchain transaction, or group of blockchain transactions as described and claimed herein, said blockchain transaction processing a blockchain token in an update e.g. transfer of tire blockchain token from a first entity to another entity. The recipient of the blockchain transaction, or group of blockchain transactions, can be the another entity and / or a miner - each of which determines whether the update e.g. transfer is valid e.g. conditions have been met. According to another aspect, there resides a system comprising: a port configured to receive transactions directly and / or from at least one other node in a blockchain network; and a processor configured to produce, hold and / or maintain a record of at least one of the blockchain transaction and token of any preceding claim. According to another aspect, there resides computer equipment comprising: memory comprising one or more memory7 units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform any of the methods as claimed herein. According to another aspect, there resides computer a computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform any of the methods as claimed herein. According to another aspect, there resides computer equipment having memory7 comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of the claims herein. According to another aspect, there resides a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system to perform the methods claimed herein. The controller can process instructions on the output of a respective token’s blockchain transaction. The instructions can be script. According to another aspect, there resides a digital wallet arranged and configured to perform any of the methods as claimed herein. According to another aspect, there resides a computer network comprising a plurality of nodes, wherein each node in the computer network comprises: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform a method disclosed herein, such as a token transaction of a token that determines the status of a token. While the examples herein have been described with reference to a latch mechanism and a token, the teaching herein can be applied to implement transactions, or groups of transactions, involving a plurality of latch mechanisms and / or a plurality of tokens, and the processing and / or validation thereof. The methods taught herein can further include melting a token. According to another aspect, there resides a computer-implemented method, comprising: at least one of using, processing and / or generating a blockchain transaction, said blockchain transaction comprising a first output defining a blockchain token and a second output, the first and / or second output configured to: when processed by or in conjunction with a subsequent blockchain transaction, cause a rebuild and / or inspection of the blockchain transaction, and cause submission of the subsequent blockchain transaction to fail unless an identifier of the rebuilt and / or inspected transaction matches an identifier of the blockchain transaction on the blockchain. By way of example, the first or second output can be configured to ensure processing by or in conjunction with a subsequent blockchain transaction, said transaction executing a full rebuild and / or inspection of the initial blockchain transaction, and cause submission of the subsequent blockchain transaction to fail unless the calculated txid identifier of the rebuilt and / or inspected transaction is contained within a set of transactional input prevOutpoints e.g. the other (first / second) of the outpoints is concurrently being unlocked &matches the legitimate identifier of the blockchain transaction on the blockchain. The order and labelling of the outputs can be irrelevant. Overall, the methods herein include establishing a latch mechanism that is associated with a blockchain token to be updated e.g. transferred, which can be for used for a single-update, or configured to be applied to all subsequent blockchain token updates. The association between the latch mechanism and the token can function as an interlock, such that the latch mechanism, or part thereof, and the token are interdependent. In other words, the latch mechanism’s purpose is to control token update e.g. transfer, and the token cannot be validly updated e.g. transferred unless the conditions of the latch mechanism are determined to be met. The latch mechanism comprises at least two parts: a latch component, attributed to the entity that can validly update e.g. transfer the token after conditions have been met; and an unlatch component, which is processed to release the latch after determining that conditions have been met. The latch mechanism can be described as an interlock, wherein the latch component: applies a lock to a token to ensure valid update e.g. transfer of a token and the conditions for establishing a key; and when conditions are met, a key is determined and can be used to release the lock and enable valid update e.g. transfer of the token. By creating the latch mechanism, conditions are imposed that enable the determination of the validity of the update e.g. transfer. Such validity can be determined once, at any time. However, in the majority of the examples herein the latch mechanism is configured promptly after the token is minted e.g. by an authority responsible for the token and / or its management, such that a latch mechanism is present throughout the subsequent chain of transactions. However configurations can exist which require some latch mechanism script to also exist in another UTXO somewhere in the token’s mint transaction. Not only do the methods herein apply to an entity using the method to process a latch mechanism associated with a token, but those receiving the token and / or reviewing the token i.e. a recipient and a miner, respectively, are able to process a transaction comprising a token and an associated latch mechanism to determine the validity of the token. A third party who is to receive the token can process the transaction to review the validity. However, independently of the sender and receiver, the broadcast transaction will be received and reviewed by miners on the blockchain network, and said miners will process the transaction and only include it in a block if it is determined to be valid. Determination can be achieved from the transaction and information on the blockchain alone. To be clear, processing the transaction to determine validity does not require any additional protocols or inputs other than the blockchain protocol required to manage the cryptocurrency upon which the blockchain token is based. Therefore, the establishment of the latch mechanism and its association with a token supports the determination of the token’s validity and inhibits counterfeiting e.g. double-spending, and said validity is determinable by the recipient and / or a miner. To implement the latch mechanism, an entity can configure a transaction output, or plurality of outputs, including a token, whose validity is to be determined, and a latch mechanism. The latch mechanism can become interlocked with the token and updated e.g. transferred to the entity who is to receive the token i.e. the token is 'latched’ to the intended recipient. The entity configuring the latch mechanism can provide in the transaction at least one of instructions, required information and script e.g. in a supplementary transaction output, for the receiving entity to process the transaction, determine that the token is valid and release the latch i.e. process unlatch script that enables the recipient to make a subsequent update e.g. transfer of the token. While the latch mechanism can be used for a single instance, an entity configuring a latch mechanism can impose a requirement that all subsequent tokens updates e.g. transfers must include a latch mechanism, and such an imposition can be made, by way of example, by an entity that is an authority responsible for the tokens e.g. a bank whose assets are represented digitally by blockchain tokens. The imposition that a latch mechanism is required for all subsequent token updates e.g. transfers can be implemented. The latch mechanism can be configured to place a restriction upon a subsequent update e.g. transfer of the token - for example it can place a condition upon subsequent update e.g. transfer that must be met before a token can be validly updated e.g. transferred again. By way of example, to release a restriction, and determine the validity of the token, at least one of the following must be included in a transaction, or group of transactions, having a latch mechanism: the transaction, or the group of transactions, that are transferring a token has a latch mechanism, which includes latch script for attributing the latch to the entity who will receive the token; the transaction, or the group of transactions, that are transferring a token has a latch mechanism, which includes unlatch script for releasing a restriction and / or determining that a condition has been met, said restriction / condition placed in a previous transaction, or group of transactions, such that token can be determined as being valid and / or transferred; and the requirement for a latch mechanism is pushed through to the next transaction, or group of transactions, thus placing an obligation for each recipient of a token to perpetuate the use of a latch mechanism, which can, by way of example, be implemented in script using, for example, an OPPUSHTX instruction. Each transaction, or group of transactions, implementing the latch can be configured to include at least one of, but not limited to, the following locking script arguments and their computational types: genesisOutpoint; grandparentOutpoint; parentOutpoint; pubKeyHash; and beneficiaryCommitment. Tire entity receiving the token and / or a miner processing can process the transaction or group of transactions to determine whether conditions have been met for a valid update e.g. transfer of the token. Following establishment of a latch mechanism, which can be perpetuated in the chain of subsequent transactions, each entity can receive and subsequently establish a proof of validity e.g. an inductive proof of validity, which provides an additional or alternative mechanism for determining the token validity without going back to genesis. The methods herein are taught using an example wherein a token is updated e.g. transferred from one entity to another entity. Additionally or alternatively to the term ‘update’ e.g. transfer, the latch mechanism can be used to govern the change of status of a token, such that the token’s configuration is able to determine the operation of an asset or resources e.g. a machine or system. A token’s configuration, or status, can be operated like a state machine, wherein it represents, for example, an indication of whether a machine should be on or off e.g. the token operates as a finite-state machine, wherein the status of a token can be determined by the transaction output. An update to a token can be implemented without it being transferred from one entity to another entity. Brief Description of the Drawings Figure 1 has already been described as an example of a logical sub-ledger of associated blockchain tokens issued by the same issuer is implemented on a blockchain ledger e.g. the Bitcoin blockchain. Figure 2a illustrates a known chain of token transactions. Figure 2b illustrates sequential transactions, nominally TxPrev i.e. a previous transaction followed by TxNew i.e. a subsequent transaction, showing known transaction outputs and outputs in relation to a “script engine” that processes in order the ‘scriptSig’ and then the scriptPubKey to determine an output e.g. “True” that validates and / or enables the transaction between TxPrev and TxNew. Aspects and examples of the present disclosure will now be described, by way of example only, and with reference to the accompany drawings, in which: Figures 3(a) to 3(d) are a series of transactions, comprising groups of transactions that include a latch mechanism, wherein a token is transferred between entities. Figure 3(e) is an example of Figures 3(a) to 3(d), wherein only one latch mechanism is used. Figure 4 is an example of broadcast transactions that implement the transactions of Figures 3(a) to 3(d). Figure 5 is a flowchart describing a selection of some of the steps that implement the transactions of Figure 4, and by whom they are performed. Figures 6(a) to 6(d) are a series of transactions that include a latch mechanism, wherein a token is transferred between entities. Figure 6(e) is an example of Figures 6(a) to 6(d), wherein only one latch mechanism is used. Figure 7 is an example of broadcast transactions that implement the transactions of Figures 6(a) to 6(d). Figure 8 is a flowchart describing a selection of some of the steps that implement the transactions of Figure 4, and by whom they are performed. Figure 9 is a system diagram of a device, such as a node or computational unit. Detailed Description of Illustrative Examples of the Disclosure Examples of some possible use cases are now provided for the purpose of illustration, without limitation. As explained above, for the sake of convenience only, we will refer herein to “Bitcoin" for our examples as it is the most well-known and widely used blockchain protocol. Examples of the disclosure may be implemented on the Bitcoin protocol, platform and ledger, although this and the references to Bitcoin are not intended to be limiting and the scope of examples of the present disclosure is not thus restricted. Figure 1 and the associated operations and functions of creating and managing tokens are known, and disclosed in WO2021 / 250037, which is incorporated by reference herein in its entirety. Background Once a blockchain token is issued or minted by an issuer or other such authority on the blockchain the token’s legitimacy can depend entirely on the issuers signature action and / or also the data contained in the “mint” transaction. The mint or “genesis” transaction identifier (txid) can be used as the pointer to origin for a tokens lifecycle and can include the issuers identifier e.g. their public key. However, validation at the bitcoin consensus layer becomes impracticable because of the growing length of transaction histories and / or ballooning transaction sizes. Methods taught herein provide alternative means for validation of a blockchain token e.g. using proof by mathematical induction. Overview of examples Examples of the invention reside, at least in part, in a protocol that governs the conditional transfer of a blockchain token. Tire protocol resides in the methods of operation taught herein, which enable the determination that the restrictions for transfer applied to a token are removed by satisfying predetermined conditions e.g. the validity is determined. Conditional transfer is implemented using a latch mechanism that comprises two components: a latching component that applies a ‘latch’ and a restriction to a blockchain token, which can be released if conditions are met in a subsequent blockchain transaction e.g. if Alice wishes to place conditions of transfer upon a token when transferring it to Bob she can apply the latch mechanism in the process of transferring the token to Bob that obliges that a condition is met before he can transfer the token; and an unlatch component that restricts subsequent transfer of a token, wherein the unlatch component is processed to release the previously applied ‘latch’ and release the restriction e.g. to subsequently transfer the token to Charlie, Bob must release the latch mechanism by meeting the conditions previously imposed before being able to make a valid transfer to Charlie. Examples of the invention reside in at least one of using, processing and / or generating a blockchain transaction. The blockchain transaction can be used for processing a blockchain token in a transfer of the blockchain token from a first entity to another entity. Processing e.g. transferring the transfer can include, by way of non-limiting example, at least one of the assignment, splitting and merging assets represented by the blockchain token. The transfer from the first entity to the another entity can be implemented in (i) a single transaction, as described and shown in relation to Figures 6, 7 and 8, or (ii) as part of a group of transactions, as described and shown in relation to Figures 3, 4 and 5. Examples herein include using a latch mechanism that adds a restriction upon the transfer of the token that requires conditions to be met before a valid transaction can be determined. The latch mechanism comprises two parts: a latch-script, which places a restriction upon a token transfer; and an unlatch-script, which releases the restriction by ensuring that conditions have been met. A token transaction, therefore, includes at least one of using, processing and / or generating at least one of an unlatch-script and a latchscript, said unlatch-script and said latch script being part of a latch mechanism configured to control transfer of the blockchain token to the another entity. The latch mechanism can reside in, at least in part, the script defining the token, latch-script and / or unlatch-script, or a combination thereof. The latch mechanism can be spread across two or more transactions. The examples herein describe the latch mechanism, or parts thereof, and blockchain token being transferred as being included with the same transaction. Tire examples are not so limited and the components of the latch mechanism can be implemented in their own separate transactions, wherein such transactions are associated with the blockchain transactions. In other words, and by way of non-limiting examples, a conditional transfer of a blockchain token can be managed by a latch mechanism in a separate transaction e.g. a separate transaction that is linked to the blockchain transaction defining the blockchain token. The separate transaction can be broadcast substantially simultaneously with the transaction making the transfer such that both transactions reside on-chain at substantially the same point in time. It is to be noted that examples are often directed to ‘a’ latch mechanism - this is because the claims are directed to a single transaction e.g. see Figures 6, 7 and 8, or a group of transactions involving a single assignor of a blockchain token e.g. see Figures 3, 4 and 5. In use, however, two components of a latch mechanism are used to effect a blockchain transaction and while these two components make a latch mechanism the latch mechanism is composed of at least two parts, and each part can be associated with a different entity involved in the transfer. By way of example, the transfer of a token from Bob to Charlie can include an unlatch component processed by Bob to enable him to effect the transfer and a latch component applied to Charlie, who is the recipient of the blockchain token. Further to the conditional transfer of a token, the methods herein can be applied to (i) a single transfer i.e. applied to a transfer from one entity to another entity, and / or (ii) all entities in the chain. In other words, upon the implementation of a latch mechanism e.g. in an inaugural transaction, the entity establishing the latch mechanism can confinn the relationship between the token and a latch mechanism to i.e. upon establishment of the requirements for a latch mechanism the controls imposed upon a transfer of the token can be applied to a single instance of transfer or each subsequent instance of transfer. Latch mechanism - overview In each of the examples herein e.g. Figures 3(a) through to Figure 8, and in the device embodied in Figure 9, a computer-implemented method uses a blockchain transaction to process a blockchain token to transfer the blockchain token from a first entity to another entity. Hie method comprises at least one of using, processing and / or generating at least one of an unlatch-script and a latch-script, which are part of a latch mechanism configured to control transfer of the blockchain token to the another entity. The unlatch-script is configured to release a preceding restriction. The preceding restriction was applied in a preceding blockchain transaction and configured to restrict transfer of the blockchain token. In one example, in the preceding transaction a latch was applied to the blockchain token now held by the first entity and before that token can be transferred to the another entity the restrictions applied by the latch must be lifted by processing the unlatch script to release the previous latch. For example, if Alice is in control of a blockchain token that has a ‘latch’ e.g. a latch condition applied to said token that places conditions and / or restrictions on the subsequent transfer of that token then these must be released using the unlatch-script before it can be transferred to Bob. The latch-script can be configured to apply a subsequent restriction to the blockchain token. The latch-script functions to ‘latch’ the subsequent restriction and restrict the ability to assign the blockchain token in a subsequent blockchain transaction. For example, if Bob is in control of a blockchain token and wishes to transfer it to Charlie then he can apply a ‘latch’ to said token and place conditions and / or restrictions on the subsequent transfer of that token that must be released using the unlatch-script before it can be transferred again e.g. to Dave. The restriction upon transfer of the blockchain token can be implemented by script embedded in the token script. In one example, associating a latch with a token output e.g. applying an interlock to the token, can functions to transfer control of the token e.g. the token’s UTXO, without transferring the token. To transfer a token to which a latch mechanism has been applied requires, by way of example, consuming and inspecting the full ‘rawSpendTx’ e.g. the raw transaction that applied the latch, of the transaction in which the interlock was created. In other words, unlatching a token can require at least one of parsing and verifying the origin and destination of the inputs and outputs of the transaction that included the latch script. The latch mechanism can be described as an unique locking restriction whereby any token output e.g. UTXO, the latch output, in one transaction can be processed in another transaction in order to inspect the full transaction containing the latch output. By way of non-limiting example, the unlatching process can include ensuring the latch outpoint is within the set of the unlatching transaction input outpoints e.g. via a PUSHTX hashPrevouts value comparison with the result of a sha256d(sctOfPrc\ Outpoints) calculated value, and that outpoint is calculated from first principles, e.g. recalculating sha256d(rawLatchTx) + vout 8 bytes (known, given or calculated vout index). The latch mechanism can be used in a chain-like manner to define, at least in part, a protocol that determines the validity of a blockchain token. The protocol of examples herein can be described as the method of creating a latch mechanism and corresponding token, wherein the rules of subsequent transfer are established e.g. the application of restrictions upon a token transfer (i.e. latch script), which requires subsequently satisfying conditions to release the restrictions (i.e. unlatch script). Used in a chain, the latch mechanism can establish a protocol that enables the determination of validity. A primitive of the examples herein can be described as an implementation of the protocol. Validity can be determined from a chain of latch mechanisms that are continuously applied i.e. latched and released i.e. unlatched. The components of a latch mechanism must reside in a transaction, or group of transactions, although the components can be attributed to different entities e.g. in an exchange transaction the entity holding the blockchain token must first release the latch that is attributed to said first entity using unlatch-script before applying a latch to the another entity receiving the blockchain token. Alternatively, the responsibilities of the components can be rotated. An oracle can be assigned a component, or part thereof e.g. when determining that a smart contract has been fulfilled an oracle can be consulted to determine whether a condition required to unlatch am applied mechanism has been met. In one example, tire latch mechanism communicates with an oracle, wherein the oracle determines whether a condition has been met to satisfy a requirement set by latch script - hence when the condition can be met the oracle, for example, signs the unlatch script. An oracle can be used, for example, when the requirement relates to only part of a smart contract, such that the unlatch script relates to only the relevant part of the smart contract that is to be fulfilled and avoids the need to incorporate the full smart contract in the latch mechanism or its associated transaction. The unlatch-script can be configured to release a preceding restriction that was applied in a preceding blockchain transaction, or group of transactions, containing an output with a latch mechanism e.g. unlock script can be processed. The latch mechanism (e.g. the latch script and / or the unlatch script) and / or the blockchain token can contain further embedded unlocking script. The unlatch script can be associated with blockchain token unlocking script, such that the entity that can be designated to receive the associated token must process the token and the unlatch script of the latch mechanism together. For example, a pay-to-public-key-has (P2PKH) can be applied to the latch mechanism for unlatching the restriction on transferring the blockchain token when a condition has been met e.g. it is encapsulated / required by the token unlocking script. In other words, the unlatch script can be applied to the token, which has been assigned to an entity rather than applied to the entity itself. For example, the token includes script that determines whether the unlatch script has been executed to meet a condition and release the restriction set by the latch mechanism. Unless conditions have been met that release the restriction then neither the recipient e.g. the another entity, nor a blockchain miner processing the transaction, will recognise the token transfer as valid. The emit)' having control of the token to whom part of the latch mechanism has been applied must comply with the requirements to release the restriction before being able to transfer the token. The latchscript can be configured to apply a subsequent restriction upon the recipient of the token e.g. the another entity can be configured to oblige the recipient to comply with requirements and / or meet certain conditions, such that a chain of latch mechanisms can be enforced. In other words, in a chain of transactions transferring a blockchain token between entities includes a latch mechanism for each transfer, such there can be a constant cyclical ‘rolling’ of latching, unlatching, latching and unlatching etc. At any one time in the cycle there will be: a preceding latch, latch and subsequent latch; and a preceding unlatch, unlatch and subsequent unlatch. These are staggered across the entities as will be clear in the examples herein. It is to be noted, however, that a latch mechanism can be applied to a single instance of a blockchain token transfer, as described herein in relation to Figures 3(e) and 6(e), wherein a latch mechanism has been applied only to a transfer between Alice and Bob. The latch mechanism can operate in a separate transaction e.g. in a separate chain of transactions being processed concurrently with the transfer of the blockchain token. Additionally or alternatively the latch mechanism can be an integral component of at least one preceding blockchain transaction, the blockchain transaction and the subsequent blockchain transaction. In other words, the method can require that a component of the latch mechanism must be part of the same transaction that transfers the blockchain token. The unlatch-script can be configured as an input to the blockchain transaction. The latch-script can be configured as an output of the blockchain transaction. While examples herein comprise a single token and a latch mechanism, the scope of the examples extend, in light of the teaching herein, to cover (i) a plurality of tokens, each governed by their own latch mechanisms or any permutation of shared latch mechanisms, (ii) a plurality of tokens governed by a common latch mechanism, and (iii) a latch mechanism having a plurality of unlatch-scripts and / or a plurality of latch-scripts, wherein said unlatch-scripts and / or latch-scripts respectively release and / or apply a plurality of restrictions upon the transfer of at least one blockchain token. Multiple conditions can be placed, or latched, to a token during a transfer such that unlatching requires a plurality of conditions to be met. By way of non-limiting examples, a condition to be met can include at least one of the following: knowing something e.g. knowing a private key required to unlock; meeting a contractual obligation e.g. a smart contract; and an amount of time lapsing. Overall, the latch mechanism can be described as an interlock on the token and / or transaction that transfers the token. Beyond the token, the latch mechanism can place additional conditions / requirements on the ability to use the token in a transaction and / or prove its validity. Additionally or alternatively, the latch mechanism can place additional conditions / requirements on itself. Applying a latch using the latching mechanism can involve just one entity, which nominally is the entity receiving the blockchain token. Alternatively, release of the restrictions can require a plurality of entities to meet conditions e.g. the restriction can be that a smart contract must be fulfilled, and the entity to whom the token is transferred can only process the token when several restrictions have been lifted. This can be handled by an oracle, which can provide a signature to enable the unlatch script to be processed to release the restrictions when all conditions have been met. It follows that said entity may be the only entity able to release the conditions placed upon the subsequent transfer of the blockchain token. A latch, however, can be configured such that a plurality of conditions must be met before it can be released. The plurality of conditions can be applied to a plurality of entities. Additionally or alternatively, a latch-script can be configured to limit removal of a subsequent restriction e.g. conditions placed upon the transfer of an associated blockchain token, wherein said restrictions placed upon a token held by a recipient e .g. another entity, who is required to process a subsequent unlatchscript and / or satisfy the conditions required to release the restrictions in order for the transaction to be processed successfully by a miner. Latch mechanism - groups - overview While the method herein can be implemented by an entity within one transaction, as per Figures 6(a) to 8, the step of attributing a latch mechanism to a blockchain token and the subsequent release of the latch before a subsequent transfer can be enacted can clearly be illustrated in Figures 3(a) to 5. In Figures 3(a) to 5, a blockchain transaction is used to process a blockchain token in a transfer of the blockchain token from a first entity to another entity. The process can additionally or alternatively include at least one of, but not limited to, assigning, splitting and merging digital assets represented by the token. The method includes at least one of using, processing and / or generating the latch mechanism as described herein, which includes at least one of an unlatch-script and a latch-script, said unlatch-script and said latch script being part of the latch mechanism configured to control transfer of the blockchain token to the another entity. The method is illustrated showing that each entity uses a group of transactions, said group being one of a series of groups of blockchain transactions in the transfer of a blockchain token between entities. The entities in the examples are labelled George (G), Alice (A), Bob (B) and Charlie (C), and the subtext letter indicates to whom a token output or a latch output is attributed. George is typically a creator, authority or manager of the token ledger and it is in his interest that the protocol as taught herein is established securely and operates efficiently. In Figure 3(a) a blockchain token is created at TxO e.g. by George and assigned to George. In Txl, George creates a transaction using his token (Token-) token as an input and in the output he: assigns the token to himself; and creates a second output, which is a latch of a latching mechanism (LatchA) that is attributed to Alice. To be clear, George adds latch-script in Txl, which is configured to apply a subsequent restriction on the ability of Alice to use the blockchain token. The restriction is configured to at least one of: restrict the ability to assign the token in a subsequent blockchain transaction; place a condition on Alice to prove the validity of the token; place a condition on Alice to process the latch mechanism using the unlatch script to show and / or determine the validity of the token, said unlatch-script configured to release a preceding restriction; and oblige any recipient of the token to apply a latch-script thereto, such that the requirement for a latch mechanism perpetuates, and each subsequent token transfer transaction group requires the unlatching of previous latch mechanism and the creation of a new latch mechanism. In practice, George, or any other entity, can implement the latch mechanism and apply it to a token transfer for any given transaction, or even all subsequent transactions. In this example it is suggested that George is the token creator and acts as an issuing authority e.g. he functions like a regulated financial institution taking regulated responsibility for the tokens. In Tx2, George assigns the token to Alice, as indicated by the change in subscript from G’ to ‘A’. Because George created the inaugural latching mechanism there is no preceding latch having conditions or requirements to fulfil. In the example of Figure 3(a), the issuer, George, can (i) issue, mint or refresh a token and associated it with an existing latch mechanism, and / or (ii) create a latch mechanism at the same time the token is issued, minted or refreshed. Figure 3(b) includes Txl and Tx2 from Figure 3(a) for clarity. Alice wishes to transfer the token to Bob and compiles two transactions for broadcast on the blockchain network. In Tx3, Alice assigns the token to herself while creating a new latch for Bob (LatchB) that places a restriction on Bob’s ability to transfer the token when he receives it. In other words, in Tx3, Alice has control of the token while Bob is locked in as the recipient of tire token - and in Tx4 Alice transfers the token to Bob. Alice creates and broadcasts Tx3 and Tx4. This group of transactions establishes a protocol when the use of the latch is imposed upon the chain of token transfer. Before Alice can transfer the token to Bob in Tx4 the restrictions placed on the ability to transfer the token must be released. George placed these restrictions, and therefore the ability of the token recipient i.e. Alice to subsequently transfer a token, upon Alice in Txl. Alice, therefore, must process the unlatch script of the latch mechanism on the input of Tx4 before a valid transfer of the token can be made to Bob, which involves processing, at least in part, the original latch script (Latcha) in Txl, as indicated by the double-lined arrow extending from Latch \ in Tx4 to Txl. Figure 3(c) includes Tx3 and Tx4 from Figure 3(b) for clarity. Bob wishes to transfer the token to Charlie and compiles two transactions for broadcast on the blockchain network. In Tx5, Bob assigns the token to himself while creating a new latch for Charlie (Latchc) that places a restriction on Charlie’s ability to transfer the token when he receives it. In other words, in Tx5, Bob has control of the token while Charlie is locked in as the recipient of the token - and in Tx6 Bob transfers tire token to Charlie. Bob creates and broadcasts Tx5 and Tx6. Before Bob can transfer the token to Charlie in Tx6 the restrictions placed on the ability to transfer the token must be released. George placed these restrictions, and therefore the ability of the token recipient i.e. Alice to subsequently transfer a token, upon Alice in Txl, which have been pushed through the transactions and now also applies to Bob. Bob, therefore, must process the unlatch script of the latch mechanism on the input of Tx6 before a valid transfer of the token can be made to Bob, which involves processing, at least in part, the latch script (LatchB) in Tx3, as indicated by the double-lined arrow extending from LatchB in Tx6 to Tx3. Figure 3(d) includes Tx5 and Tx6 from Figure 3(c) for clarity. Charlie wishes to transfer the token to Dave and compiles two transactions for broadcast on the blockchain network. In Tx7, Charlie assigns the token to himself while creating a new latch for Dave (Latcho) that places a restriction on Dave’s ability to transfer the token when he receives it. While Charlie sends the token to himself on the output of Tx7 Dave is just the designated recipient of the token. Before Charlie can transfer the token to Dave in Tx8 the restrictions placed on the ability to transfer the token must be released. George placed these restrictions, and therefore the ability of the token recipient i.e. Alice to subsequently transfer a token, upon Alice in Txl, which have been pushed through the transactions, applied to Bob and now are applied to Charlie. Charlie, therefore, must process the unlatch script of the latch mechanism on the input of Tx8 before a valid transfer of the token can be made to Dave, which involves processing, at least in part, the latch script (Latchc) in Tx5, as indicated by the double-lined arrow extending from Latchc in Tx8 to Tx5. It is to be noted, however, that a latch mechanism can be applied to a single instance of a blockchain token transfer. Figure 3(e) shows transactions TxO to Tx5, which are comparable to transactions TxO to Tx8 of Figures 3(a) to 3(d), as described herein, except that a latch mechanism, at least in part, has only been applied to the transfer of the token between Alice and Bob. In Tx2 Alice creates a latch and associates it with the token. The latch is transferred to Bob in Tx2, such that Bob has control over the token e.g. after he receives it. Before Bob can transfer the token he must process the latch using unlatch script in order for the token to be valid. Additionally or alternatively, Alice could apply a latch to the token that would require each subsequent transaction to implement and use a latch mechanism, as per George’s actions in Txl of Figure 3(a). Latch mechanism - groups- detail A more granular example of the example of Figure 3 is now described with reference to Figures 4 and 5. The embodiment comprises a method 200, stages of which are carried out by actors George, Alice, Bob, Charlie, and a miner. At step 202, George mints a token by constructing and submitting to the blockchain for mining a transaction 102, denoted TxO. TxO, which may be referred to as a “genesis” transaction, contains a funding input 104, which provides an amount of cryptocurrency, and an output 106, which contains a locking script locking the output, and thus the control of the token, to George. The token and / or the script of the latch mechanism can contain th e rules of a protocol which governs transmittal of the token, which includes the use of the latch mechanism. The protocol rules include conditions that control transmittal of the token and any additional bolt / latch outputs. The protocol can govern the latch and release of the control of a token. Additionally or alternatively, the latch script can determine and propagate the rules of said protocol. Said rules can reside in both the token and the latch output script, or be shared therebetween in any configuration. According to the protocol rules, for George to transmit the token onwards to a new entity, who in this example is called Alice, he can construct and submit at least two transactions in sequence to the blockchain, as shown at steps S204 and S206 respectively. Additionally or alternatively, after minting an agent e.g. an oracle, acting on behalf of George can move the token to Alice by paying the fees in the funding input. The first transaction, 108, is denoted Txl. Txl 108 contains an input 110 which contains an unlocking script that unlocks the output 106 of TxO 102. Txl 108 contains at least two outputs. A first output 112 contains a script which at least one of (i) locks the output 112, and thus control of the token, to George or an actor representing George, (ii) locks control of the token to Alice, or a combination of George or Alice, and (ii) imposes a condition that the next transaction that unlocks this output must transmit control of the token to a particular recipient e.g. Alice. In this example, the condition is that the next transaction must transmit control of the token to Alice. In other words, for the next transaction to successfully unlock this output, that next transaction must lock a corresponding token output to Alice. The condition may specify, for example, Alice's public key hash, a hash of a secret known to Alice, or a redeem script comprising a secret or other script content known to Alice. For example, an unlocking condition can require locking control of the following token output to the token protocol script template containing Alice’s pubKeyHash. . A second output 114 of Txl 108 contains a locking script locking control of that output to Alice, that is, to the same recipient stipulated by the condition of the first output 112. For shorthand purposes, this second output 114 will be referred to as ‘BolfyAlice’. The ‘bolt’ i.e. the latch, is part of the latch mechanism, and the term ‘bolt’ has been used to indicate that the output is secured, or otherwise locked, and just like a ‘latch’ it can be subsequently released. Notably, the mining of Txl 108 does not transmit control of the token to Alice; the token is still under George’s control. By way of non-limiting example, latch scripts can be standard pay-to-publicKeyHash scripts, e.g. Bolt Alice is a simple script containing OP DUP OP HASH 160 <pubKeyHashAlice> OP EQUAL VERIFY OP CHECKSIG’. The second of the aforementioned at least two transactions broadcast by George is denoted Tx2 116. Tx2 116 contains an input 118 which contains an unlocking script that unlocks the first output 112 of Txl 108. Tx2 116 also contains an output 120 which contains a locking script that locks control of the token to Alice. In another configuration, however the token in Txl may be in nobody’s control at all, and anyone could construct Tx2 and pay the fees needed to pass it on to Alice without requiring any signature or by some other manner. During the mining of Tx2 116, the unlocking script of Tx2 input 118 and the locking script of the first output 112 of Txl 108 are executed together. During this execution, the condition, mentioned above, that Tx2 116 (the “next” transaction that attempts to transmit control of the token) is checked, i.e., the locking script of Tx2 output 120 is examined to determine whether Alice is indeed the next recipient. By way of example, this can include building the locking script with Alice's pubKeyHash as the recipient and using an OPPUSHTX hashOutputs value to "check" it is valid. This may involve checking whether, for example, the locking script contains Alice’s public key hash. If die determination is positive, that is, if Alice is indeed the next recipient, then the unlocking of Txl’s first output 112 by the unlocking script of Tx2’s input 118 succeeds and Tx2 116 is successfully mined onto the blockchain, thereby transmitting control of the token to Alice. One possible way of having Tx2’s unlocking script examine the content of Tx2 116 itself is to use the pseudo-OP code “OPPUSHTX” and the validation values it exposes (hashOutputs, hashPrevouts, scriptCode etc) to determine the validity of the token transfer. It is noted that this is the only stage in this protocol where no unlocking of a second transaction output is required to effect transmittal of control of the token during the second transaction of the transfer group. This is because George and / or the oracle or agent operating on his behalf have created and initiated the protocol and do not need to apply it to themselves. In subsequent stages, as will be described below, unlocking of an earlier second output is a further condition imposed on transmitting control of the token. At this stage, George and / or the oracle or agent operating on his behalf have created and initiated the protocol and the token, by way of the protocol rules, can still prove at a later stage that it came from the genesisTx / TxO by way of combining the full inspection / rebuild of Txl with the spend of the bolt output 114 (as Txl input 110 contains a legitimate outpoint reference to the genesisOutpoint TxO output 106 and importantly also contains the scriptContext from the original genesis token output 106, and also a corresponding token output 114). This is to say, in subsequent stages, as has just been and will further be described below, unlocking of an earlier second output can be a further condition imposed on transmitting control of the token. At this point, Alice has control of both the second output 114 of Txl 108 and the output of Tx2 120 (which comprises the token). Alice now wants to transmit control of the token to another recipient, Bob. To effect this transmittal, the protocol whose rules are contained in and propagated by the token and / or the latch mechanism requires Alice to submit at least two transactions in sequence to the blockchain, as shown at steps S208 and S210 respectively. Two ofthese transactions are denoted Tx3 122 and Tx4 130. The transfer from one entity to another follows a latch and release cycle e.g. where a latch mechanism is applied to lock control of a token, and is subsequently unlocked by the entity having control of the token and the latch. Tx3 122 contains an input 124 which contains an unlocking script that unlocks the output 120 of Tx2 116. Tx3 122 also contains at least two outputs. A first output 126 contains a script which both (i) locks the output 126, and thus control of the token, to Alice, and (ii) imposes a condition that the next transaction that unlocks this output must transmit control of the token to Bob into a token output script encapsulating &proliferating the protocol rules. In other words, for the next transaction to successfully unlock this output then the next transaction must lock an output to Bob. The condition may specify, for example, Bob’s public key hash, a hash of a secret known to Bob, or a redeem script comprising a secret or other script content known to Bob. For example, an unlocking condition can require locking control to the following token output to a standard pay-to-public-key-hash (p2pkh) containing Bob's pubKeyHash e.g. an unlocking condition can require locking control of the following token output to the token protocol script template containing Bob’s pubKeyHash. A second output 128 of Tx3 122 contains a locking script locking control of that output 128 to Bob, that is, to the same recipient stipulated by the commitment condition of the first output 126 e.g. locked to Bob’s pubKeyHash or otherwise. For shorthand purposes, this second output 128 will be referred to as “BoltBob”. Notably, the mining of Tx3 122 does not transmit control of the token to Bob; the token is still under Alice’s control. It is to be noted, however, that the token can be under either entities control, or indeed anyone can control the token but Bob is the only valid recipient -because it’s 'latched’ to Bob. Tx4 130 contains a first input 132 which contains an unlocking script that unlocks the first output 126 of Tx3 122 i.e. the token. Tx4 130 also contains an output 136 which contains a locking script that locks control of the token to Bob. During mining of Tx4 130, the unlocking script of Tx4 130 and the locking script of the first output 126 of Tx3 122 are executed together. During this execution, the condition, mentioned above, that Tx4 130 (the “next” transaction that attempts to transmit control of the token from Alice to Bob) is checked, i.e., the locking script of the token output 136 in Tx4 130 is examined to determine whether Bob is indeed the next recipient. This may involve checking whether, for example, the locking script contains Bob’s public key hash. If the determination is positive, that is, if Bob is indeed the next recipient, then the unlocking of Tx3’s first output 126 by the unlocking script of Tx4’s first input 132 succeeds. One possible way of having Tx4’s unlocking script examine the content of Tx4 130 itself is to use the pseudo-OP code “OPPUSHTX”. Tx4 130 also contains a second input 134 which contains an unlocking script that unlocks the second output 114 of Txl 108, i.e., releases the latch e.g. unlocks “Bolt^Alice”. The successful mining of Tx4 130, and thus the success of transmittal of control of the token from Alice to Bob, is contingent on both processing the second input 134 of Tx4 (releasing the latch / bolt attributed to Alice) and the unlocking of the first output 126 of Tx3 122 being successful. As the unlocking script of Tx4’s second input and the locking script of Txl’s second output are executed together, or in other words, as the latch is released e.g. "BoltAlicc" is consumed, its outpoint is confirmed to be included in the verified executing transaction’s scriptContext / txPreimage via a full rebuild or inspection of Txl which is performed in the neighbouring token script e.g. Tx4’s first input script and Tx3‘ first output script executed together shown at step S210. After a rebuild, or inspection, the protocol determines a comparison of the TxID on blockchain with the calculated TxID in scriptContexts.hashPrevouts, which determines that there as a ‘bolt’ in Txl and / or that Txl existed. For example, by reconstructing or being given the full boltTx its txid can be calculated, and the latch outpoint created from that value can be validated to be within the set of the transactions input ‘prevOutpoints’ by way of sha256d (setOfOutpointValuePairs) PUSHTX.hashPrevouts. In other words, after the rebuild, or inspection, of the ancestral transaction, which validates the legitimacy of the historical token transaction, the protocol rules and token and / or latch output scripts ensure that the conditions of the preceding latch mechanism have been satisfied. This can be achieved by ensuring the bolt in Txl is currently being unlocked in the same transaction with the aforementioned scriptContexts.hashPrevouts check using the calculation sha256d(rawTx 1) in the setOfPrevOutpoints, and checking that it matches the grandparentTxid / grandparentOutpoint which has been handed down since Tx2. In this way it can be determined that there was at least a token and a ‘latch’ in Tx 1 and / or that Txl existed. For example, by reconstructing or being given the full boltTx its TxID can be calculated, and the latch outpoint created from that value can be validated to be within the set of the transactions input ‘prevOutpoints’ by way of sha256d (setOfPrevOutpoints) PUSHTX.hashPrcvouts. During the rebuild i.e. the execution of the protocol scripts, the transaction ID TxIDl of Txl 108 is calculated and is compared to the TxID of the transaction as stored on the blockchain, as shown at decision step D212. If the calculated TxIDl and the stored TxID do not match, Tx4 130 is rejected, that is, not mined, and transmittal of the token from Alice to Bob fails (S214). If the calculated TxIDl and the stored TxID match, Tx4 130 is mined and transmittal of the token from Alice to Bob succeeds (S216). Notably, first part of the latch mechanism applied using latch-script in the output of Txl e.g. “BoltAlice” 114 is consumed using unlatch-script on the input of Tx4 and tire latch is released enabling the successful transmittal of control of the token from Alice to another entity. It is to be noted that another latch output is applied using latch-script in the output of Tx3 i.e. a latch is attributed to Bob e.g. “BoltyBob” 128. The group of transactions including Tx3 122 and Tx4 130, created by Alice, have enabled the secure transmittal of the token. Bob wants to transmit control of the token to another recipient, Charlie. To effect this transmittal, the protocol whose rules are contained in and propagated by the token requires Bob to submit at least two transactions in sequence to the blockchain, as shown at steps S218 and S220 respectively. Two of these transactions are denoted Tx5 138 and Tx6 146. As before, the transfer from one entity to another follows the latch and release cycle e.g. where a bolt is applied to lock control of a token, and is subsequently unlocked by the entity having control of the token and the bolt. To transfer the token to Charlie, Bob must first (i) create a latch for Charlie, which occurs in the output of Tx5 138, and (ii) release the latch attributed to Bob, which was applied by Alice in the output of Tx3 122 and occurs in the second input 150 of Tx6 and is enforced by the complimcntarily first input 148 of Tx6’s script executing alongside the token output 142 script from Tx5.In other words, just like Alice in Tx3 122 and Tx4 130, Bob uses a blockchain transaction, said blockchain transaction processing a blockchain token in a transfer of the blockchain token from Bob to Charlie, in this example. In Tx5 138, Bob uses an unlatch-script to release or unlock the part of the latch mechanism e.g. Bolt attributed to Bob in Tx3. The unlatch-script, when processed, is configured to release the preceding restriction on Bob’s ability to make a valid token transfer. In Tx6 146, Bob uses a latch-script, said latch script being part of the latch mechanism configured to control transfer of the blockchain token to the another entity. The latch-script, when processed, is configured to apply a subsequent restriction, said subsequent restriction configured to restrict Charlie’s ability to assign the blockchain token in a subsequent blockchain transaction. Tx5 138 contains an input 140 which contains an unlocking script that unlocks the output 136 of Tx4 13 0. Tx5 13 8 also contains at least two outputs. A first output 142 contains a script which both (i) locks the output 142, and thus control of the token, to Bob, and (ii) imposes a condition that the next transaction that unlocks this output must transmit control the token to Charlie. In other words, for the next transaction to successfully unlock this output then the next transaction must lock an output to Charlie. The condition may specify, for example, Charlie’s public key hash, a hash of a secret known to Charlie, or a redeem script comprising a secret or other script content known to Charlie. For example, an unlocking condition can require locking control to the following token output to a standard pay-to-public-key-hash (p2pkh) containing Charlie’s pubKeyHash. A second output 144 of Tx5 138 contains a locking script locking control of that output to Charlie, that is, to the same recipient stipulated by the condition of the first output 142. For shorthand purposes, this second output 142 will be referred to as “BoltCharlie”. Notably, the mining of Tx5 138 does not transmit control of the token to Charlie; the token is still under Bob’s control. As before, it is to be noted that the token can be under either entities control, or indeed anyone can control the token but Charlie is the only valid recipient - because it is ‘latched’ to Charlie. Tx6 contains a first input 148 which contains an unlocking script that unlocks the first output 142 of Tx5 138 i.e. the token. Tx6 146 also contains an output 152 which contains a locking script that locks control of the token to Charlie. During mining of Tx6 146, the unlocking script of Tx6 146 and the locking script of the first output 142 of Tx5 138 are executed together. During this execution, the condition, mentioned above, that Tx6 146 (the “next” transaction that attempts to transmit control of the token from Charlie) is checked, i.e., the locking script of Tx6 146 is examined to determine whether Charlie is indeed the next recipient. This may involve checking whether, for example, the locking script contains Charlie’s public key hash. If the determination is positive, that is, if Charlie is indeed the next recipient, then the unlocking of Tx5’s first output 142 by the unlocking script of Tx6’s first input 148 succeeds. One possible way of having Tx6’s unlocking script examine the content of Tx6 146 itself is to use the pseudo-OP code “OP PUSHTX ” Tx6 146 also contains a second input 150 which contains an unlocking script that unlocks the second output 128 of Tx3 122, i.e., releases the latch e.g. unlocks “Bolt^Bob” The successful mining of Tx6 146, and thus the success of transmittal of control of the token from Bob to Charlie, is contingent on both processing the second input 134 of Tx4 (releasing the latch / bolt attributed to Alice) and the unlocking of the first output 142 of Tx5 138 being successful. As the unlocking script of Tx6’s second input and the locking script of Tx3’s second output are executed together, or in other words, as the latch is released e.g. "BoltBob" is consumed, its outpoint is confirmed to be included in the verified scriptContext / txPreimage via a full rebuild or inspection of Txl which is performed in the neighbouring token script shown at step S218. During a rebuild, or inspection, the protocol determines a comparison of the TxID on blockchain with the calculated TxID in scriptContexts.hashPrevouts, which determines that there as a ‘bolt’ in Tx3 and / or that Tx3 existed. During the rebuild, the transaction ID TxID3 of Tx3 122 is calculated and is compared to the TxID of the transaction as stored on the blockchain, as shown at decision step D222. If the calculated TxID3 and the stored TxID do not match, Tx6 146 is rejected, that is, not mined, and transmittal of the token from Bob to Charlie fails (S224). If the calculated TxID3 and the stored TxID match, Tx6 146 is mined and transmittal of the token from Bob to Charlie succeeds (S226). Notably, first part of the latch mechanism applied using latch-script in the output of Tx3 e.g. “BoltBob” 128 is consiuned using unlatch-script on the input 150 of Tx6 146 and the latch is released enabling the successful transmittal of control of the token from Bob to another entity. It is to be noted that another latch output is applied using latch-script in the output of Tx5 i.e. a latch is attributed to Charlie e.g. “Bolt^Charlie” 144. The group of transactions including Tx5 138 and Tx6 146, created by Bob, have enabled the secure transmittal of the token. Subsequent transmittal of control of the token follows mutatis mutandis the pattern established by the creation, submission to the blockchain, and mining of groups of transactions Tx3 and Tx4, and Tx5 and Tx6. The pattern continues as illustrated Figure 3(d). Latch: commitment &exchange The group of transactions created, respectively, by Alice, Bob and Charlie in Figure 3(a) to 6 included two transactions. Further transactions can be included in the group, for example funding transactions that are made to add an amount of cryptocurrency to a token’s value for paying miner’s fees. One of the two transactions were a commitment transaction e.g. Tx3, Tx5 and Tx7, in which the first entity commits to assigning the blockchain token to another entity. The other transaction e.g. Tx4, Tx6 or Tx8 was an exchange transaction, in which the first entity assigns the blockchain token to the another entity. The commitment transaction can include the latch script, and the exchange transaction can include the unlatch-script. Processing the latch-script imposes conditions upon the transfer of the blockchain token in a subsequent blockchain transaction or group of transactions; and / or processing the unlatch-script conditionally satisfies conditions imposed, in a preceding blockchain transaction or group, upon the transfer of the blockchain token. Additionally or alternatively to the latch-script and unlatch-script, the blockchain transaction affecting the blockchain token transfer, or group of blockchain token transactions, can include at least one of: verification-script configured to determine the presence of a latch mechanism; and / or push-script configured to enforce that a latch mechanism is processed, at least in part, on the input of a subsequent transaction. The verification-script functions to determine whether a latch mechanism is present, otherwise the token is deemed invalid. The push-script ensures that a latch mechanism is included on the input script of at least one transaction implementing the token transfer. Inclusion of the push-script can be enforced by pushing a transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig. By including the verification-script and / or the push-script then an inherent obligation to use the latch mechanism is imposed upon entities intending to make valid token transfers. The absence of a latch mechanism and / or failure to satisfy a condition and release a restriction indicates to a miner processing the transaction, or a potential recipient of the token, that the token is invalid. The blockcham transaction effecting transfer, or group of transactions, is one of a chain of transactions. Each transaction includes, at least in part, the latch mechanism. Each latch mechanism, or part thereof, enables the validity of the blockchain token back to Genesis to be determined. Overall, therefore, after initiation of the latch mechanism the transfer of the blockchain token to the another entity is conditional upon processing the script as taught herein, which includes at least one of: processing the latch-script, which defines a base step that requires verification that a condition is true in a subsequent blockchain transaction or group; processing the unlatch script, which defines an inductive step that provides verification that tire condition is true in a preceding transaction; processing verification-script to determine whether a latch mechanism is present within the ancestral or linked transaction's token and / or latch output scripts; and processing the push-script to ensure a latch mechanism is used in a subsequent token transaction. Latch transfer - single transaction - overview The method herein can be implemented by an entity within a group of transactions, as per Figures 3(a) to 5, wherein the application of a latch, using latch-script, and release of the latch to validate the token transfer, using unlatch-script, are in separate transactions. Alternatively, the application of a latch, using latch-script, and release of the latch to validate the token transfer, using unlatch-script, can be implemented by an entity in single transaction, as will be described with reference to Figures 6(a) to 8. Implementing the protocol in a single transaction improves the efficiency and reliability of a token transfer. A comparison of Figures 3(a) to 5 and Figures 6(a) to 8 illustrates that token transfer using a single transaction requires fewer transactions. In Figure 6(a) to 8, a blockchain transaction is used to process a blockchain token in a transfer of the blockchain token from a first entity to another entity. The process can additionally or alternatively include at least one of assigning, splitting and merging digital assets represented by the token. The method includes at least one of using, processing and / or generating the latch mechanism as described herein, which includes an unlatch-script and a latch-script, said unlatch-script and said latch script being part of the latch mechanism configured to control transfer of the blockchain token to the another entity. The method is illustrated showing that each entity uses a single transaction to transfer a blockchain token between entities. The entities in the examples are labelled George (G), Alice (A), Bob (B) and Charlie (C), and the subtext letter indicates to whom a token or a latch is attributed. George is typically a creator, authority or manager of the token ledger and it is in his interest that the protocol as taught herein is established securely and operates efficiently. In Figure 6(a) a blockchain token is created at TxO e.g. by George and assigned to George. In Txl, George creates a transaction using his token (Token. ;) as an input and in the output he: assigns the token to himself; and creates a second output, which is a latch of a latching mechanism (LatchA) that is attributed to Alice, to whom he intends to assign the token. As described above, George, or any other entity, can implement the latch mechanism and apply it to a token transfer for any given transaction, or even all subsequent transactions. To be clear, George adds latch-script in Txl, which is configured to apply a subsequent restriction on the ability of Alice to use the blockchain token. The restriction is configured to at least one of: restrict the ability to assign the token in a subsequent blockchain transaction; place a condition on Alice to prove the validity of the token; place a condition on Alice to process the latch mechanism using the unlatch script to show and / or determine tire validity of the token, said unlatch-script configured to release a preceding restriction; and oblige any recipient of the token to apply a latch-script thereto, such that the cycle perpetuates. Rather than first assigning the token to himself, and then assigning the token to Alice, George directly assigns the token to Alice in the output of Txl, as indicated by the change in subscript from ‘G’ to ‘A’. Because George created the inaugural latching mechanism there is no preceding latch having conditions or requirements to fulfil. Figure 6(b) includes Txl from Figure 3(a) for clarity. Alice wishes to transfer the token to Bob and compiles a single transactions for broadcast on the blockchain network. In Tx2, Alice: initially releases the LatchA applied by George in Txl, by running unlatch-script that satisfies the protocol e.g. conditions are met that fulfil the requirements of the protocol; then Alice assigns the token to Bob while creating a new latch for Bob (LatchB) that places a restriction on Bob’s ability to transfer the token when he receives it. Unlatching i.e. releasing the restriction involves processing, at least in part, the original latch script (LatchA) in Txl, as indicated by the double-lined arrow extending from Latch a in Tx2 to Txl. Figure 3(c) includes Tx2 from Figure 3(b) for clarity. Bob wishes to transfer the token to Charlie and compiles a single transaction for broadcast on the blockchain network. Before Bob can transfer the token to Charlie in Tx3 the restrictions placed on the ability to transfer the token must be released. George placed these restrictions, which permeated through Tx2 when Alice created the latch for Bob i.e. LatchB. Therefore, restrictions have been pushed through the transactions and now also applies to Bob. Bob, therefore, must process the unlatch-script of the latch mechanism on the input of Tx3 before a valid transfer of the token can be made to Charlie, which involves processing, at least in part, the latch script (Latch) on the output of Tx2, as indicated by the double-lined arrow extending from LatchB in Tx3 to Tx2. With the latch released, Bob assigns the token to Charlie on the output of Tx3, while also creating a new latch for Charlie (Latchc) that places a restriction on Charlie’s ability to transfer the token he ’s received. Figure 6(d) includes Tx3 from Figure 6(c) for clarity. Charlie wishes to transfer the token to Dave and compiles a single transaction for broadcast on the blockchain network. In Tx4, Charlie assigns the token to Dave while creating a new latch for Dave (LatchD) that places a restriction on Dave’s ability to transfer the token when he receives it. Before Charlie can transfer the token to Dave in Tx4 the restrictions placed on Charlie to have the ability to transfer the token must be released. George placed these restrictions, which permeated through Tx2 and Tx3 when a new latch was created for the recipient of the token -therefore, the protocol requirement for a latch mechanism has been pushed through the transactions, and Charlie is the latest in the series of transaction that has to release the latch. Charlie, therefore, must process the unlatch script of the latch mechanism on the input of Tx4 before a valid transfer of the token can be made to Dave, which involves processing, at least in part, the latch script (Latchc) in Tx3, as indicated by the double-lined arrow extending from Latchc in Tx4 to Tx3. As per Figure 3(e), a latch mechanism can be applied to a single instance of a blockchain token transfer. Figure 6(e) shows transactions TxO to Tx4 of Figures 6(a) to 6(d), as described herein, except that a latch mechanism, at least in part, has only been applied to the transfer of the token between Alice and Bob. In Tx2 Alice creates a latch and associates it with the token, such that the latch is now in Bob’s control. Before Bob can transfer the token he must process the latch using unlatch script in order for the token to be valid. Additionally or alternatively, Alice could apply a latch to the token that would require each subsequent transaction to implement and use a latch mechanism, as per George’s actions in Txl of Figure 6(a). Latch mechanism - single transaction - detail Figures 6(a) to 8 can use the methods taught herein, and in particular use the techniques and features described in relation to Figures 3(a) to 5, although fewer transactions are now required in the transfers. To be clear, aspects of the example in Figures 3(a) to 5 can be applied to the teaching of Figures 6(a) to 8. With reference to Figures 7 and 8, another example of the invention will now be described. The embodiment comprises a method 400, stages of which are carried out by actors George, Alice, Bob, Charlie, and a miner. At step 402, George mints a token by constructing and submitting to the blockchain for mining a transaction 302, denoted TxOO. TxOO, which may be referred to as a “genesis” transaction, contains a funding input 304, which provides an amount of cryptocurrency, and an output 306, which contains a locking script locking the output, and thus the control of the token, to George. The token and / or the latch mechanism contain the rules of a protocol which governs transmittal of the token. The protocol rules include conditions that control transmittal of the token. According to the protocol rules, for George to transmit the token onwards to a new entity, who in this example is called Alice, he must construct and submit at least one transaction to the blockchain, as shown at step S404. A first transaction, 308, is denoted Txl2. Txl2 308 contains an input 310 which contains an unlocking script that unlocks the output of TxOO 302. Txl2 308 also contains at least two outputs. A first output 312 contains a script which locks the output 312, and thus control of the token, to Alice. A second output 314 of Txl 2 308 contains a locking script locking control of that output to Alice, that is, to the same recipient of the first output 312. For shorthand purposes, this second output 114 will be referred to as ‘BoltAlice’. As described previously, the ‘bolt’ is part of the latch mechanism, and the term ‘bolt’ has been used to indicate that the output is secured, or otherwise locked, and just like a ‘latch’ it can be subsequently released. After successfill mining of Tx 12, Alice has control of both the first output 312 of Txl2 308, i.e., the token, and the second output of Txl2 308, i.e., the latch e.g. Bolt Alice output. Alice wants to transmit control of the token to another entity, namely Bob. To effect this transmittal, the protocol whose rules are contained in and propagated by the token requires Alice to submit at least one transaction in sequence to the blockchain, as shown at step S408. One of these transactions is denoted Tx34 322. Tx34 322 contains a first input 324 which contains an unlocking script that unlocks the output 312 of Txl2 308. Tx34 also contains a second input 325 which unlocks the second output 314 of Txl2 308, i.e. unlatching-script releases the latch e.g. unlocks “Bolt^Alice” The successfill mining of Tx34 322, and thus the success of transmittal of control of the token from Alice to Bob, is contingent on both releasing the latch and the unlocking of the first output 312 of Txl2 308 being successful. As the unlocking script of Tx34’s second input and the locking script of Txl2’s second output are executed together, or in other words, as the unlatch-script is processes and “BoltAlice” is consumed, a full rebuild or inspection of Txl2 is performed, as shown at step S408. During the rebuild e.g. execution of the protocol scripts, the transaction ID TxlD 12 of Tx 12 308 is calculated and is compared to the TxlD of the transaction as stored on the blockchain, as shown at decision step D412. If the calculated TxlD 12 and the stored TxlD do not match, Tx34 322 is rejected, that is, not mined, and transmittal of the token from Alice to Bob fails (S414). If the calculated TxID12 and the stored TxlD match, Tx34 322 is mined and transmittal of the token from Alice to Bob succeeds (S416). Notably, the latch attributed to Alice e.g. output “BoltAlice” 314 is consumed in the successful transmittal of control of the token from Alice to another entity. Tx34 322 also contains at least two outputs. A first output 326 contains a script which locks the output 326, and thus control of the token, to Bob. A second output 328 of Tx34 322 contains a locking script locking control of that output 328 to Bob, that is, to the same recipient of the first output 326. This second output 128 i.e. latching control of the token to Bob e.g. “BoltBob” 328, is created during the process of constructing the at least one transaction necessary for the transmittal (Tx34 322). Bob wants to transmit control of the token to another recipient, Charlie. To effect this transmittal, the protocol whose rules are contained in and propagated by the token requires Bob to submit at least one transaction to the blockchain, as shown at step S418. One of these transactions is denoted Tx56 338. Tx56 338 contains a first input 340 which contains an unlocking script that unlocks the first output 326 of Tx34 322. Tx56 also contains a second input 341 which unlocks the second output 328 of Tx34 322, i.e. unlatches the preceding latch applied in output 328 e.g. unlocks ‘"Bolt Bob”. The successful mining of Tx56 338, and thus the success of transmittal of control of the token from Bob to Charlie, is contingent on both releasing the latch and the unlocking of the first output 326 of Tx34 322 being successful. As the unlocking script of Tx56’s second input and the locking script of Tx34’s second output are executed together, or in other words, as the latch is released e.g. '‘Bolt Bob” is consumed, a full rebuild or inspection of Tx34 is performed, as shown at step S418. During the rebuild, the transaction ID TxID34 of Tx34 322 is calculated and is compared to the TxlD of the transaction as stored on the blockchain, as shown at decision step D422. If the calculated TxID34 and the stored TxlD do not match, Tx56 338 is rejected, that is, not mined, and transmittal of the token from Bob to Charlie fails (S424). If the calculated TxID34 and the stored TxID match, Tx56 338 is mined and transmittal of the token from Bob to Charlie succeeds (S426). Notably, output “BoltBob” 328 is consumed in the successful transmittal of control of the token from Bob to another entity. Tx56 338 also contains at least two outputs. A first output 342 contains a script which locks the output 342, and thus control of the token, to Charlie. A second output 344 of Tx56 338 contains latch-scrip that locks control of the latch e.g. “Bolt^Charlie” 344 to the named recipient i.e. Charlie. Creating the latch can be necessary for the transmittal (Tx56 338). Subsequent transmittal of control of the token follows mutatis mutandis the pattern established by the creation, submission to the blockchain, and mining of transactions Tx34 and Tx56. Latch - inductive proof In light of the latch mechanism i.e. the creation of a latch, and subsequent release of the latch spanning the transactions of the entities involved in the assignment of the blockchain token , then an inductive proof of the validity of a token can be determined. Hie latch mechanism either spans between two transactions e.g. Figure 6(c) or between two groups of transactions e.g. Figure 3(c), as described above. To be clear, an inductive proof of the validity can be determined because the transaction, or group of transactions, broadcast by an entity making a transfer use: unlatch-script, which is processed to release a restriction imposed on the entity in a preceding transaction; and latch-script, which applies a subsequent restriction to a transfer in a subsequent blockchain transaction. The latch mechanism, therefore, enforces a relationship with the preceding and subsequent transactions that transfer the blockchain token. In any one transaction, or group of transactions, making a transfer there is one latch mechanism in play, while different parts of the latch mechanism are attributed to different entities. For example, if Bob wishes to transfer a token to Charlie, then (i) Bob must process unlatch-script such that a previous latch e.g. a bolt is deactivated / unlocked / consumed / released, which was attributed to Bob by Alice, requires a set of conditions to be met for token transfer to occur e.g. that there is a successful assessment / inspection / ancestral transactional rebuild of the transaction in which the previous latch was created, and (ii) Bob must process latch-script such that a new bolt / latch is activated / locked / created and attributed to Charlie, who is the intended token recipient, which sets a future condition upon Charlie when making a subsequent transaction, just like the imposition Alice placed on Bob previously. The combination of the latch-script and unlatch-script of the latch mechanism that perpetuates through the chain of transfer of the blockchain token establishes an inductive proof of the validity of the token because each new latch is the “basis” and the associated “unlatch” is the step of the inductive proof. In other words, in any one transaction, or group of transactions, the two parts of a latch mechanism exist -an unlatch script, which is required to release the restriction set in the preceding transaction(s), and a latch script to place a restriction on a subsequent transfer. The latch mechanism and, therefore, the requirements for inductive proof were embedded upon the token in its first transfer e.g. conception, during the transfer and / or minting by George. The initial latch applied to Alice, using latch-script, functions as a base step, or ‘basis’, of the proof that is imposed upon the ability to transfer the token from the point of the token’s creation, or genesis. The imposition of the latch upon the token transfer can be achieved, by way of example, by embedding the latch mechanism into the token and / or initial latch script e.g. as created by George at Txl, and requires the unlatch script and the token unlocking script to be processed together before a latch can be released. Additionally or alternatively, the token can require: the presence of a latch mechanism in an exchange transaction, or part thereof, in order to be deemed valid; the presence of a latch mechanism in an exchange transaction, or part thereof, in order to be deemed valid; the inclusion of latch-script that attributes a latch to the entity that receives the token; and the successful processing of unlatch-script, which releases a restriction e.g. by satisfying a condition, placed upon the entity transferring the token by the preceding entity. By way of example, the compulsory application of a latch mechanism can be pushed through a transaction using push script and / or a Bitcoin operation code. In other words, script that use signature messages e.g. ECDSA signatures to access and enforce transactional states and other conditions in Bitcoin script. The latch mechanism requires the entity that is transferring a token to push a transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig. In one example OP_PUSH_TX can be used: https: / / wiki.bitcoinsv.io / index.php / OP PUSH TX. In the examples described herein: the application of a latch-script, which must be present (as determined in tire first transaction e.g. the genesis transfer from George to Alice, provides the ‘base’ of the inductive proof; and the processing of the unlatch-script, which verifies that tire latch was applied correctly and / or releases restrictions when conditions are met e.g. by rebuilding and / or inspecting the transaction that included the applied latch output, functions as the ‘step’ of the inductive proof. Latch creation (latch) and release (unlatch) cycle - Restrictions / Requirements / Conditions The examples herein describe a transaction including a latch mechanism, which includes an unlatch-script and a latch script. In a token transfer the entity having control of the token will also have had a latch attributed to said entity and / or the token, and said latch must be released in order for a valid transfer to occur. Similarly, the entity to whom the token is being transferred will have a latch attributed to them which must be released, in turn, when they wish to transfer the token. The latch mechanism, therefore, establishes a creation and release cycle in which i.e. a latch must be created and conditions have to be met in order for a latch and its associated restrictions to be released. Conditions, or the requirements, of releasing a latch can be set in tire latch-script, which places a restriction on the ability to transfer a valid token. For example, if the conditions are not met, then the restriction is such that the token and / or the token transaction is deemed invalid. In the examples provided, George initiates the protocol as taught herein by configuring the inaugural latch script. Additionally or alternatively, the or each token can be configured e.g. by George to require at least one of: a latch mechanism, or part thereof, to be present in the transaction; that an unlatch-script is processed, and confirms conditions have been met; and the token has an associated latch mechanism attributed thereto - otherwise the token and / or the transaction is deemed invalid. While the latch mechanism sets the requirements to meet the conditions in order to release the restrictions, the unlatch-script determines whether conditions have been met. The unlatch-script and the latch-scrip of the latch mechanism are, respectively, part of the input e.g. scriptSig and output scriptPubKey of the transaction and, therefore, are processed by a miner who receives the broadcast transaction. Unless the conditions have been met then the miner will determine that the transaction, and therefore the token, are invalid. Determining a valid transaction includes processing the combination of the input of the new transaction e.g. scriptSig which is followed by the output of the previous transaction e.g. scriptPubKey -which is then processed as one computer program and outputs true or false. If the conditions have been met, and the correct signatures provided, the outcome will be TRUE. Unlatch-script is run to release restrictions, and determines whether at least one of the following requirements and / or conditions have been met: Simultaneous unlocking of the blockchain token and the latch script e.g. by determining one or more references between the outputs that applied the latch and the associated restrictions, which can be achieved by directly referencing known UTXO outpoints e.g. derived from common ancestry, and introduced at runtime e.g. as an input. A latch mechanism, or part thereof, is present in tire exchange transaction and / or group of transactions exchanging the token. A latch, or part thereof, has been pushed through on the output of a transaction such that it is part of the subsequent transaction, or group of transactions e.g. an obligation to create a latch script for the next recipient on output of a transaction is ‘pushed’ through. Unlatching requires the token script and tire unlatch-script to be processed together e.g. the token and the latch are spent together and requires that the transaction in which the latch was applied to be rebuilt in order to determine its TXID, which is a double SHA-256 hash of the fully serialised transaction. It is then determined whether this matches the TXID on chain. If the TXIDs do not match then the transaction is invalid and the token transfer is invalid. Determining whether the transaction in which unlatching occurs contains an input referencing at least one of the outpoints of the transaction that applied the latch. At least one ancestral variable is carried forward in a transaction, wherein an ancestral variable is a value derived from a previous transaction, or group of transactions. The ancestral variables can be of the computational type and can be used as data slices in the full ancestral transaction rebuild and thus identity value calculation and are listed as follows: o ancestralNVersion, o ancestralTxInsVi, o ancestralFundingSerialisedScriptSeq, o aiicestrallnputOutpoint, o ancestrallnputScriptLen, o ancestrallnputContextLengthVi, o anccstralScriptCodcVi. o ancestralScriptCodeData, o ancestral InputSig, o ancestrallnputPubKey, o ancestral InputBeneficiaryPubKey Hash. o ancestrallnputFundingOutpointSequence, o ancestrallnputChangeSerialisedOutput, o ancestrallnputNSequence, o ancestralTxOutsVi, o ancestralNLocktime. The locking script arguments and their computational types can include at least one of: genesisOutpoint (bytes), grandparentOutpoint (bytes). parentOutpoint (bytes), pubKeyHash (bytes), hasLatch (int), beneficiaryCommitment (bytes). Each of these variables have a distinct purpose throughout each stage of the token lifecycle. For example, the ’genesisOutpoint' can be set to an array of 36 null bytes when the issuer mints the token into existence. Then, once the first transaction of the token can be made the actual genesis transaction outpoint can be stored in this variable in perpetuity as the “pointer to origin” previously mentioned. The variables ‘grandparentOutpoint’ and ‘parentOutpoint’ can also be initialised with 36 byte null values in the genesis transaction output locking script. These variables keep track of the chain of transaction outpoint history and enforcement of such will also be described later in this application. A standard Bitcoin transaction ‘pubKeyHash’ variable can be used to control ownership of the unspent token output, and an integer value ‘has Latch’ can be used to distinguish whether or not the token exists beside a protocol ‘ Latch’ output or not (with the value 1 equal to true, and 0 equal to false). If hasLatch is true, that is, equal to 1, it means the transaction containing the token output can be one of the declaration transactions or Latch transactions mentioned earlier. Finally, the last variable ‘beneficiaryCommitment’ can be used to contain the declaration of which pubKeyHash the token must travel to next. This variable operates in sort of conjunction with ‘has Latch’. Example - latch and release cycle In each of the examples herein a latch mechanism, or part thereof, is processed during the transfer of a token. Examples focus upon the actions of: the entity transferring the token e.g. Alice; the recipient of the token e.g. Bob; and the miner who validates the transactions and / or the token e.g receives the or each transaction broadcast on the blockchain network to record the transactions on the blockchain. The latch mechanism has two stages. The first stage is the latching stage, which can employ latching script, wherein an interdependency e.g. interlock can be created between the token to be transferred and the latching mechanism. The latching stage applies conditions to the recipient, which must be met before they can make a valid transfer of the token. The latch functions like a lock upon the token. Components of the latch mechanism can be implemented in an output of a transaction e.g. its own output. Additionally or alternatively, components of the latch mechanism can be included in the token output. The term latch has been used to describe the mechanism because it effectively locks control of the token to a recipient who is to receive the token. The key to unlatching e.g. unlocking the applied latch is for the applied conditions to be met. Another stage is the unlatching stage, or release stage, which can employ unlatching script wherein the interdependency e.g. interlock is released. When the unlock script is processed it is determined w hether the applied conditions have been met - if met, the result is, for example, TRUE. When met, tire recipient can make a subsequent valid transfer of the token. The actions taken by the entities are represented by the boxes having hashed lines in Figures 3 and 6, while in Figures 4, 5, 7 and 8 an indication is provided to show which entity e.g. George (G), Alice (A) or Bob (B) is submitting a transaction for broadcast and / or performing steps of the method. The boxes and / or actions contain at least one transaction (Figures 6(a) to 8), or at least two transactions (Figure 3(a) to 5). To be clear, the entity transferring the token can create and broadcast the transactions in the hashed-line box, a recipient can process those transactions to validate the token transfer, and a miner receives and validates those transactions and only includes them in a block if valid. A latch mechanism can be applied once, wherein an entity' e.g. sender, receiver or miner only processes part of the latch mechanism. With reference to the examples herein: George establishes a latch w hen transferring a token to Alice, and because George created the token then there is no preceding latch mechanism or conditions to meet (see Figure 3(a) and Figure 6(a)); and Alice may configure a single-use latch when transferring a token to Bob, such th at Alice has no conditions to meet, yet conditions are imposed upon Bob (see Figures 3(e) and 6(e)). When applied once, an entity uses only part of the latch mechanism e.g. George and Alice have used latching script to apply a latch and conditions, while Bob uses unlatching script to determine that conditions have been met. The latch mechanism, and the interlock relationship between transactions is indicated by a double-line in Figures 3 and 6, and a hashed-line in Figures 4 and 7. It is to be noted that Figures 3(e) and 6(e) show only one interlock. The latch mechanism, however, can be created and applied to all subsequent transactions. When created e.g. by George, the token and / or the initial latch of the latch mechanism include script that pushes forward e.g. using an OP PUSHTX op-code, data and script that impose the use of a latch mechanism thereafter, such that use of the latch mechanism is perpetuated through the chain of token transfers. This should be clear from the teaching herein and the double-line in Figures 3 and 6, and a hashed-line in Figures 4 and 7. This technique affords the transactor the ability to enforce advanced unlocking requirements including for specific outpoint outputs(s) to be spent / unlocked alongside one another, or even for the transaction’s new ly created outputs to conform to be precise specific ty pes of locking script. When a latch mechanism is applied to all subsequent transactions the actions of an entity include e.g. with reference to Figures 3(a) to (d) and Figures 6(a) to (d) two stages of the latch mechanism. With reference to Figure 3(b), at least, a preceding latch was applied to Alice in Txl, wherein she was designated as having control of the token, although she did not have possession of the token until Tx2. With control of the token at Tx3, Alice creates a latch to establish an interlock for Bob before transferring the token to Bob, wherein Bob has control of the token but not possession of the token. Before Alice can transfer the token to Bob she must process unlatch script that releases the preceding latch applied in Txl. During unlatching e.g. processing unlatching script, the entity in control of the token must demonstrate that conditions have been met before a valid transfer to another entity can be determined. The script on the input of Tx4 e.g. the scriptSig is processed before it is determined that the token output of Tx3 e.g. scriptPubKey can be assigned to Bob in Tx4. However, the token is interdependent on the latch attributed to Alice and, therefore, Alice must process the token and the unlatch script on the input of Tx4 before a valid transfer to Bob can be made. On the input of Tx4, the requirements for a known token transfer can be processed. Additionally, on the input of Tx4, a condition must be met to release the latch attributed to Alice, which includes processing data associated with Txl - as indicated by the doublelined arrow extending from Tx4 to Txl. The conditions to be met are not limited to the application of a latch using the latch mechanism, and release of tire latch. Thus far, the latch mechanism applies conditions to the transfer of the token, which can be embedded in a dedicated latch output, embedded in the token or distributed between a latch output and a token output. In each case, latch script of the latch mechanism is applied to the token to function as an interlock, and lock the ability to make a valid subsequent transfer of the token to another entity e.g. the subsequent transfer of the token is dependent on the latch mechanism. Determining that the conditions have been met is analogous to building a key to release said lock, which can involve processing data from at least one previous transaction e.g. the transaction in which the latch was created. Processing the unlatch script to determine whether the conditions are met, and enables the transaction to be determined as valid. Data processed to determine whether conditions are met include: Inspection: o was a preceding latch and / or token present, and applied to the token assignor e.g. Alice in Txl; o was a preceding latch created and applied to the token assignor in the same transaction in which the assignor received the token e.g. the output of Txl contained both a latch applied to Alice and the token was assigned to Alice; o have the conditions of a smart contract specified in the latch mechanism, using the latch script, been met; o has an oracle, who was tasked to monitor fulfilment of a condition, indicated that the condition has been met;... Rebuilding: o Using the data available to the entity unlatching e.g. Alice in Tx4, the transaction m which the latch was applied can be rebuilt and the TxID determined therefrom, which can then be compared to the TxID on-chain. The latch applied by Alice in Tx3 not only applies a lock, but the latch and / or a portion of the transaction in which it was applied becomes part of the key. Determination that a condition has been met relies, therefore, on the data associated with a preceding transaction e.g. release of the latch on the input of Tx4 depends on the data from the output of Txl. Because the transaction that created the latch has been broadcast and can be identified and verified on-chain, counterfeiting and double-spending is inhibited. To be clear, with reference to Alice, she applies a latch to the token in Tx3 imposing conditions upon Bob before he can make a subsequent transfer to Charlie in Tx6, yet she must also release the latch that was applied to her in Txl by processing unlatch script in Tx4, wherein said unlatch script, contained in some configuration across the Tx4 token input scripts, includes conditions that require an inspection and / or rebuild of Txl. Transfer / Update The examples presented in the Figures involve the transfer of a token from, for example, Alice to Bob. In Figure 3(b), Alice uses transactions Tx3 and Tx4 to make a transfer using a latch mechanism, wherein in Tx3 a latch is created for Bob (LatchB), and in Tx4 Alice releases the latch (LatchA) applied by George, to Alice, in Txl. Similarly, in Figure 6(b), Alice uses transactions Tx2 to both to make a transfer using a latch mechanism, wherein in Tx2 a latch is created for Bob (LatchB) and Alice releases the latch (LatchA) applied by George, to Alice, in Txl. Assigning and / or transferring a token is analogous to updating a token. While the token transactions taught herein can effect a transfer from one entity to another entity, they can, for the avoidance of doubt, additionally or alternatively to transferring a token, use a latch mechanism to manage an update to a token. An update to a token can be effected without a transfer taking place. A transaction and latch mechanism can be used to update at least one the status of assets or resources. Updates can be tracked and / or managed using one or more blockchain transactions in which token-related outputs, representing tokens, function to determine the status of an asset. The status can, for example, indicate at least one of ownership, access rights to a secured asset, data, instruction, state, operation, configuration and value of an asset or resource, such as an amount of token-units. In particular, the methods herein additionally or alternatively can operate the token like a state machine. In the ‘transfer’ examples, a latch mechanism includes attributing a latch to another entity that is to receive control of the token, and said latch must be released before the another entity' can make a subsequent transfer. Similarly, additionally or alternatively, a latch mechanism can include attributing a latch to a status update of tire token, and said latch must be released before the status can be updated again in a subsequent transaction. Drawing an analogy with the ‘transfer’ examples, a latch can be attributed a status level e.g. an integer value e.g. level N, which can increase from level 0 upwards. Therefore, the entities represented in Figure 3 can be substituted with an equivalent status: George represents level 0, Alice represents level 1. Bob represents level 2 and Charlie represents level 3 and so on. Therefore, in Figure 3(b), an entity managing the status of the token, such as a machine e.g. a digital wallet, oracle or the like, can update the token from level 1 using transactions Tx3 and Tx4 to make a transfer using a latch mechanism, wherein in Tx3 a latch is created for Level 2 (Latch2), and in Tx4 the ability to update from level 1 is enables by releasing the latch (Latch ) applied when the token status was level 0, in Txl. Similarly, in Figure 6(b), updating the status from level 1 requires the use of transaction Tx2 to update the status using a latch mechanism, wherein in Tx2 a latch is created for level 2 (Latch2) and a restriction upon updating the status comprises releasing the latch (Latchi) applied when the token status was level 0, in Txl. The methods herein can be used to manage a stateful contract, wherein there is no exchange of assets, but where there is a process that requires permission from an external authority to proceed via updating the status of a token e.g. an Oracle manages and / or oversees the contract management. The method herein, therefore, can additionally or alternatively operate as a state machine e.g. finite state machine such that the latch mechanism can be used for transferring and / or updating the token. In this way, a token can be updated without being transferred. By way of non-limiting example, a token can be used to determine the status of streetlights in a given neighbourhood, with a status of ‘1’ representing ‘on’ and ‘0’ representing ‘off. The hardware that switches the lights on and off is respondent to the status of the token, which can be spent from one state into another to toggle the streetlights on or off. The status of the token can be determined, for example, by a smart contract. A latch applied to the token can require predetermined conditions to be met before the token will change state and switch the streetlights on or off. The conditions can include, for example, that at least m of n e.g. at least 6 of the 24 light sensors distributed around the neighbourhood indicate a change of light levels that requires the streetlights to be switch on or off. The conditions can include an override function enabled by signing conditions, such that the latch can be signed to force the streetlights on or off. In light of the teaching herein, the methods and latches can be applied to machines and control systems. Example device The invention can be implemented on a device. An example of a device having a controller and a control system is illustrated in Figure 9. A device 100 can be scalable in size and across different locations to implement an aspect or method of the invention described herein. The device can also be representative of an input device such as a sensor or an output device such as an actuator. The device 100 includes a bus 102, at least one processor 104, at least one communication port 106, a main memory 108 and / or a removable storage media 110, a read only memory 112 and a random access memory 114. The components of device 100 can be configured across two (2) or more devices, or the components can reside in a single device 10. The device can also include a battery 116. The port 106 can be complimented by input means 118 and output connection 120. The processor 104 can be any such device such as (but not limited to) an Intel(R), AMD(R) or ARM processor. The processor may be specifically dedicated to the device. The port 106 can be a wired connection, such as an RS-232 connection, or a Bluetooth connection or any such wireless connection. Hie port can be configured to communicate on a network such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the device 100 connects. The read only memory 112 can store instructions for the processor 104. The bus 102 communicably couples the processor 104 with the other memory 110, 112, 114, 108 and port 106, as well as the input and output connections 118, 120. The bus can be a PCI / PCI-X or SCSI based system bus depending on the storage devices used, for example. Removable memory 110 can be any kind of external hard-drives, floppy drives, flash drives, for example. Hie device and components therein are provided by way of example and does not limit the scope of the invention. The processor 104 can implement the methods described herein. The processor 104 can be configured to retrieve and / or receive information from a remote server or other device. The device 100 can also include an embedded system 122 and contain a secure module 124 for holding associated private keys. A key store 126 can hold key-pairs assigned to transactions of the system. A device can include a secure mechanism 128 for generating key-pairs for use in signing the UTXO of a token, and the secure mechanism can include a physical unclonable function (PUF). The operational history of the device can be held in a back-up store 128. A local copy 130 of the token transactions associated with the device ledger can be stored on the device. A separate data store 132 can hold at least one of the device identity, authority information, finite-state machine configurations and keypairs of the input devices. The invention can reside in: a computer-based resource e.g. a node or a digital wallet arranged and configured to use or process the method; and a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system to perform said methods. It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative examples without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. Hie word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, ‘"comprises” means “includes or consists of’ and “comprising” means “including or consisting of’. Throughout this specification the word "comprise", or variations such as “includes”, "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. Hie singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. In this document we use the term ‘blockchain’ to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof. As the Bitcoin ledger is the most widely known application of blockchain technology it will be 5 used herein for ease of reference, although it should be noted that the term “Bitcoin” is intended herein to refer to any version or variation that derives from, or is based on, the Bitcoin protocol. Moreover, other non-Bitcoin blockchain implementations have been proposed and developed and alternative blockchain implementations and protocols fall within the scope of the present disclosure. The term “user” may refer herein to a human or a processor-based resource. 10 The skilled person will readily understand that in the art it is usual to refer to spending of cryptocurrency in terms of sending coins from one address / owner to another. However, in reality, no actual “coins” are transferred. Instead, control of ownership is transferred from one script to another. As used herein, phrases “quantity / amount / portion of cryptocurrency”, “non-negative quantity etc of cryptocurrency” and the like are intended to mean zero or more units of a cryptocurrency e.g. >= 0 Satoshi 15 in relation to Bitcoin.

Claims

1. A computer-implemented method comprising:at least one of using, processing and / or generating a blockchain transaction, said blockchain transaction processing a blockchain token in an update of the blockchain token; andat least one of using, processing and / or generatingat least one of an unlatch-script and a latch-script, said unlatch-script and said latch script being part of a latch mechanism configured to control the update of the blockchain token, wherein the latch mechanism comprises:the unlatch-script, which is configured to release a preceding restriction, said preceding restriction applied in a preceding blockchain transaction and configured to restrict the update of the blockchain token; and / orthe latch-script, which is configured to apply a subsequent restriction, said subsequent restriction configured to restrict the ability to update the blockchain token in a subsequent blockchain transaction.

2. The computer-implemented method of claim 1, wherein the latch mechanism is an integral component of the preceding blockchain transaction, the blockchain transaction and the subsequent blockchain transaction.

3. The computer-implemented method of claim 1 or 2, whereinthe unlatch-script is configured as an input to the blockchain transaction and the latch-script is configured on the output of the blockchain transaction.

4. The computer-implemented method of any preceding claim, wherein the latch mechanism comprises (i) a plurality of unlatch-scripts and / or (ii) a plurality of latch-scripts, wherein said unlatch-scripts and / or latch-scripts respectively release and / or apply a plurality of restrictions upon the update of the blockchain token.

5. The computer-implemented method of any preceding claim, wherein only a first entity is able to process the unlatch-script to release a preceding restriction, and / or the latch-script is configured to limit removal of the subsequent restriction to another entity by processing a subsequent unlatch-script.

6. The computer-implemented method of any preceding claim, wherein the method comprises at least one of using, processing and / or generating a group, said group being one of a series of groups of blockchain transactions, said group including the blockchain transaction.

7. The computer-implemented method of claim 5 or 6, wherein tire group of transactions comprises: a commitment transaction, in which the first entity commits to assigning the blockchain token to the another entity; andan exchange transaction, in which the first entity assigns the blockchain token to the another entity.

8. The computer-implemented method of any preceding claim, wherein the commitment transaction includes the latch script, and the exchange transaction includes the unlatch-script.

9. The computer-implemented method of any preceding claim, whereinprocessing the latch-script imposes conditions upon the update of the blockchain token in a subsequent blockchain transaction or group, and / orprocessing the unlatch script conditionally satisfies conditions imposed, in a preceding blockchain transaction or group, upon the update of the blockchain token.

10. The computer-implemented method of any preceding claim, wherein the blockchain transaction includes at least one of:verification-script configured to determine the presence of a latch mechanism; and / or push-script configured to enforce that a latch mechanism is processed, at least in part, as part of a subsequent transaction.

11. The computer-implemented method of any preceding claim, wherein the blockchain transaction is one of a chain of transactions, wherein: each transaction includes, at least in part, the latch mechanism; and each latch mechanism, or part thereof, enables the validity of the blockchain token back to Genesis to be determined.

12. The computer-implemented method of any preceding claim, wherein the update of the blockchain token to the another entity' is conditional upon:processing the latch-script, which defines a base step that requires verification that a condition is true in a subsequent blockchain transaction or group; andprocessing the unlatch script, which defines an inductive step that provides verification that the condition is true in a preceding transaction.

13. The method of any preceding claim, wherein at least one of using, processing and / or generating a blockchain transaction further includes the respective token having at least one of: a quantity of token units (TU); a quantity of token-related cryptocurrency (TRC) associated with the respective token (T); and a record of the blockchain transaction (MTx) and index output of the respective token.

14. The method of any preceding claim, wherein the blockchain transaction further comprises at least one Issuer-related output (I-UTXO) comprising issuance data (IData) associated with the Token Issuer (TI).

15. The method of any preceding claim, wherein the transaction includes authentication information comprises at least one of:the latest outpoint on the ledger of the respective token;a flag indicating the validity of the respective token (T);data that enables the validity of the respective token to be determined; anda signature required to process the respective token in a subsequent transaction, wherein said signature validates and / or controls the ability to update the respective token.

16. The method of any preceding claim, further comprising using, processing and / or generating a subsequent blockcham transaction, said subsequent blockchain transaction comprises a replacement or re-is-sued respective token having the same authentication information as the previous respective token.

17. A computer-implemented method comprising:at least one of using, processing and / or generating a blockchain transaction, said blockchain transaction processing a blockchain token that includes in the output:an inaugural latch mechanism, or part thereof; andan update of the blockchain token; andat least one of using, processing and / or generating a latch-script, said latch script being part of a latch mechanism configured to control the update of the blockchain token.

18. A system comprising: a port configured to receive transactions directly and / or from at least one other node in a blockchain network; and a processor configured to produce, hold and / or maintain a record of at least one of the blockchain transaction, latch mechanism and token of any preceding claim.

19. Computer equipment comprising: memory comprising one or more memory' units; and processing apparatus comprising one or more processing units, wherein the memory' stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 17.

20. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 17.42

Images