Field

This disclosure relates generally to methods and systems for validating a transaction recorded in a block of a blockchain, and in particular a token transaction. More specifically, the invention generally resides in at least one of: a method for establishing a means for validation, a method for providing validation; a method of operating a wallet for determining validation of a transaction; a system for supporting the methods e.g. a node; and a method of operating or managing the system and/or determination of the validation.

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 in the examples used herein. Examples of the disclosure are not limited in this regard and alternative blockchain protocols and implementations fall within the scope of the present disclosure. Although it has gained publicity as a means of transferring cryptocurrency, the wider applicability of blockchain technology is somewhat analogous to the way that the Internet provides an underpinning support layer for many distributed services, communications and data sharing technologies. Bitcoin is referred to in 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.

Examples of blockchain transactions having functional and transparent outputs are known from W02021/250037, which is incorporated by reference herein in its entirety. Figure 1 discloses such an example in which a logical sub-ledger 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. Computer implemented systems and methods for storing, retrieving and communication data via a peer-to-peer network are known from W02020109910A1. Operational use of tokens requires a means for validation. Determining the authenticity of a token can be achieved by determining a relationship with the issuer and/or authority that created the token in a set of transactions at the beginning of a linear transaction history i.e. writechain. If a token has been used in many transactions, typically 100 or more, or 1000 or more, the linear transaction history takes longer to verify. Therefore, a validation process that leads back to genesis can be lengthy for tokens with extensive history.

The invention seeks to address problems with token validation and improve the operational efficiency and lower the computational cost of the determination of token validation. Summary

The invention generally resides in a computer-implemented method comprising: a tracking token, said tracking token including authentication data for validating the respective token (T) related outputs. The tracking token is created from a blockchain transaction (MTx) having a plurality of token- related outputs (T-UTXOs), each of which represents a respective token (T) issued by a Token Issuer (Tl). The tracking token is stored and/or maintained by a system e.g. an oracle or bot, which can be automated. Rather than validating each token by tracing transactions back to the blockchain transaction that created them e.g. minting transaction, a tokens validity can be determined from information held in the tracking token. In other words, the tracking token, which is a blockchain token, functions as a digital asset that is analogous to a machine, or component thereof, that interacts with other machines during its operational use. The tracking token can be an operational component of a ledger of blockchain tokens, which operates to at least one of generate, use and process authentication data for validating the respective tokens in the token ledger.

The tracking token and/or the oracle provide an efficient method or mechanism for determining the validity in fewer computational steps. For example, authentication data can store issuance data, details of the minting transaction and the index of the transaction output containing the token. Moreover, the tracking token and/or the oracle are managed by the issuer of the tokens, or their agent, and act as an authority for verification. The tracking token functions as a 'tracing output' from the point of token creation and provides a source of verification data as if it were a 'bulletin board'. The tracking token functions like a digital register. It is to be noted that a token can have at least one of (i) a record of the tracking token's data such that it can be efficiently sought to determine token validity, and (ii) a record of the minting transaction, and an index of the tracking token such that the tracking token data can be efficiently sought to determine token validity. The tracking token holds data that is required to determine the validity of a token - to be clear, the data therein is retrieved and processed computationally to determine the validity of a token.

While steps can be taken to verify a token from its transaction history the validation data stored in the tracking token can be required to concur, which can inhibit token replication and/or back-to-genesis verification. Overall, trust in the tokens resides with the issuer.

According to one aspect there resides a computer-implemented method comprising: using, processing and/or generating a blockchain transaction having: one or more token-related outputs, each of which represents a respective token issued by a Token Issuer, and comprising a tracking token, said tracking token including authentication data for validating the respective token related outputs.

According to another aspect there resides a computer-implemented method comprising: producing, storing and/or maintaining a tracking token, wherein said tracking token was generated in a blockchain transaction including one or more token-related outputs, each of which represents a respective token issued by a Token Issuer, wherein said tracking token includes authentication data for validating the respective token. Authentication data can include token issuance data, the location of the transaction that created the token, an index of the token output, a Merkle proof that the blockchain transaction that created the token is part of a block, and the block's details are provided. Each token output can include a location and/or link to the tracking token.

Each token output can propagate forward at least one of: data identifying the transaction e.g. minting transaction that created the token e.g. a token within a token ledger; data identifying the tracking token that holds data indicating the status of the token; an index that points to the output of the transaction creating the token in the token ledger; and an index that points to the output of the token status in the tracking token output. The tracking token can determine from the latest token transaction whether such data has been propagated and update the status of the tracking token output corresponding to the token.

According to another aspect there resides a computer-implemented method comprising: compiling a transaction for broadcast on a blockchain, said transaction including a respective token issued by a Token Issuer, said respective token having a corresponding tracking token including authentication data for validating the respective token related outputs; identifying and processing the respective token data associated with the minting transaction of the respective token, and further retrieving validation data for validating the token from the corresponding tracking token; and using the validation data in the transaction. The validation data can function as 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; and 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. The outpoint can be the token's most recent Tx:index, thus defining the location of the respective token. In particular, it is data from the latest transaction e.g. UTXO that is used i.e. the most recent Tx:index. Data can include a Merkle proof, or SPV data, that the token was compiled in the minting transaction.

