GB2620401A

GB2620401A - Computer implemented systems and methods

Info

Publication number: GB2620401A
Application number: GB2209879.2A
Authority: GB
Inventors: Lee Brendan
Original assignee: Elas Holdings Pty Ltd
Current assignee: Elas Holdings Pty Ltd
Priority date: 2022-07-05
Filing date: 2022-07-05
Publication date: 2024-01-10
Also published as: GB202209879D0; WO2024009091A1

Abstract

A method comprises using, processing and/or generating a blockchain transaction having one or more token-related outputs, each representing a respective token issued by an issuer and comprising a tracking token. The tracking token including authentication data for validating the respective token related outputs. A method of producing, storing and/or maintaining the tracking token is further provided, as well as a method comprising using, processing and/or generating first and second blockchain transactions, the second of which comprises the tracking token. The respective token may comprise at least one of a quantity of token units, a quantity of token-related cryptocurrency associated with the respective token, and a record of blockchain transaction and index output of the respective token. The tracking token may comprise a hash chain for each token, and validation comprises the tracking token providing the (n-1)th hash value for the nth token transaction.

Description

COMPUTER IMPLEMENTED SYSTEMS AND METHODS

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-UTX05), each of which represents a respective token (T) issued by a Token Issuer (TI). The tracking token is stored and/or maintained by a system e.g. an oracle or loot, 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.

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'.

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. 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.

In an additional or alternative aspect, there resides a computer-implemented method comprising: using, processing and/or generating a first 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 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.

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.

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 (I-UTX0) comprising issuance data (IData) associated with the Token Issuer (TI). 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-UTX0) 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 transaction: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.

A token can have a multi-signature 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-UTX05) is/are configured to embed the blockchain transaction (MTx) identification (MTx ID) and index into each subsequent transaction.

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 outputs transaction authentication information is logged in said tracking token; and determining whether the latest outpoint of the respective token precedes the transaction authentication information.

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-1)th hash value for the nth token transaction. The seed of the hash chain of a token is a concatenation of a private key of a key-pair of the Token Issuer (TI) and a token identification.

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.

A tracking token can be to 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 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.

Minting 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-UTX05), 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 (I-UTX0) comprising issuance data (IData) associated with the Token Issuer (TI). 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 hmm(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 h999(x), which is hashed to validate that h(h999(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-1)th hash value for the nth 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. hmocify, r 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 I0 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 = Ox00000000 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. TUTX0) 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-UTX05) 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 "tx01" 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, "D(02 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 Ox0000001, 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 s10 including: actions, including creating and transmitting a minting transaction (MTx) that can be taken by the issuer to create tokens s12; using a tracing output s14, implemented in the form tracking token s14, 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 s16 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 s12, and the use of the tracking token s14 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 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 s16 generated from a minting transaction s12.

Determining the validity of a token-related output can include at least one of: reading the token-related output's blockchain transaction and index s18 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) s18; 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.

No matter how often spent, got to MTx. Validate that part of Merkle proof and issuer is legit, then output of tracking token references recent history...of actual token on BC 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 (MIX)) 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 s16 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 hi"(x) allocated to the first transaction. The provider of the token can sign the transaction using the value of hlm(x), the recipient can obtain the next hash value in the chain corresponding to the transaction a hash value e.g. h999(x), and hash said value to determine whether h(h999(x)) = hiC100(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.

IS

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 non-limiting 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.

Claims

Claims 1. A computer-implemented method comprising: using, processing and/or generating a blockchain transaction (MTx) having: one or more token-related outputs (T-UTX05), each of which represents a respective token (T) issued by a Token Issuer (TI), and comprising a tracking token, said tracking token including authentication data for validating the respective token (T) related outputs.
2. A computer-implemented method comprising: producing, storing and/or maintaining a tracking token, wherein said tracking token was generated in a blockchain transaction (MTx) including one or more token-related outputs (T-UTX0s), each of which represents a respective token (T) issued by a Token Issuer (TI), wherein said tracking token includes authentication data for validating the respective token (T).
3. The method of claim 1 or 2, wherein the respective token comprises 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.
4. The method of any preceding claim, wherein the blockchain transaction further comprises at least one Issuer-related output (I-UTX0) comprising issuance data (IData) associated with the Token Issuer (TI).
5. The method of any preceding claim, further comprising: receiving and/or retrieving token data associated with the or each unspent transaction output (T-UTXO) and/or transaction (Tx) containing said T-UTXO; and updating the tracking token.
6. The method of any preceding claim, wherein the tracking token defines a payment channel.
7. The method of any preceding claim, wherein the tracking token is read only.
8. The method of any preceding claim, wherein the tracking token has 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.
9. The method of any preceding claim, wherein the 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.
10. The method of any preceding claim, wherein the one or more token-related outputs (TUTX05) is/are configured to embed the blockchain transaction (MTx) identification (MTx ID) and index into each subsequent transaction.
11. The method of any preceding claim, further comprising using, processing and/or generating a subsequent blockchain transaction (MTx), said subsequent blockchain transaction comprises a replacement or re-issued respective token (rT) having the same authentication information as the previous respective token (T).
12. The method of any preceding claim, further comprising 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 (s16); determining that the token is derived from the blockchain transaction (MTx) (s18); processing the authentication information in the tracking token (s20); 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 (s22); and determining whether the latest outpoint of the respective token precedes the transaction authentication information (s24).
13. The method of any preceding claim, further comprising 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 (MTx); 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.
14. The method of any preceding claim, wherein the tracking token comprises a hash chain for each token created from the transaction, and validation of a token comprises the tracking token providing the (n-1)th hash value for the nth token transaction.
15. The method of claim 14, wherein the seed of the hash chain of a token is a concatenation of a private key of a key-pair of the Token Issuer (TI) and a token identification.
16. A computer-implemented method comprising: using, processing and/or generating a first 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 output.
17. 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 (Mix), token and the tracking token of any preceding claim.
18. 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 16.
19. 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 16.