The Issuer's signature is not limited thereto, the signature functions as a key or a flag that can be provided e.g. by an Issuer or Authority managing or holding responsibility for the token ledger, tracking token and/or the corresponding tokens of the ledger. The signature is a unit of secure data functions to provide a proof that the token is valid and can be used in a subsequent transaction. Additionally or alternatively, this unit of secure data can be a solution to a hash puzzle or a comparable proof mechanism that allows the token to be validated for use in a subsequent transaction. The signature can be provided by the Issuer or Authority responsible for the token ledger - either directly or through an agent e.g. an Oracle. The signature can be provided on an output of the tracking token corresponding to the token to be validated. The signature can be applied each time a transfer of the token is validated by the Issuer e.g. by the Oracle. A signature can be required to validate the token and enable a subsequent transfer. In other words, the tracking token functions to maintain a digital register of the tokens on the ledger and holds data for determining the validity and/or enabling a subsequent token transaction.

An indication, e.g. signature, issued on or on behalf, e.g. by an Oracle, of the Issuer or Authority that a token transfer is valid can be generated automatically for a tracking token. Such an indication can be used by a recipient of a token and used to determine validity. The indication can b determinably derived from the Issuer e.g. Authority e.g. because i) the indicator e.g. signature is derived from the Issuer and ii) the Issuer has checked and produced the signature.

During a token transfer, the subsequent transaction can require a multiple signature input e.g. a signature from the entity transferring the token, and the Issuer's signature that resides in the tracking token. With each transaction, the tracking token can be updated with a new signature e.g. by the Oracle, such that there is a rolling update of the signature that maintains a level of security.

The creation of the tracking token, and it's subsequent operation, which is analogous to a machine, or component thereof, provides a mechanism for the validation of tokens in a ledger that, at least one of: requires the retrieval of fewer information; performing fewer operational and/or computational steps; and adds additional layers of security by utilising signatures of the Issuer and/or Authority, or the agent thereof e.g. an Oracle to validate and/or use enable use of a token in a subsequent transaction.

According to one aspect there resides a computer-implemented method comprising: using, processing and/or generating a blockchain transaction having: one or more token-related outputs, each of which represents a respective token issued by a Token Issuer, and comprising a tracking token, said tracking token including authentication data for validating the respective token related outputs.

According to another aspect there resides a computer-implemented method comprising: producing, storing and/or maintaining a tracking token, wherein said tracking token was generated in a blockchain transaction including one or more token-related outputs, each of which represents a respective token issued by a Token Issuer, wherein said tracking token includes authentication data for validating the respective token. Authentication data can include token issuance data, the location of the transaction that created the token, an index of the token output, a Merkle proof that the blockchain transaction that created the token is part of a block, and the block's details are provided. Each token output can include a location and/or link to the tracking token. Through the data held on the tracking token output e.g. authentication data, the Issuer and/or Authority of the token ledger can endorse changes to the token. Changes to the token can include at least one of: updating the data that is propagated with the token e.g. incorporating additional script before a token transaction can be enacted; adding limitations to the transactions in which the token can be used; updating or otherwise changing the public key associated with the token; requiring additional actions upon the token transfer, such that predetermined conditions must be met or actions performed before a valid transfer can be enacted; re-issuing or otherwise updating the token and/or the underlying cryptocurrency e.g. refreshing the token.

The tracking token can hold a record for the or each token. The record can hold data associated with the issuance of the token and comprise at least one of: minting transaction data; the location of the minting transaction; and the index of the token in the minting transaction. Each token can hold data that includes tracking token data that enables the validity of the token to be authenticated by finding and referring to the tracking token.

According to one aspect there resides a computer-implemented method comprising: using, processing and/or generating a blockchain transaction having: one or more token-related outputs, each of which represents a respective token issued by a Token Issuer, and comprising a tracking token, said tracking token including authentication data for validating the respective token related outputs. In an additional or alternative aspect, there resides a computer-implemented method comprising: using, processing and/or generating a ret blockchain transaction having: one or more token-related outputs, each of which represents a respective token issued by a Token Issuer; and using, processing and/or generating a second blockchain transaction having: and comprising a tracking token, said tracking token including authentication data for validating the respective token related outputs. In one example, a token ledger can be established in stages, wherein the first blockchain transaction establishes a token ledger and the second blockchain transaction establishes a tracking token that functions as a data register for the token ledger, holding data that can be used to validate tokens in said ledger.

In another additional or alternative aspect, there resides a computer-implemented method comprising: producing, storing and/or maintaining a tracking token, wherein said tracking token was generated in second blockchain transaction and includes data associated with one or more token- related outputs created in a first blockchain transaction, each of which represents a respective token issued by a Token Issuer, wherein said tracking token includes authentication data for validating the respective token. In light of the teaching herein, the tracking token can be created (i) as an output from a minting transaction that created a token to be tracked, and/or (ii) in a subsequent minting transaction, said subsequent minting transaction and/or tracking token comprising authentication data for validating the respective token related output(s) in a preceding minting transaction. In this way, a tracking token can be created to retrospectively track and/or authenticate an existing token. The tracking token and the tokens being tracked can be created by the same issuer. The techniques taught herein that enable the tracking token to authenticate a token minted in the same minting transaction token can be applied to the authentication and/or validation of a token that has already been issued. This can be achieved by collating token data and/or validating and/or authenticating token data before including it in the output of a tracking token in a subsequent minting transaction.

The validation or authentication of a token is improved over known techniques. Data for authentication can be achieved through verification of the linear transaction history in combination with data held in the tracking token.

These aspects relate to the creation and subsequent management of a tracking token, said tracking token receiving and/or collecting data associated with each token. The tracking token can hold additional information generated and/or processed by a system e.g. oracle or bot that uses the tracking token. An oracle or bot can use a plurality of tracking tokens. The oracle can manage the output or the tracking token keeping it updated with authentication data. The oracle can hold a collection of blockchain transaction data required to validate a token and/or can dynamically update the output in relation to each token to support validation of a token for inclusion in a token transaction.

The tracking token can function like a payment channel and the oracle can update the payment channel and/or publish information in the payment channel required to validate a token transaction. The payment channel can create a set of false return outputs that each contain data related to the outputs of the respective tokens in the minting or issuance transaction. Use of a payment channel can enable the determination of the validity of a token using the tracking token to be shared with at least one third party. Moreover, using a payment channel can maintain privacy.

In the or each aspect, the respective token can comprise 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. A recipient of the token can use the record of the blockchain transaction (MTx) and index output to identify the tracking token that was output at the same time the token was created, and then seek validation data from the tracking token to authenticate the token.

The blockchain transaction further comprises at least one Issuer-related output (l-UTXO) comprising issuance data (IData) associated with the Token Issuer (Tl). The issuance data and/or minting record associated with the blockchain transaction can be checked to ensure that the token or number of token units transferred is a genuine, authorised token or token unit. Known 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. In this way the blockchain transaction itself can be authenticated.

Further to producing, storing and/or maintaining the tracking token, the methods herein can comprise receiving and/or retrieving token data associated with the or each unspent transaction output (T-UTXO) and/or transaction (Tx) containing said T-UTXO. Receiving and/or retrieving token data can be used to update the tracking token. In particular, the status of one or more tokens can be updated. The tracking token can define a payment channel. The tracking token can be read only. The tracking token can be configured and/or managed by the issuer or their agent via, for example, an oracle. The oracle can publish data for third parties to obtain.

The tracking token can be configured having interlocks comprising at least one of: a sequence number; and a locktime, wherein the tracking token is non-final until the sequence number and/or the locktime exceed a threshold value.

The authentication information can comprise 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; and 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. The latest outpoint can be the token's most recent transactio index, thus defining the location of the respective token.

Signatures can be generated automatically by the oracle, which functions to indicate the validity of the token because i) it comes from the Issuer and ii) the issuer has checked and produced the signature.

The tracking token can operate as a data register, holding information that can be used to validate a token. During the transfer of a token its validity can be determined by referring to the tracking token either directly or via records held in the Minting Transaction. A token can have a multisignature input. Script in the token can retrieve a required signature from the oracle. The signature can be updated with each token transaction. Therefore, token transactions rely on the status/key held by the oracle. It is to be noted, however, the oracle provides data for authentication and validation of the token unconditionally.

The one or more token-related outputs (T-UTXOs) is/are configured to embed the blockchain transaction (MTx) identification (MTx ID) and index into each subsequent transaction.

Placement of the blockchain transaction (MTx) identification (MTx ID) and index in a token enables a recipient to efficiently locate the minting transaction, which includes a pointer to the tracking token that holds data enabling the determination of the validity of the token. Data within the minting transaction can be used in the subsequent transfer of the token e.g. the issuer's signature. The methods herein enable efficient operations in terms of processing cost and the responsiveness of devices that must determine token validity. A device can be a machine operating on the basis of the status of a token. A device can be an oracle that is required to determine and support a token transaction upon which a device will respond. In each case, the efficiency of token validation has an impact on the system that uses tokens and the speed and reliability of the determination of the token status has an impact outside of the technical determination of the validity.

Improved speed and reliability of the determination of the validity lowers the processing cost because of the swift validation via the minting transaction and/or the tracking token i.e. determining the linear transaction history is not required for validation of the token. Moreover, the improved speed and reliability improves the has an impact on the improved speed and reliability of a device that detects the status of a token e.g. an "invalid" token, thus having an impact on the operation of devices outside of the computer. The methods herein not only provide a technical improvement that improves upon the technical operations of validation, but the method improves the responsiveness of machines processing a valid or invalid token notification, thus speeding up operations using tokens.

As described herein, updating the tracking token output with an Issuer signature, which can be a rolling signature, functions to provide a conditional transfer mechanism, wherein a signature is applied to the tracking token only when the latest token transfer was determined to be valid thus making a subsequent transfer permissible. The Issuer's signature is not limited thereto, the signature functions as a key or a flag that can be provided by an authority managing the tracking token and the corresponding tokens of the ledger. Data can be obtained from the tracking token via a connection to the network in which the blockchain transaction (MTx) was broadcast.

Each token can be issued using an OP_PUSH_TX script that embeds the issuance TXID and index into each subsequent transaction that the token is used in, giving each subsequent receiver an immediate reference anchor for the validation of the token. The script requirements are minimal and allow for diverse locking conditions to be applied to each token, as per the requirements of individual users or applications. This script can also be used to ensure that the input->output indexing is managed correctly, preventing token destruction through malicious action or user error.

The method can further comprise 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.

The method can further comprise determining the validity of the token-related output, the method comprising at least one of: reading the token-related output's blockchain transaction and index; determining that the token is derived from the blockchain transaction; processing the authentication information in the tracking token; determining the validity of the token-related output by identifying that the token-related output's transaction authentication information is logged in said tracking token; and determining whether the latest outpoint of the respective token precedes the transaction authentication information. Transaction authentication information, e.g. a flag or signature is added to the tracking token indicate and determine validity or transferability of the respective token, is added after the latest transaction by the Issuer directly or by its agent e.g. Oracle and, therefore, follows the latest transaction. Using the blockchain transaction and index, the origin of the token can be determined and/or verified e.g. a wallet can provide this information to a receiving party in the preparation of a transaction e.g. through an OP-PUSH-TX operation.

The tracking token can comprise a hash chain for each token created from the transaction, and validation of a token comprises the tracking token providing the (n-l) ^th hash value for the n ^th token transaction. The seed of the hash chain of a token can be a concatenation of a private key of a keypair of the Token Issuer (Tl) and a token identification.

Overall, the provision of the tracking token that has a relationship between a minting transaction and a token generated from a minting transaction enables the validity or authentication of the token. While this is performed on a computer, and provides an indication of the validity or authenticity of the token, the methods herein provide the results of computational analysis e.g. a Merkle proof or other such simplified payment verification (SPV) techniques - said analysis being performed to extract data from two or more locations, and verify the relationship therebetween i.e. a token can be validated by analysing, at least, the minting transaction and data in the tracking token that holds a digital record of, at least in part, the transactional history of the token.

The tracking token, and the tokens and operating system that depend upon the tokens can be considered as individual mechanisms, wherein individual tokens can dynamically update a digital asset, and the tracking token is used to validate the token. These mechanisms operate independently and securely from one another. In one example, a token is analogous to a digital voucher representing, by way of non limiting examples, a payment token, a digital access pass or a digital record.

An initial or establishment transaction e.g. a minting transaction, can determine a relationship between a token and a tracking token. Not only does this initial transaction define a new product i.e. the tracking token for subsequent use when validating the tokens, but the tracking token is used to validate a token prior to or during a subsequent transaction of a token and, thereafter, updated to reflect the latest transaction that has taken place. A single tracking token can support a plurality of tokens i.e. the tracking token functions as a digital register for a plurality of tokens. At least two of the tracking token, token and process being operated by the token can occur in different machines. Even if operating in the same machine the tracking token, token and process being operated by the token are independently operable.

In use, processing a token requires validating a token to be used in a transaction. Via data within the token itself, the associated tracking token that functions as a digital register for the status of a token can be identified and data can be retrieved from the tracking token to determine whether the token is valid. If valid, a subsequent transaction using the validated token can take place. Assuming that the subsequent transaction was valid, then the tracking token can be updated to include a record that said token was validly used in a transaction in preparation for the next transaction requiring validation of said token.

Use of authentication data e.g. a signature, key, flag, hash-puzzle or similar proof can be provided e.g. by an Issuer or Authority managing or holding responsibility for the token ledger. The authentication data is a unit of secure data functions to provide a proof that the token is valid and can be used in a subsequent transaction. This authentication data indicates that the Issuer or Authority determine that a token is valid. The processes taught herein are technical in nature and involves analysis the relationship between digital assets, namely blockchain tokens and is analogous to a physical test of a "lock and key". The validation or authentication of the token using the data within the tracking token provides an improved monitoring and validation technique that is technically superior to that produced in the art. While a linear transaction history of a token can be verified the methods taught herein enable a significant reduction in the computational cost required to determine the validity of a token. Not only if this more cost efficient, but the validity involves (i) fewer computational steps and (ii) retrieving and accessing fewer data elements. Validation or authentication can use signatures from the minting transaction and/or the tracking token, which can be used to indicate the validity of the token because i) they come from the Issuer and ii) the Issuer has checked and produced said signatures. A token, therefore, can require multi-signature input to enable validation and/or a subsequent transaction.

The output e.g. script of a tracking token can be refreshed with each transaction of a token that it is tracking. Additionally or alternatively an oracle can revise at least one of the status and key following each transaction, wherein said status and/or key e.g. a signature is applied to the tracking token output to indicate a token is valid. The tracking token can, for example via an Oracle, monitor transactions on-chain and, if the latest transaction was valid, apply a signature of the Issuer e.g. a rolling signature that is updated with each transaction, to the indexed output of the tracking token that indicates the status of a token. In other words, this signature can be required prior to a subsequent transaction, wherein the Issuer's signature must be applied in the tracking token for a token to be valid and for a transaction to be implemented. An Issuer, or an Oracle operating on their behalf, can sign the output of the tracking token when a transaction has occurred, and is validated. A signature can be applied in response to a transaction, rather than on-request.

If a transaction is deemed to be invalid, the Issuer or their Oracle can select not to sign the tracking token thus invalidating said token. A potential recipient of said token can read the output of the token they are due to receive, retrieve the Minting transaction data and/or the tracking token information and directly retrieve data that can be processed to determine the validity of the token. If the required data e.g. flag, or signature is not available they can identify the token as being invalid and cancel the planned transaction. An issuer can place controls on the use of a token by signing, or not, the output of the tracking token .

In another aspect, a system comprises: 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 (MTx), token and the tracking token as claimed herein. The system can include an oracle or bot. The system, oracle or bot can operate as part of a node, as a node, or has a link with a node. The oracle independently and/or via an association with a node, can be connected to a blockchain network to access the mempool, which will let the oracle know whenever one of the tokens was spent, and then updating the tracking token.

According to another aspect, there resides 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 as claimed.

According to another aspect, there resides a computer program embodied on computer- readable storage and configured so as, when run on one or more processors, to perform the method of as claimed.

For the avoidance of doubt, transactions herein refer to blockchain transactions.

In light of the teaching of the present invention, the skilled person would appreciate that aspects of the invention were interchangeable and transferrable between the aspects described herein and can be combined to provide improved aspects of the invention. Further aspects of the invention will be appreciated from the following description.

Brief Description of the Drawings

Figure 1 has been referred to above as representing a known token ledger. 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: Figure 2 is a schematic representation of a minting transaction in which tokens are created, said transaction comprising a mint record and a tracking token, which functions as a tracing output;

Figure 3 is a schematic representation of a tracking token of Figure 2, configured by way of example as a payment channel and comprising a 'mint data output' and an indexed output of each of the tokens of Figure 2;

Figure 4 is a schematic representation of updates made to the set of five tokens issued in Figure 2, wherein a record of the token transaction and index is recorded;

Figure 5 is a schematic representation of the tracking token recording the updates made in Figure 4;

Figure 6 is a schematic process flow representing the relationship between the minting transaction and tracking token of Figure 2 during determination of the validation of a token in a transaction; and

Figure 7 is a schematic representation of a device for implementing the methods herein.

Detailed Description - overview

Examples of some possible examples and 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 the 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 W02021/250037, which is incorporated by reference herein in its entirety.

General overview

Determining the authenticity of a token can be achieved by creating a tracking token in a minting transaction (MTx) at the beginning of a linear transaction history i.e. writechain. The tracking token is subsequently used, on and/or off-chain, to provide data that functions as a refence e.g. referee, for enabling the determination of a token's validity.

The tracking token functions as a tracing output and is analogous to a bulletin board. The tracking token receives and/or gathers and/or generates data associated with the other tokens generated in the minting transaction (MTx). Said data can be managed on a database or resource, thus can be updated and provide information to third parties off -chain e.g. while off-chain.

While the tracking token is analogous to a 'bulletin board' it is technical in nature and can provide more than a bookkeeping function. The tracking token operates as a digital register. As a digital register it can be at least one of: updated with details of one or more token transactions; and provided with static and/or dynamic signatures that are required to transfer one or more tokens in a subsequent token transaction. Validation of a token can include retrieving and determining through computational processing the validity of a token. A tracking token can be generated by miners. The tracking token can be used in a non-final state e.g. usable only as part of the mempool. While the tracking token can be transmitted on the network for inclusion in a transaction, this is optional. The tracking token can be constantly updated.

Following the minting transaction, the tracing is managed by an oracle e.g. a bot. The oracle uses the tracking token to provide, at least, a record of the latest token transaction. Upon consulting the oracle, the tracking token data can be obtained that enables the token to be validated and/or a subsequent transaction to be established/validated.

The data record held in the tracking token functions like a public 'bulletin board' e.g. a standalone and/or read-only source of data enabling validation of a token and/or control system outputs. The tracking token can operate like a digital register, holding information that is processed to determine the validity of a token. The data record of the tracking token provides an efficient mechanism for validating a token with computational cost efficiency. The data record can hold part of a solution required for a token's transferability.

The tracking token can be used as part of a control system, wherein the status of an actuator and/or sensor can be stored as data in the output, said output functioning as a consolidated repository for data associated with said actuator and/or sensor that is stored in a block of a blockchain. By way of example, a control system managed by tokens (see W02021/250022, incorporated herein by reference in its entirety) can operate based on the data stored in 1000 tokens, and determining the status of each of said tokens requires, conventionally, retrieving data from the transaction outputs that are distributed in blocks on a blockchain. In light of the teaching herein, the tracking token can hold the data and/or status associated with said 1000 tokens such that the data is consolidated and accessible in one location, rather than accessed from each of their respective blockchain locations. As described above, the location of the tracking token data can be (i) a database and/or repository, and/or (ii) a block in a blockchain, when recorded in a tracking token transaction. The tracking token can function as a repository for the status of components in a sequential control and data acquisition (SCADA) system.

The minting transaction and/or the oracle can be created and/or managed by an issuer. In other words, the issuer responsible for the pool of tokens can retain control of the oracle - directly or indirectly - to correct errors or deal with corruption e.g. by refreshing a token. The oracle, however, can operate autonomously to maintain the tracking token and/or make available data records to third parties requiring data to verify a token. Figure 2 illustrates a minting transaction (MTx) that can be transmitted and recorded in a blockchain block. The minting transaction has in input of 100 satoshis and an output at index 2 for returning the remaining balance as change i.e. 73 satoshis, after paying 10 satoshis in mining fees. The output at index 0 is a mint record, having a value of 1 satoshi, having an accompanying digital signature of the issuer, said signature having an associated public key of a parent transaction on a token ledger. A tracking token, having a value of 11 satoshis, is output at index 1. The outputs at indices 3 to 7 correspond to five tokens, nominally 'Token 1' to 'Token 5', each having a value of 1 satoshi.

The minting transaction, therefore, generates a mint record of the transaction, the tracking token and five tokens. During the subsequent transfer and/or verification of the or each token the minting transaction (MTx) and/or the tracking token can be used together with the respective token to validate the token.

The or each output can include data e.g. script of a UTXO, representing the function of the output, which in the present example comprises: token-related outputs (T-UTXOs), each of which represents a respective token; and a tracking token, said tracking token including authentication information for the respective token (T) related outputs.

The minting transaction can further comprise at least one Issuer-related output (l-UTXO) comprising issuance data (IData) associated with the Token Issuer (Tl). The issuer can record in the token ledger parent a 'public key'. Issuance data and/or a 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. Known 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.

The tracking token functions as a data repository e.g. a noticeboard holding records of the status and/or validity of the or each token output from the minting transaction. The tracking token can hold data that is passively used during the validation of a token. The tracking token can, additionally or alternatively, hold data that is processed to enable verification and/or transfer of the token e.g. the tracking token holds a signature required for a multi-signature input of a token. Overall, the tracking token tracks the latest status of the outputs of the minting transaction e.g. token UTXO.

The output of each token is configured having data associated at least one of: the minting transaction, the tracking token and token parameters e.g. token value and functionality. In other words, a recipient seeking to determine the authenticity of a token can obtain from the output said data, or a link/address of where to find the required data e.g. an address of the tracking token. The tracking token is produced, stored and/or maintained by, or on behalf of, the token issuer that created and/or authorised the minting transaction e.g. using their digital signature. The tracking token holds data indicating at least one of the status, history or origins of the or each of the minting transaction outputs. The data enables authentication of a token e.g. said token having associated transaction data that has been recorded in a block on a blockchain.

A token output can include at least one of: a quantity of token units (TU); and a quantity of token-related cryptocurrency (TRC) associated with the respective token (T); a record of the blockchain transaction (MTx); and an index output of the respective token. The status of the token can be recorded in the tracking token.

Hash chain

When the tokens are minted, a hash chain can be generated from each token. At least a portion of the seed for the hash can be known and/or determined only by the issuer. By way of example, the tracking token can generate a deterministic wallet. For example, a seed (x) for the hash chain can include the private key of the issuer concatenated with the token number.

Each hash value in the hash chain of a token is allocated to a corresponding transaction. By way of example, a hash chain of length 1000 is generated, and the value h ¹⁰⁰⁰ (x) allocated to the first transaction. For each token, the tracking token makes available the hash value corresponding to the next transaction.

A third party can validate the first transaction, by retrieving a hash value for the second transaction from the tracking token, said second hash value being h ⁹⁹⁹ (x), which is hashed to validate that h(h ⁹⁹⁹ (x)) = h ¹⁰⁰⁰ (x).

The value of 1000 is a nominal example, and the hash chain can be of any length, such that the tracking token provides the (n-l) ^th hash value for the n ^th token transaction.

The token script can be configured to require the correct hash value provided by the tracking token as part of the solution when signing the token.

The script can also be configured to allow the issuer to insert a hash from a new seed (e.g. h ¹⁰⁰⁰ (y) after the 1000 hashes have been consumed through transactional use/traffic.

Tracking token

The tracking token comprises data that can be used to determine at least one of: that the tracking token was in the minting transaction MTx, which is included in the Merkle path of a blockchain block (B); transaction data of the most recent token transaction; location details of the most recent token transaction(s). The transaction data enables determination of the authenticity of a token in fewer steps. A transaction of the tracking token is shown in Figure 3. The tracking token can be treated like a token having output script. The output script can include control script for authorising a transaction and holding satoshis. The input to the transaction is 11 satoshis. An input sequence number can also be recorded. The mining fee is 10 satoshis. Change of 1 satoshi is retained in the "tracing output control" token e.g. the token retains a value of 1 satoshi. It is to be noted that the values of satoshis used in all the examples herein are for illustration purposes only.

The output of the transaction of the tracking token e.g. the UTXO output. The transaction output includes data associated with each of the indexed outputs of the minting transaction in which the tracking token was established. In other words, the indexed output of the minting transaction i.e. indices 0 to n, are tracked in corresponding outputs of the tracking token. In the example herein, the minting transaction had 8 outputs i.e. indices 0 to 7, and the tracking token has eight pieces of transaction data, indicating the status of each of the minting transaction outputs. In the specific example, the tracking token includes data for: index 0, a record of the mint record, provided as "mint data output" in an OP_FALSE_OP_RETURN, which means that the data can only be read, and not changed by a third party; "tracking token control", which enables the issuer and/or the oracle managing the tracking token to include the tracking token in a transaction; the "change output" for receiving change from a transaction; and five "ISSUANCE TXID INDEX n", wherein "n" corresponds to the index of the token output in the minting transaction, which in the example is indices 3 to 7, each having an OP_FALSE_OP_RETURN, which means that the data can only be read, and not changed by a third party. The output of the tracking token that defines the status and/or data associated with each token is configured to be processed without payment e.g. by using an OP-RETURN. The tracking token output is configured such that it does not require a payment i.e. it does not require 1 satoshi for each output. Optionally, each token can have zero-value output.

Overall, the tracking token creates a set of false return outputs that each contain data related to their matched outputs in the issuance e.g. minting transaction it originates.

The tracking token can be used and/or configured as a payment channel. Payment channels are known in the art e.g. https://wiki.bitcoinsv.io/index.php/Payment_Channels. The tracking token is spent with nSequence = 0x00000000 and nLocktime set to 1 week in the future. For implementing a payment channel these parameters must be non-final. In this way the parameters govern the function of the payment channel by instructing nodes on the network under which conditions the transaction is to be made final.

The tracking token can be managed by an oracle service, agent or bot, which monitors token transactions in blocks on a blockchain ledger and/or token activity in the mempool. The tracking token can be updated at regular intervals/periods e.g. every minute, or each time a new block is created, to reflect the latest outpoint of each token on the ledger. If there has been no token activity e.g. transfer, then the data record on the tracking token remains unchanged. If the token has been included in a transaction since the last tracking token update, then the output is updated to reflect the most up-to- date transaction data e.g. location of the token.

Following the creation of the token output in the minting transaction, the methods herein can include receiving and/or retrieving token data associated with the or each unspent transaction e.g. T- UTXO) and/or transaction containing said T-UTXO and updating the tracking token. The tracking token can be read only. The tracking token can merely monitor and record, updating the data records associated with each of the indexed outputs from the minting transaction that created the tracking token - in this way, the tracking token can remain robust and serve as an authentic source of information because only the issuer or their agent, which holds the signatures to control the tracking token, can modify the data records. The tracking token can include interlocks comprising at least one of: a sequence number; and a locktime, wherein the tracking token is non-final until the sequence number and/or the locktime exceed a threshold value.

The tracking token includes data records that function to provide authentication information, which can comprises at least one of: the latest outpoint on the ledger of the respective token e.g. the location of the transaction; data indicating that the transaction that included the token at one of its indices was part of a Merkle tree and/or identifying the block in which said transaction is recorded; a flag indicating the validity of the respective token (T); data that enables the validity of the respective token to be determined e.g. a Merkle proof that the token transaction was compiled in a block e.g. using Simplified Payment Verification (SPV) techniques; and 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.

Transaction data of tokens generated in a minting transaction can be configured to include e.g. embed information that enables a third party to initiate authentication of a token. By way of example, the transaction data e.g. the one or more token-related outputs (T-UTXOs) is/are configured to embed at least one of: the blockchain transaction (MTx) identification (MTx ID); and index; a link and/or location information of the tracking token. This information can be incorporated within the script of the token such that remains after each transaction e.g. using an OP_PUSH_TX.

Each token, therefore, can be issued using an OP_PUSH_TX script that embeds the issuance TXID and index into each subsequent transaction that the token is used in, giving each subsequent receiver an immediate reference anchor for the validation of the token. The script requirements are minimal and allow for diverse locking conditions to be applied to each token, as per the requirements of individual users or applications. This script can also be used to ensure that the input->output indexing is managed correctly, preventing token destruction through malicious action or user error. This data can ensure that the token's genesis transaction ID and output index is embedded in each future use of the token after the genesis event. This 'embedding' event is performed by the issuer in the first transaction performed with each token. This embedding transaction can be done by tokens on an individual basis, or all at once.

In the examples herein, Figure 4 illustrates that the tracking token has identified that tokens 1, 2, 3 and 5 have been included in transactions, and that the tracking token requires updating accordingly. In particular: token 1 has been included in a transaction "txOl" at index 4 e.g. Vout4; tokens 2 and 3 have both been used in the same transaction, namely "tx02" at indices 2 and 12, respectively; and token 5 has been used in "tx04" at index 0. No transaction including token 4 has been identified.

Figure 5 illustrates a transaction of the tracking token, in which the data output corresponding to the indices of tokens 1, 2, 3 and 5 is updated to include a reference to the latest transaction and index in which the respective token was included. In particular, the transaction data includes: for token 1, "TX01 INDEX 4"; for token 2, "TX02 INDEX 2"; for token 3, "TX02 INDEX 12"; for token 4, "ISSUANCE TXID02 INDEX 6", because the last transaction data was obtained from the minting transaction and there has been no subsequent transaction identified; and for token 5, "TX04 INDEX 0". It is to be noted that the payment channel input's nSequence number has been updated to 0x0000001, and the false return outputs have each been updated to reflect the new locations of the transferred tokens. The nLocktime value has also been updated to a new time, 1 week in the future to ensure the payment channel remains open for the duration of the token's use.

In the event that a token is corrupted or becomes otherwise unusable through malicious action or user error then the issuer, their agent and/or the oracle can refresh a token by updating the tracking token with transaction data with corrected authentication information. In other words, a token can be replaced or re-issued by having the same authentication information as the previous respective token (T).

Validation

Figure 6 illustrates a process slO including: actions, including creating and transmitting a minting transaction (MTx) that can be taken by the issuer to create tokens sl2; using a tracing output sl4, implemented in the form tracking token sl4, which can be performed by an oracle on behalf of the issuer of the minting transaction to hold a record of at least the latest transaction of a token; and a series of steps sl6 through to s24, wherein the or each step can be used for determining the authenticity of a token issued in the minting transaction (MTx). The minting transaction at sl2, and the use of the tracking token sl4 has been described above. A third party, e.g. recipient of a token for inclusion in a transaction, can take one or more steps to determine the validity of a token. This can involve using a device configured to implement the methods herein e.g. a digital wallet. The tracking token functions as a repository of data records of the token transactions. The tracking token is managed by an oracle e.g. bot on behalf of the issuer of the tokens, or by the token issuer themselves.

It is to be noted that the issuer and/or oracle does not need to be party to a token transaction nor be aware of or have any influence on the transaction or its contents. The validation process can be performed without needing to access systems operated by the issuer and/or the oracle e.g. the tracking token can be read-only and/or provide data on request.

A third party initially receives a token sl6 generated from a minting transaction sl2. Determining the validity of a token-related output can include at least one of: reading the token-related output's blockchain transaction and index sl8 e.g. a digital wallet receives a token, and reads the tokens minting transaction and output index data, and then subsequently proceeds to query the public network to identify/confirm the minting transaction details, thus determining that the token is derived from the blockchain transaction (MTx) sl8; the mint record meta-reference can then be checked s20 to ensure that the minting transaction was created by the issuer i.e. genuine; the token and/or minting transaction includes a pointer to the tracking token, and the token transaction data and/or the minting transaction record can be used to obtain data records from the tracking token s22, which can be processed to authenticate information in the tracking token; determining the validity of the token-related output by identifying that the token-related output's transaction authentication information is logged in said tracking token (s24); and determining whether the latest recorded outpoint of the respective token is or precedes the transaction authentication information (s24).

Overall, a third party can check that the blockchain transaction creating the tokens is valid e.g. validating the transaction is part of a block on the blockchain. Further, at least one issuer's can be validated, although all of the issuers' signatures can be validated. Token information can also be obtained from the tracking token and cross-checked against the history of the token e.g. are recent blockchain transactions involving the token recorded on-chain and/or do they correspond to the records in the tracking token, e.g. do the transaction locations match.

Independently of the number of token transaction, the Miniting transaction can be immediately identified from a record in the token output. This can enable an efficient and computationally cost effective determination of a Merkle proof. The methods described above have included the use of systems, an oracle/bot and a digital wallet. The system, by way of example can be implemented as a node, or part thereof. The system or device that obtains information to manage the tracking token requires a port configured to receive transactions directly and/or from at least one other node in a blockchain network. The system and/or device has a processor configured to produce, hold and/or maintain a record of at least one of the blockchain transaction (MTx), token and the tracking token as described herein. The system and/or device can be implemented on 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 methods taught herein. A computer program e.g.an oracle or a bot can be embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the methods taught herein.

In the series of steps sl6 through to s24, a third party receiving a token for inclusion in a blockchain transaction can validate a token by referring to the oracle that holds a hash chain for the respective token and provides a hash value corresponding to the previous transaction. Referring to the example above, a hash chain of length 1000 is generated, and the value h ¹⁰⁰⁰ (x) allocated to the first transaction. The provider of the token can sign the transaction using the value of h ¹⁰⁰⁰ (x), the recipient can obtain the next hash value in the chain corresponding to the transaction a hash value e.g. h ⁹⁹⁹ (x), and hash said value to determine whether h(h ⁹⁹⁹ (x)) = h ¹⁰⁰⁰ (x).

System

An example of a device having a controller and a control system is illustrated in Figure 7. The device can function as an oracle or bot to manage the tracking token and its associated data. 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 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 100. 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. The 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. The 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 a control system 122 and contain computational units 124 to 132.

The indefinite articles "a" and "an," as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean "at least one." The phrase "and/or," as used herein in the specification and in the claims, should be understood to mean "either or both" of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Other elements may optionally be present other than the elements specifically identified by the "and/or" clause, whether related or unrelated to those elements specifically identified unless clearly indicated to the contrary. Thus, as a non-limiting example, a reference to "A and/or B," when used in conjunction with open-ended language such as "comprising" can refer, in one embodiment, to A without B (optionally including elements other than B); in another embodiment, to B without A (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

As used herein in the specification and in the claims, "or" should be understood to have the same meaning as "and/or" as defined above. For example, when separating items in a list, "or" or "and/or" shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as "only one of" or "exactly one of," or, when used in the claims, "consisting of," will refer to the inclusion of exactly one element of a number or list of elements. In general, the term "or" as used herein shall only be interpreted as indicating exclusive alternatives (i.e. "one or the other but not both") when preceded by terms of exclusivity, such as "either," "one of," "only one of," or "exactly one of." "Consisting essentially of," when used in the claims, shall have its ordinary meaning as used in the field of patent law.

As used herein in the specification and in the claims, the phrase "at least one," in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase "at least one" refers, whether related or unrelated to those elements specifically identified. Thus, as a nonlimiting example, "at least one of A and B" (or, equivalently, "at least one of A or B," or, equivalently "at least one of A and/or B") can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

In the claims, as well as in the specification above, all transitional phrases such as "comprising," "including," "carrying," "having," "containing," "involving," "holding," and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03. Use of ordinal terms such as "first," "second," "third," etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

The invention also consists in any individual features described or implicit herein or shown or implicit in the drawings or any combination of any such features or any generalisation of any such features or combination.