Computer-implemented method and system for verifying tokens for block chain-based crypto-currencies

Abstract

To provide a method, a system, and a program for determining the validity of a token associated with a crypto-currency amount.SOLUTION: A method includes the steps of: receiving, by a second user via a communication network 8, a first transaction including the transfer of a token from a first user to the second user; querying a peer-to-peer distributed ledger to determine whether an attested transaction associated with the token and including a previous transaction associated with the token can be identified; validating the token; and determining that the token is valid in response to identifying the attested transaction.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates generally to distributed ledger technologies, such as, but not limited to, the Bitcoin blockchain. Described embodiments relate to security-enhanced systems and methods for validating tokens for blockchain-based cryptocurrencies. Some embodiments relate to validating tokens associated with blockchain transactions (TXs) that have not been electronically countersigned by authorized signers. Other embodiments relate to systems and computer-implemented control methods configured to enable and enhance the transfer and communication of blockchain-implemented tokens between computing nodes. [Background technology]

[0002] The term "blockchain" is used in this document to include all forms of electronic, computer-based distributed ledgers. These include peer-to-peer consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. While Bitcoin may be referenced in this disclosure for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a computer-based, decentralized, distributed, peer-to-peer electronic ledger implemented as a system composed of blocks, each of which consists of transactions. Each transaction (TX) is a data structure that encodes the transfer of digital assets between participants in the blockchain system and contains at least one input and at least one output. Each block contains a hash of the previous block, and blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain, from its inception. Transactions contain small programs, known as scripts, embedded in their inputs and outputs that specify how the transaction's outputs can be accessed and by whom. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] In order for a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work of ensuring each transaction is valid, with invalid transactions being rejected by the network. A software client installed on the node performs this validation on unspent transactions (UTXOs) by executing its locking and unlocking scripts. If the locking and unlocking scripts evaluate to TRUE, the transaction is valid and is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives it—and if the transaction is verified, this node relays the transaction to other nodes in the network—ii) be added to a new block constructed by miners, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for automated tasks and processes that are not limited to the cryptocurrency realm. Such solutions would be more diverse in their applications while still being able to take advantage of the benefits of blockchain (e.g., distributed processing of a permanent, tamper-resistant record of events).

[0006] One area of ​​current research is the use of blockchain to implement "smart contracts." Smart contracts are computer programs designed to automate the execution of machine-readable contracts or agreements. Unlike traditional contracts, which may be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to generate outcomes and then cause actions to be taken depending on those outcomes. With respect to commercial transactions, for example, these may involve the transfer of property rights and / or assets. Such assets may include real estate, personal property (including both tangible and intangible property), digital assets such as software, or any other type of asset. In the digital economy, there is often a prediction that exchanges and transfers will be carried out in a timely manner over enormous distances. This prediction, along with practical technological limitations, means that traditional forms of asset transfer, such as hard copies of documents representing contracts, negotiable instruments, etc., or physical delivery of the tangible assets themselves, are undesirable. Smart contracts can therefore provide increased control, efficiency, and speed of transfers.

[0007] Another area of ​​interest related to blockchain is the use of "tokens" (or "colored coins") to represent and transfer real-world entities via the blockchain. Potentially sensitive or secret items can be represented by tokens that have no discernible meaning or value. Tokens therefore function as identifiers that allow real-world items to be referenced from the blockchain. The use of tokenization provides increased security and control in terms of communication, transfer, and verification of digital entities on the blockchain.

[0008] The description of documents, acts, materials, devices, products or the like which has been included in this specification should not be construed as an admission that any or all of such matters form part of the basis of the prior art or were common general knowledge in the art relevant to the present disclosure as existing prior to the priority date of each claim of this application.

[0009] Throughout this specification, the words "comprise," "having," "including," or variations such as "comprises" or "comprising" will be understood to imply the inclusion of a stated element, integer, or step, or group of elements, integers, or steps, and not the exclusion of any other element, integer, or step, or group of elements, integers, or steps. Summary of the Invention

[0010] Embodiments of the invention are provided as defined in the claims.

[0011] The present invention may be described as a verification or authentication method and corresponding system, as it may enable the determination and / or identification of blockchain transactions that include or relate to one or more tokens and that are digitally signed by an authorized signatory, which may be the token issuer or another party. As a result of this verification technique, security is enhanced.

[0012] Some embodiments relate to a computer-implemented method of determining validity of a token associated with a cryptocurrency amount, the method may include receiving, by a second user, a first transaction over a communications network, the first transaction including a transfer of the token from the first user to the second user; querying a peer-to-peer distributed ledger (blockchain) to determine whether an attested transaction associated with the token can be identified, the attested transaction including a previous transaction associated with the token that validates the token; and determining that the token is valid in response to identifying the attested transaction.

[0013] In some embodiments, querying the peer-to-peer distributed ledger includes querying the peer-to-peer distributed ledger in response to determining that the authenticity of the token of the first transaction has not been attested.

[0014] In some embodiments, determining that the token is not authentic includes determining that a redeem script associated with the token, the redeem script referenced as an input to the first transaction, is not (cryptographically) signed by an authorized signer. A token for a validated transaction may be signed by an authorized signer. For example, the authorized signer may include at least one of the token issuer and a trusted service provider.

[0015] In some embodiments, querying the peer-to-peer distributed ledger includes: a) determining a previous transaction ID indicated in the first transaction; b) identifying a previous transaction recorded in the peer-to-peer distributed ledger, wherein the transaction ID of the previous transaction matches the determined previous transaction ID; c) determining whether the redemption script of the previous transaction is signed by an authorized signer; d) identifying the previous transaction as a validated transaction in response to determining that the redemption script of the previous transaction is signed by an authorized signer; e) determining the previous transaction ID indicated in the previous transaction as a previous transaction ID in response to determining that the redemption script of the previous transaction is not signed by an authorized signer, and identifying a further previous transaction recorded in the peer-to-peer distributed ledger as a previous transaction, wherein the transaction ID of the further previous transaction matches the previous transaction ID; and f) iteratively performing steps c) through e) until no further previous transactions are identified.

[0016] Thus, the present invention may involve performing one or more of the steps described above to start with an initial or "trigger" transaction and proceed through a logical path or hierarchy of transactions, examining different transactions in each block on the blockchain until the validity of the token is established or at least sufficiently proven, or verification fails.

[0017] In some embodiments, the method further includes determining that the token is not valid in response to not identifying an attested transaction in the peer-to-peer distributed ledger.

[0018] Some embodiments relate to a computer-implemented method for determining validity of a token associated with a cryptocurrency amount, the method including: receiving, via a communications network, a first transaction involving a transfer of the token from the first user to the second user; querying a rights registration database to determine whether a second transaction involving the transfer of the token is recorded in the rights registration database; and determining that the token is valid in response to determining that the second transaction is recorded in the rights registration database. For example, the second transaction may precede the first transaction in time.

[0019] In some embodiments, querying the rights registration database includes querying the rights registration database in response to determining that the token is not authentic.

[0020] In some embodiments, the rights registration database includes one or more entries related to transactions involving transfers of tokens, each entry associated with a transaction indicator, and querying the rights registration database includes determining a transaction indicator associated with the token from the first transaction; and comparing the transaction indicator with one or more transaction indicators in the rights registration database to identify the second transaction. For example, the transaction indicator may include a transaction ID.

[0021] In some embodiments, determining that the authenticity of the token is not attested includes determining that a first redemption script associated with the token, the first redemption script referenced as an input to the transaction, is not signed by an authorized signer, which may include at least one of the issuer of the token and a trusted service provider.

[0022] In some embodiments, the method further includes determining that the token is not valid in response to determining that the second transaction is not recorded in the rights registration database.

[0023] In some embodiments, the method further includes, in response to determining that the second transaction is not recorded in the rights registration database, querying the peer-to-peer distributed ledger to determine whether an attested transaction associated with the token can be identified, the attested transaction including a previous transaction associated with the token and validating the token; and, in response to identifying an attested transaction, determining that the token is valid.

[0024] In some embodiments, a computer-implemented method for maintaining, by a first party, a rights registration database for recording transfers of tokens issued by an issuer, each token associated with a cryptocurrency amount, the method comprising: monitoring a peer-to-peer distributed ledger for transactions involving transfers of tokens issued by the issuer; and, in response to identifying a first transaction recorded on the peer-to-peer distributed ledger that includes a transfer of tokens issued by the issuer, recording the transfer of the token in the rights registration database.

[0025] In some embodiments, monitoring the peer-to-peer distributed ledger further includes determining a previous transaction ID for the transaction recorded in the peer-to-peer distributed ledger; comparing the determined previous transaction ID to a set of transaction IDs, where each transaction ID in the set identifies a transaction associated with a token issued by the issuer; and, in response to the determined previous transaction ID matching a transaction ID in the set of transaction IDs, determining the transaction associated with the previous transaction ID as a record of a first transaction involving a transfer of a token issued by the issuer.

[0026] In some embodiments, monitoring the peer-to-peer distributed ledger further includes determining a target transaction ID of a transaction associated with the token issued by the issuer; comparing the target transaction ID with a previous transaction ID of the transaction recorded in the peer-to-peer distributed ledger; and, in response to the target transaction ID matching the previous transaction ID of the one of the transactions recorded in the peer-to-peer distributed ledger, determining the one of the transactions recorded in the peer-to-peer distributed ledger as a record of the first transaction.

[0027] In some embodiments, the method further includes verifying the authenticity of an entry associated with recording the transfer of the token in the rights registration database by adding the issuer's signature to the entry.

[0028] In some embodiments, maintaining the rights registration database is performed by at least one of the publisher and the authorized service provider.

[0029] In some embodiments, the rights registration database includes a distributed hash table. For example, the distributed hash table may include contracts associated with tokens issued by an issuer.

[0030] Some embodiments relate to a token validation system for determining the validity of a token associated with a cryptocurrency amount, the token validation system having a memory for storing a validation application and a processor, the processor configured to execute the validation application to perform any one of the methods described above.

[0031] Some embodiments relate to a rights register maintenance system that maintains a rights register database for recording transfers of tokens, each token being associated with a cryptocurrency amount, the rights register maintenance system having a memory for storing a maintenance application and a processor, the processor being configured to execute the maintenance application to perform any one of the methods described above.

[0032] Some embodiments relate to a computer software program comprising machine-readable instructions that, when executed by a processor, cause the processor to perform any one of the methods described above. [Brief explanation of the drawings]

[0033] Examples of the present disclosure will now be described with reference to the drawings. [Figure 1] FIG. 1 is a schematic diagram of an exemplary system for creating and / or transferring tokens, according to some embodiments. [Figure 2] FIG. 1 illustrates an example of a first type of transaction between an issuer and a first user, including creating a token. [Figure 3] 1 is a process flow diagram of a computer-implemented method for creating a token, according to some embodiments. [Figure 4]FIG. 10 illustrates an example of a second type of transaction between a first user and a second user, involving transferring tokens. [Figure 5] 1 is a process flow diagram of a computer-implemented method for maintaining a rights registration database for recording transfers of tokens, according to some embodiments. [Figure 6] 1 is a process flow diagram of a computer-implemented method for validating a token, according to some embodiments. [Figure 7] 1 is a process flow diagram of a computer-implemented method for validating a token, according to some embodiments. [Figure 8] 2 illustrates a schematic example of a processing device of the system of FIG. 1, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0034] Described embodiments relate to systems and computer-implemented methods for validating tokens implemented in conjunction with blockchain-based cryptocurrencies, such as Bitcoin. Some embodiments relate to validating tokens associated with transactions that have not been electronically countersigned by an authorized signatory. Other embodiments relate to systems and computer-implemented methods for maintaining a rights registration database for recording transfers of tokens. A token can be a representation or identifier of any type or associated with a physical, electronic, digital, or abstract entity or asset.

[0035] Some embodiments relate to systems and computer-implemented methods for determining the validity of a token (T) associated with a cryptocurrency amount (B1), where the token (T) is transferred from a first user (A) to a second user (B), for example, via a blockchain transaction Tx that includes (or results in) the transfer of the token (T). In some embodiments, the authenticity of the token (T) has not been verified by a signatory, such as the issuer of the token (T) or a trusted service provider.

[0036] In some embodiments, a peer-to-peer distributed ledger (blockchain) may be queried to determine whether an attested transaction associated with a token (T) can be identified. This may or may not be the Bitcoin blockchain. For example, such attested transactions may include previous transactions associated with the token (T), where the token (T) is validated. In response to identifying an attested transaction, the token (T) may be determined to be valid. A "previous" transaction refers to a transaction that was written to the blockchain earlier, i.e., earlier in time. Recall that blocks (and therefore transactions) are written to the blockchain in chronological order. An earlier transaction may be described as a transaction that is earlier in the chain of blocks, i.e., closer to the originating inception block.

[0037] In some embodiments, a rights registration storage resource, e.g., a database, may be queried to determine whether a second transaction involving the transfer of token (T) has been registered or recorded in the rights registration storage, where the second transaction precedes the first transaction in time. In response to determining that the second transaction (T2) has been recorded in the rights registration store, token (T) may be determined to be valid.

[0038] In some embodiments, a party (P), such as an issuer (I) of a token (T), may be responsible for maintaining the rights register storage by recording transactions involving transfers of tokens in the rights register storage.

[0039] 1 , there is shown a system 1 including a first processing device 13 associated with an issuer (I) 3, a second processing device 15 associated with a first user (A) 5, and a third processing device 17 associated with a second user (B) 7. The first processing device 13, the second processing device 15, and the third processing device 17 may communicate with each other via a communications network 8. The first processing device 13 may also have an associated data store 11 and may communicate with the associated data store 11, for example, directly or via the communications network 8.

[0040] Although the first processing device 13 is illustrated as a single node, it will be understood that the first processing device 13 may include one or more nodes associated with the issuer (I) 3, and one or more steps of the method described as being performed by the first processing device 13 may be distributed across and performed at different and / or multiple nodes of the first processing device 13.

[0041] In some embodiments, second processing device 15 and third processing device 17 may be computers, mobile communication devices, or other electronic devices used by first user 5 and second user 7, respectively. In other examples, second processing device 15 and third processing device 17 may be virtual machines accessible by first user 5 and second user 7, respectively, via a terminal or other interface.

[0042] The issuer (I) 3 creates the token and may be, for example, a bank, another financial institution, a mint, a corporation, etc. However, in other examples, the issuer may not be a financial institution, and the present invention is not limited to financial-specific applications. A first user (A) 5 may request that the issuer (I) 3 create a token, redeem some or all of the token's value with the issuer (I) 3, and / or transfer some or all of the token's value to a second user (B) 7. Similarly, a second user (B) 7 may request that the issuer (I) 3 create a token, redeem some or all of the token's value with the issuer (I) 3, and / or transfer some or all of the token's value to the first user (A) 5.

[0043] System 1 also includes one or more processing devices 19 for managing a peer-to-peer distributed ledger (blockchain) 9 for recording transactions. In particular, one or more processing devices 19 may be configured to receive transactions and record the transactions, e.g., from first processing device 13, second processing device 15, and / or third processing device 17, respectively, via communications network 8. An example of a peer-to-peer distributed ledger 9 includes a blockchain, which is a distributed network of transactions (TXs) based on the Bitcoin protocol. Accordingly, in some embodiments, one or more processing devices 19 may be associated with a "miner." Accordingly, the present invention includes one or more processing devices 19 in communication with a blockchain-implemented distributed network. The network and various devices intercommunicate to implement the present invention.

[0044] In some embodiments, system 1 also includes one or more processing devices 21 for managing a rights registration database 23 for recording transactions associated with transfers of tokens. The one or more processing devices 21 may communicate with first processing device 13, second processing device 15, and / or third processing device 17, and / or one or more processing devices 19 via communications network 8. In particular, the one or more processing devices 21 may be configured to receive and record data related to transactions including transfers of tokens (T).

[0045] Overview of transactions involving tokens There are three general types of transactions involving tokens: creation of a token by an issuer (I) 3; redemption of some or all of the token's value with an issuer (I) 3 by a first user (A) 5 or a second user (B) 7; and transfer of some or all of the token's value by a first user (A) 5 or a second user (B) 7 to a second user (B) 7 or a first user (A) 5.

[0046] Referring to FIG. 2, the creation of a first token (T1) generally involves a first user (A) transferring fiat currency (e.g., $1,000 AUD) to an issuer (I) 3, and in exchange for the fiat currency, the issuer (I) “tokenizes” a first cryptocurrency amount (B1) so that it has a token value and transfers the first cryptocurrency amount (B1) to the first user (A). The first token (T1) may represent a contract, such as a contract in which the issuer (I) agrees to redeem a specified fiat currency amount (e.g., $1,000 AUD) for the holder of the first token (T1). Thus, the first token (T1) may be similar to a negotiable instrument. Depending on the specific terms, the first user (A) 5 may be able to redeem the first token (T1) in the future for a value associated with the deposited fiat currency. Such terms may also permit a first user (A) 5 to transfer at least a portion of the value of the token to a second user (B). Such terms may be specific to the token or may be general terms between the users 5, 7 and the issuer (I) 3.

[0047] Overview of how to create a token A method 300 for creating a token is described in detail below with reference to Figures 2 and 3. In particular, the method 300 includes, at 310, allocating a first cryptocurrency amount (B1) for association with a first token (T1). The method further includes, at 312, determining a first hash (H1) of a first redemption script (RS1), where the first redemption script (RS1) is based on at least first metadata (MD1) including information associated with the first token (T1), a first user public key (P1A), and a first issuer public key (P1I) associated with the issuer (I), the first issuer public key (P1I) forming a cryptographic pair with a first issuer private key (V1I). The method 300 also includes, at 314, transmitting the first data output (O1) to the blockchain 9 via the communication network 8. The first data output (O1) includes an indication of a transaction of the first cryptocurrency amount (B1) to the first user (A) 5 and a first hash (H1) associated with the first cryptocurrency amount (B1) to provide a first token (T1) associated with the first user (A) 5 and the issuer (I).

[0048] Thus, the method 300 enables the creation of a token, thereby allowing a record of the token to be transmitted to the blockchain 9. An advantage of recording this transaction on the blockchain 9 is that it may allow a recipient, such as the first user (A) 5, to verify the existence of the token (T1). Furthermore, because at least the first metadata (MD1), which includes information associated with the first token (T1), is hashed, this allows for verification of the transaction (on public record) against the information associated with the token. In one example, the information associated with the first token (T1) may be the terms of a contract. Thus, including the terms in the hashed first redemption script may advantageously provide the first user (A) 5 (or any other user) with peace of mind that any changes cannot alter the terms in a way that would alter the first hash (H1). Because the first hash (H1) was transmitted and recorded on the blockchain 9 when the first token (T1) was created, it is impossible (or difficult) to change the terms at a later time to provide the same first hash (H1).

[0049] Detailed instructions on how to create a token Referring to Figure 3, a method 300 for creating a first token (T1) is shown, according to some embodiments. In this example, the creation of the token is described in the context of a first user (A) 5 depositing cash with an issuer (I) 3 in exchange for a token representing the deposited cash. However, it should be understood that this is a non-limiting example, and that tokens may be created in the context of other transactions. For example, a token may represent any other contract, negotiable instrument, tangible property, etc.

[0050] Agreement on Token Terms At 302, a first user (A) 5 initiates the creation of a first token (T1) by sending a request for the first token (T1) from a second processing device 15 to a first processing device 13 associated with an issuer (I) 3. In one example, the first user (A) 5 makes this request by depositing fiat currency, such as $1000 AUD, with a request to have this amount in the token (T1). The request may include an offer for a contract, which may include one or more terms of the contract. For example, the first user (A) 5 may include in the request that the token associated with the $1000 AUD deposit should have a fixed pegging rate to the cryptocurrency. For example, the request is for the pegging rate to be 1000 satoshis / cent (AUD). It should be understood that other terms may be included in the offer, such as how the token can be redeemed, account maintenance fees, transaction fees, etc.

[0051] The first processing device 13 of the issuer (I) receives 304, via the communications network 8, a request from the first user (A) 5 for the first token (T1), and in some cases receives at least some of the terms. In some embodiments, the issuer (I) decides 306 whether to accept the request, propose a counter-offer including changes to the terms of the request, or reject the request. In some embodiments, method 300 may include the issuer (I) transmitting, via the communications network 8, a result of the decision in step 306 to the first user (A) 5.

[0052] In some embodiments, the request sent to the issuer (I) may simply include a request for the first token (T1). In this case, the issuer (I) may send an offer, including terms, to the first user (A) 5. The first user (A) 5 may then decide whether to accept the offer, propose a counteroffer, or reject the offer, which is then sent to the issuer (I). It will be appreciated that multiple rounds of offers and counteroffers may be sent back and forth between the issuer (I) and the first user (A) 5 until the issuer (I) and the first user (A) 5 agree. In some embodiments, the terms may be standardized, whereby users accept the terms by performing the steps in method 300. In one example, the issuer (I) may have standardized offers for tokens for its customers, including the first user (A) 5. Such offers for tokens may be publicly listed, for example, on a public exchange or on the issuer's website. The standing offers may be provided confidentially by the issuer (I) to the first user (A) 5, for example, by email, through an application, or by logging into a secure website. The terms and conditions associated with the token may be stored in the data store 11, transmitted to a third party for storage, or torrented. In some embodiments, the terms may be stored in a distributed hash table (DHT).

[0053] Determining the first user's public key The method 300 includes, at 308, determining a first user public key (P1A) of a cryptographic pair associated with the first user (A) 5, where the cryptographic pair includes a first user private key (V1A) and a first user public key (P1A). In one example, the first user public key (P1A) may be transmitted from the first user (A) 5 to the issuer (I) via the communications network 8. In another example, the first user public key (P1A) may be stored in the data store 11 (e.g., received and stored during registration of the first user (A) 5). Thus, determining 308 the first user public key (P1A) may include retrieving this key from the data store 11. In yet another example, the first user public key (P1A) may be received via the communications network 8 from a third party. The third party may include, for example, a trusted third party that functions as a public directory, such as a certificate authority.

[0054] First cryptocurrency amount allocation for association with tokens The method 300 includes allocating 310 a first cryptocurrency amount (B1) for association with a first token (T1). In order for a record of a transaction involving the first token (T1) to be recorded on a peer-to-peer distributed ledger (in this example, a blockchain), the token must be associated with the cryptocurrency amount, and the cryptocurrency amount is recorded on the blockchain as a transaction from an issuer (I) 3 to a first user (A) 5.

[0055] The allocation of the first cryptocurrency amount (B1) for association with the first token (T1) may be based on a ratio of token values. For example, a pegging rate (PR1) may be specified for the first token (T1). Thus, allocating the first cryptocurrency amount (B1) at 310 may include determining the first cryptocurrency amount (B1) based on the pegging rate (PR1) and the first token value (TV1). As an illustrative example, the pegging rate (PR1) may be 1,000 satoshis / cent (AUD) and the first token value (TV1) is $1,000 AUD. Thus, the first cryptocurrency amount (B1) may be 10,000,000.

[0056] The cryptocurrency amount allocated for a token may be influenced by several of the following considerations. First, the allocated cryptocurrency amount ideally has a market value lower than the value of the token (the “token value”) (for this purpose, this means the market value of the cryptocurrency itself, assuming it has a value, without reference to the token value). This is desirable because it disincentivizes using the cryptocurrency amount for its underlying value rather than as a token. This may be similar to cash coins, where it is desirable to have the face value of the cash coins to be higher than the metal from which they are minted, so that there is no desire to melt the cash coins due to the value of the metal. In some examples, the token value is several times greater than the underlying value of the cryptocurrency amount. However, it should be understood that some tokens may not have a fixed or easily determinable token value. For example, a token may represent a contract to perform work, whereby the value may vary from day to day. In other examples, the contract may only have a value that is determinable on the day it is redeemed.

[0057] Another consideration is that the allocated cryptocurrency amount should not be too large relative to the token value or transaction value, because recording a cryptocurrency amount transaction on a peer-to-peer distributed ledger can be costly, such as incurring transaction fees. In some instances, transaction fees are based on the amount of cryptocurrency in the transaction, and therefore it may be desirable to keep the cryptocurrency amount for the token at a minimum level.

[0058] On the other hand, the cryptocurrency amount allocated for association with a token cannot be infinitesimal. First, a cryptocurrency may have a minimum currency unit amount; for example, Bitcoin has a minimum amount of 1 satoshi (where 1 Bitcoin (BTC) = 10,000,000 satoshis). Second, cryptocurrency transactions may be limited to a minimum size, or they will not be recorded (or the cost of the transaction may approach or exceed the cost of executing the transaction). This minimum amount, in some examples, is a “dust” limit. Thus, in some examples, allocating a cryptocurrency amount for a token must be equal to or greater than the minimum threshold amount (MT1) of the cryptocurrency. Thus, a method may include determining a minimum threshold amount (MT1) of the cryptocurrency appropriate for a first token (T1) and determining a first cryptocurrency amount (B1) that is equal to or greater than the minimum threshold amount (MT1) of the cryptocurrency. In one example, the minimum threshold amount (MT1) of the cryptocurrency for Bitcoin is 546 satoshi.

[0059] Another consideration when assigning a cryptocurrency amount for a token is the divisibility of the cryptocurrency for subsequent tokens. For example, a first token (T1) may have a token value (TV1) of $1000 AUD, and a first user (A) 5 may wish to transfer $800 AUD of this token value to a second user (B) 7 and retain the remaining $200 AUD token. Such a transaction would involve a transaction using the first token (T1) resulting in a second token (T2) representing $200 AUD that remains with the first user (A) 5, which creates a third token (T3) representing $800 AUD that is transferred to the second user (B) 7. The result of this transfer is therefore two tokens, the second token (T2) and the third token (T3), where each of these tokens must also be assigned a cryptocurrency amount. If the first cryptocurrency amount (B1) is a minimum, such as a "dust" limit, then additional cryptocurrency amounts need to be provided so that each new token created is also associated with a cryptocurrency amount sufficient to meet the minimum threshold amount. Thus, there may be an advantage to allocate a sufficient cryptocurrency amount (B1) for the first token (T1) so that the amount is sufficient to be divided to be used for the expected number of subsequent tokens.

[0060] In one example, the condition may specify a cryptocurrency amount, or a minimum value or currency unit of a token. For example, the condition may set the minimum currency unit of the token value at $10 AUD. Thus, allocating a first cryptocurrency amount (B1) for a first token (T1) having a token value (TV1) of $1000 AUD may include determining a first amount that ensures that there is enough cryptocurrency when the total token value (TV1) is divided into the minimum currency unit. In this example, the token value (TV1) may be divided into 100 subsequent tokens (calculated as $1000 / $10). Thus, an appropriate first cryptocurrency amount (B1) may be 100 times the "dust" limit.

[0061] Determining the first hash (H1) of the first redemption script (RS1) The method 300 further includes determining a first hash (H1) of the first redemption script (RS1) at 312. In one example, the hash of the redemption script can be used to provide a pay-to-script hash (P2SH) address for a pay-to-script hash transaction. Examples include hash functions used in P2SH scripts in the Bitcoin protocol. This can include a combination of SHA256 and SHA256 followed by RIPEMD160.

[0062] The first redemption script (RS1) is a script that can be used to unlock a first token (T1) that includes a transaction of a first cryptocurrency amount (B1), as described below. When unlocking the first token (T1), certain conditions in the first redemption script (RS1) must be met to unlock the transaction. In particular, signatures of the first user (A) 5 and the issuer (I) are required. An example of the first redemption script (RS1) will now be described.

[0063] First Redemption Script (RS1) The first redemption script (RS1) is based on at least first metadata (MD1) including information associated with the first token, a first user public key (P1A), and a first issuer public key (P1I).

[0064] (i) Overview of the P2SH redemption script By way of background, in a Pay-to-Script Hash (P2SH) method, the redemption script may take the following form: <NumSigs PubK1 PubK2 ... PubK15 NumKeys OP_CHECKMULTISIG> where: NumSigs is the number of valid signatures, m, required to satisfy the redemption script to unlock the transaction, PubK1, PubK2, ..., PubK15 are the public keys corresponding to the signatures that unlock the transaction (up to 15 public keys), NumKeys is the number of public keys "n" (must be 15 or less).

[0065] To unlock the above redemption script, at least "m" signatures corresponding to the public keys are required. In some instances, the order of the public keys is important, and m out of n signatures for signing must be done in order. For example, suppose "m" is 2 and the number of public keys "n" is 15. Given two signatures available, namely, Sig1 (corresponding to PubK1) and Sig15 (corresponding to PubK15), the redemption script must be signed first by Sig1, followed by Sig15.

[0066] (ii) First Redemption Script (RS1) using P2SH Returning to this example, a first redemption script (RS1) using P2SH may include at least first metadata (MD1) within the redemption script. Specifically, at least first metadata (MD1) may be embedded in one or more of the 15 locations available for the public key within the redemption script.

[0067] Thus, in one example, the first redemption script (RS1) may take the following form: <NumSigs Metadata1 Metadata2...PubK1 PubK2...NumKeys OP_CHECKMULTISIG> where: NumSigs is the number of valid signatures, m, required to satisfy the redemption script to unlock the transaction, Metadata1 and Metadata2 contain metadata that occupies the location of the public key; PubK1 and PubK2 are actual public keys, in one example, PubK1 may be a first user public key (P1A), and PubK2 may be an issuer public key (P1I); NumKeys is the total number of locations occupied by metadata and public keys (must be less than or equal to 15).

[0068] The advantage of this is that the metadata will be included in the first redemption script (RS1), which in turn will be hashed and this record will be included in the blockchain 9. It is therefore difficult, if not impossible, to change the value of the metadata without causing a change in the corresponding hash of the first redemption script hash (RS1).

[0069] A practical advantage can be illustrated by the following example: A first user (A) 5 and an issuer (I) 3 may wish to enter into a contract with certain conditions. The contract may involve the issuer (I) creating a token, whereby the certain conditions are included in metadata embedded in a redemption script. A hash of the redemption script is then recorded on the blockchain 9, becoming a record of the transaction that is difficult or impossible to change. Suppose the issuer (I) attempts to deceive the first user (A) 5, for example, by changing a term, and claims that the changed term was present in the originally agreed-upon contract. The first user (A) 5 may be able to dispute this by placing the changed term in the redemption script's metadata, hashing it, and then showing that it does not match the redemption script recorded on the blockchain. Thus, including information associated with the token in at least the first metadata may be useful to ensure the integrity of the token.

[0070] It should be appreciated that the metadata in the redemption script may itself include hashes of other information. For example, if the conditions are lengthy, a hash of the conditions may be used to provide shorter metadata.

[0071] The first redemption script (RS1) may be stored as a record in the data store 11 for redeeming the first token (T1). In some alternatives, the first redemption script may be transmitted to the first user (A) 5 or a third party.

[0072] Metadata In this example, the first redemption script (RS1) may take the following form: <2 Metadata1 Metadata2 P1A P1I 4 OP_CHECKMULTISIG>

[0073] Thus, at least the first metadata (MD1) includes both Metadata1 and Metadata2, which occupy two of the locations in the redemption script. These are followed, in order, by two public keys: the first user public key (P1A) and the first issuer public key (P1I). NumSigs is 2, which means that two signatures are required to unlock the transaction.

[0074] The metadata may include information about the token in several ways. As described, in one example, the terms may be included in the metadata. In another example, a hash of the terms may be included in the metadata. In yet another example, the metadata may include a pointer to a file containing the terms of the agreement. In further embodiments, a combination including one or more of the above may be included in the metadata.

[0075] (i) Metadata containing a pointer to the condition A specific example of the first metadata (MD1) is shown in Table 1 below. [Table 1]

[0076] This example includes minimal information about the token and transaction. This example includes providing a pointer to the contract (smart contract), which may be useful if the size of the contract (smart contract) prohibits including such details in the metadata. Furthermore, because metadata may be publicly available or may be transmitted over insecure networks, it may be desirable for specific details of the token to be hidden or kept secret for privacy reasons.

[0077] The first four bytes of Metadata1 indicate the type of contract. For example, the contract type might be for "Fiat Currency." The next 16 bytes hold the IP address of the location of the actual electronic contract file, allowing IPv6 addresses. Note that in some embodiments, this value may point to the seed of a torrent file so that the contract file can be distributed across the cloud rather than centrally managed. The next 12 bytes contain data specific to the type of contract.

[0078] The first 20 bytes of Metadata2 are a hash of the actual contract file using SHA256 and RIPEMD-160 applied to the actual contract file. Since the actual contract file is searchable and retrievable, this allows for verification of transactions against the contract. The contract file itself may be fully public (unencrypted and human readable) or encrypted for privacy, depending on the requirements of the specific implementation. The contents of the remaining 12 bytes of Metadata2 may be used depending on the type of contract.

[0079] (ii) Metadata containing key parameters of the token Another example of the first metadata (MD1) is shown in Table 2 below. [Table 2]

[0080] In this example, several key parameters of the token are included in the metadata. Depending on the key parameters, this may include information related to the token itself or information that can assist in processing the transaction. In particular, the bytes allocated to the subfield "ContractTypeData1" in Table 1 above are used to indicate the fiat currency (FiatDenomination), pegging rate (PeggingRate), and transaction type (TransactionType).

[0081] Including key parameters in the metadata can contribute to greater processing efficiency as the issuer (I) 3 can, in some cases, process the token in a transaction without having to search the agreement file for key information needed to process the transaction.

[0082] In addition to the above information, other information related to the token's history, i.e., tokens that preceded it, may also be included. For example, if a first user (A) 5 wants to redeem a portion of a first token (T1) and a second token (T2) is created by an issuer (I) to represent the value of the remaining portion, the issuer can embed information in the metadata that associates the second token (T2) with the first token (T1). This can help the issuer (I), such as a bank, to understand and track the tokens without having to spend time tracing the transaction history, which can be an intensive task for the issuer (I).

[0083] In Table 2, the metadata includes a two-byte field indicating the fiat currency (FiatDenomination) and a one-byte field called PeggingRate. The pegging rate is set by the issuer (I). Several different rates may be set for the same fiat currency, but a different token (with a different contract) would be required for each different rate. The rate selection is at the discretion of the issuer (I), but the issuer (I) may give the same consideration to the pegging rate as it does to the allocation of cryptocurrency amounts for tokens described above.

[0084] In one example, PeggingRate is an 8-bit code value such as: The leftmost bit is used as a flag: Rate expressed as 1 = satoshis / cent (a "cent" is one-hundredth of a legal tender amount and is the minimum legal amount) 0 = rate expressed as cents / satoshi The right 7 bits represent the rate as a power of 10 in binary, e.g.: USD 10000010 means a rate of 100 satoshis / cent (flag is on) PHP 00000000 means a rate of 1 centavo / satoshi (flag off) IDR 00000001 means a rate of 10 rupiah / satoshi (flag is off)

[0085] In one example, TransactionType is a one-byte field that indicates whether the transaction is an "issue" (tokens are created from cryptocurrency), a payment (at least a portion of the token value is transferred from one user to another), or a redemption (tokens are transferred to the issuer (I) and redeemed back for legitimate cryptocurrency).

[0086] In some examples, the "Padding" in Metadata1 and Metadata2 includes randomly generated values ​​for each transaction. The result is that each of Metadata1 and Metadata2 changes between transactions. The advantage is that this may reduce the risk and incentive for a malicious individual to attempt to determine which private keys would match one or both of Metadata1 and Metadata2 as a cryptographic pair (for the purpose of using such private keys to sign a redemption script). This may be important for standardized tokens where the rest of Metadata1 or Metadata2 is largely the same.

[0087] public key The first user public key (P1A) and the issuer public key (P1I) are paired with a corresponding first user private key (V1A) and issuer private key (V1I), respectively. In some embodiments, the public keys may be publicly known, while in other embodiments, it may be preferable to communicate the public keys as needed.

[0088] In some embodiments, the issuer (I) is a financial institution that manages electronic wallets for a first user (A) 5 and a second user (B) 7, and the first user (A) 5 and the second user (B) can access their respective electronic wallets via a virtual machine environment or a terminal. The electronic wallets may be hosted by the issuer (I) 3 (or a server associated with the issuer (I) 3), and one or more private keys of the corresponding users are stored in the data store 11 but can only be accessed (or recreated) by the issuer (I) 3 with permission from the users. In such cases, the first user 5 and the second user 7 can authorize their private keys to be provided to the issuer (I) 3 to unlock redemption scripts. This may include authorizing one or more of the user's private keys to be sent to the first processing device 13 of the issuer (I) 3, which can unlock the redemption script using the user's one or more private keys (e.g., P1A, P1B) and the first issuer public key (P1I).

[0089] Sending the first data output (O1) to the blockchain The method 300 further includes, at 314, transmitting, by the issuer (I) 3, a first data output (O1) to the blockchain 9 via the communications network 8. This first data output (O1) may include an indication of a transaction transferring a first cryptocurrency amount (B1) to the first user (A) 5, i.e., recording that the underlying cryptocurrency amount (B1) associated with the first token (T1) has been transferred to the first user (A) 5. The first data output (O1) also includes the first hash (H1) described above. The first hash (H1) is associated with the first cryptocurrency amount (B1) to provide a record of the first token (T1) associated with the first user (A) 5 and the issuer (I). Thus, the first hash (H1) may be recorded on the blockchain 9 and used to prove or verify the existence of the token (T1), the relationship between the issuer (I) and the first user (A) 5, and / or the terms of the token.

[0090] The method 300 may also include storing the first redemption script (RS1) in the data store 11 for later use.

[0091] An example of a transaction that creates a first token (T1) will now be described with reference to FIG.

[0092] A first user (A) 5 deposits $1000 AUD to the issuer (I) for the equivalent value in tokens. In this example, a first user (A) 5 wishes to deposit $1000 AUD with an issuer (I), who, in exchange, creates a first token (T1) having a token value (TV1) of $1000 AUD by associating the first token (T1) with a first cryptocurrency amount (B1) of 10,000,000.

[0093] To create a token, the issuer (I) needs to have cryptocurrency, which may be provided from a previous transaction or in response to a request from a first user (A) 5 for a first token (T1). This is shown on the left side of Figure 2 as "First (non-token) cryptocurrency amount."

[0094] Table 3 below shows the originating transaction output in the form of transaction ID / satoshi amount / locking script. This originating transaction output represents cryptocurrency acquired by the issuer (I) from a previous transaction, at least a portion of which will be used to associate with the first token. [Table 3]

[0095] The first line, "ID-201", is the transaction identifier that identifies this transaction. The next line is the number of satoshis in this transaction, which is 50,000,000. The third line is the locking script (output script) for this transaction. The redemption script for this output<PubK-Issuer hash> indicates that this output is locked using the first issuer public key (P1I), i.e., the transaction can be unlocked using the issuer's corresponding first issuer private key (V1I).

[0096] As described above, method 300 includes, at 310, allocating a first cryptocurrency amount (B1) appropriate for the first token (T1). However, the cryptocurrency amount available to the issuer (I) may not exactly match the first cryptocurrency amount (B1). In this example, the required first cryptocurrency amount (B1) is 10,000,000, much less than the 50,000,000 from transaction ID-201. Therefore, the transaction creating the first token (T1) may include providing cryptocurrency change back to the issuer (I) for the excess cryptocurrency amount not needed for this token. Additionally, token creation may be a transaction that requires payment of a transaction fee to a miner. This is illustrated with reference to Table 4 below, which shows a transaction creating a token. [Table 4]

[0097] The first line, "ID-210," is a transaction identifier that identifies this transaction. The second line indicates the "version number," which describes the version of the Bitcoin protocol used. The third line indicates the number of inputs for this transaction, which indicates one input.

[0098] Lines 4 through 7 in Table 4 relate to the "input," i.e., the previous transaction ID-201 that funds the current transaction ID-210. Line 5, "IDX-00," is the index of the output of the previous transaction ID-201 (in this case, a reference that the first output from the previous transaction ID-201 should be used). Line 6 is the "ScriptSig," which is the unlocking script for the previous transaction ID-201. As mentioned above, the previous transaction was locked using the first issuer public key (P1I), represented by PubK-Issuer. Therefore, the previous transaction can be unlocked using the issuer's corresponding first issuer private key (V1I), represented by Sig-Issuer. Line 7 is the sequence number associated with the input. In Bitcoin transactions, each Bitcoin transaction contains a 4-byte field called "Sequence Number," which is no longer used by Bitcoin Core. Depending on the issuer's implementation, an option is to use this field to assign transaction inputs to outputs. The sequence number can represent a string of one-bit flags, whereby the position of each flag, starting with the right-most bit, indicates that the input contributed some of its funds to the output that the flag is set to. In this example, the sequence number "00000000000000000000000000000011" indicates that the input is credited to outputs 1 and 2, as explained below.

[0099] Row 8 in Table 4 indicates the number of outputs for this transaction, which is 2. Rows 9-11 represent the first output, and rows 12-14 represent the second output.

[0100] The first output reflects the first cryptocurrency amount (B1) associated with the first token (T1). Line 9 is the output value of the first cryptocurrency amount (B1), which is 10,000,000 satoshis. Line 10 shows the output script length. Line 11 is the output script, i.e., the locking script that locks the first cryptocurrency amount (B1). It contains the first hash (H1) of the first redemption script (RS1), which is represented by: OP_HASH160<redeem script hash> OP_EQUAL

[0101] "OP_HASH160" is the type of hash function, where the input is hashed twice, first with SHA-256 and then with RIPEMD-160. The redeem script hash is the hash of the first redeem script (RS1) in the form described above, which in this example is: 2 metadata1 metadata2 P1A P1I 4 OP_CHECKMULTISIG

[0102] This includes the first user public key (P1A) and the first issuer public key (P1I), as described above. metadata1 and metadata2 may include the metadata described above, including an indication that this is an "issue" transaction. OP_EQUAL provides a Boolean result for validating the output.

[0103] The second output reflects the issuer's change for the transaction. Since the previous input, transaction ID-201, contained 50,000,000 satoshis, the issuer (I) can expect to receive some leftover satoshis. Line 12 is the output value for the second output, which is 39,999,000. Line 13 is the output script length, and line 14 is the output script for the second output. Since the second output is the change returned to the issuer (I), the issuer should be free to use the second output. Therefore, the output script (i.e., the locking script) is:<PubK-Issuer hash> The first issuer public key (P1I) is represented by

[0104] Generally, one or more output values ​​of a transaction must be less than or equal to its input. In the example above, the input is 50,000,000 and the output is 49,999,000 (based on the first output of 10,000,000 and the second output of 39,999,000). Therefore, there is a shortfall of 1,000 satoshis. In this example, the 1,000 satoshis is the transaction fee (e.g., the miner's fee).

[0105] Summary of the redemption by the first user (A) of part or all of the value of the tokens with the issuer (I). Generally, tokens are redeemed with an issuer (I) 3. In some embodiments, when the issuer (I) is a service provider that provides electronic wallets for users 5, 7, the users' private keys are kept secure in a data store 11 associated with the issuer (I). Thus, in such embodiments, the users 5, 7 (or their respective processing devices 15, 17) do not sign the redemption script. Instead, the issuer (I) 3, having obtained permission from the users 5, 7, signs the redemption script. For example, a first user (A) 5 may send a request to redeem a token to the issuer (I) 3; implicitly or explicitly, this request to redeem the token also includes permission from the first user (A) 5 for the issuer (I) 3 to use the first user's private key (V1A) to redeem the token.

[0106] A method for redeeming a first token (T1) may include receiving, by the issuer (I) 3, a request to redeem the first token (T1) from a first user (A) 5 via the communications network 8, determining a first redemption script (RS1) associated with the first token (T1), and obtaining a first user private key (V1A), for example from the data store 11 or another entity or node. The issuer may then sign the first redemption script (RS1) using the user private key (P1A) and the first issuer private key (P1I). This may be advantageous because the issuer (I) 3, which is a service provider for the first user (A) 5, can perform these steps securely on the first processing device 13 without transmitting the signed or unsigned first redemption script (RS1) via the communications network 8.

[0107] The method may also include transmitting a second data output (O2) to the blockchain 9 via the communications network 8, the second data output (O2) including an indication of the transaction of the first cryptocurrency amount (B1) to the issuer (I). Thus, the method returns the first cryptocurrency amount (B1) associated with the first token (T1) to the issuer (I). In one example, because the first redemption script (RS1) is signed with the private keys of both the first user (A) and the issuer (I), the recipient of the first cryptocurrency amount (B1) in this transaction, i.e., the issuer (I) 3, can subsequently use the first cryptocurrency amount (B1) for other transactions (whether cryptocurrency alone or with other associated tokens).

[0108] A first user (A) transfers part or all of the value of the tokens to a second user (B). In some embodiments, one or more additional tokens may be created to enable a first user (A) 5 to transfer the value of the first token (T1) or a portion thereof to a second user (B). For example, a third token (T3) may be created that is associated with a second user (B) 7 and an issuer (I) 3. This may advantageously enable the first user (A) 5 to, in effect, transfer the same or similar rights associated with the first token (T1) to the second user (B). Although a new token in the form of the third token (T3) is created, the third token (T3) may have similar characteristics as the first token (T1). For example, these tokens may have the same or similar associated metadata. This may be useful, for example, when the same or similar terms applicable between the first user (A) 5 and the issuer (I) 3 should also apply between the second user (B) 7 and the issuer (I) 3.

[0109] In one example, a first user (A) 5 may wish to transfer the entire value of a first token (T1) to a second user (B). Such a case may involve the creation of a third token (T3) associated with the first cryptocurrency amount (B1) to be transferred to the second user (B) 7. Advantageously, the third token (T3) is a transfer of the first token (T1) and the rights associated with the first token (T1) to the second user (B) 7.

[0110] In a further example, only a first portion (R1) of the total value of the first token (T1) may be transferred to the second user (B) 7, in which case the remaining second portion (R2) of the total value may be included in the second token (T2) refunded to the first user (A) 5. Thus, a request to create a third token (T3) may explicitly or implicitly include a request to create a third token (T3) having a third token value (TV3) based on the first portion (R1).

[0111] The transfer of tokens by a first user (A) to a second user (B) without the involvement of an issuer (I) or any other third-party intermediary. In the example described in the section above, the transfer of token value from a first user (A) 5 to a second user (B) involves the issuer (I) 3 as an intermediary to facilitate the transfer, which is distinct from a direct transaction of a first cryptocurrency amount (B1) from the first user (A) 5 to the second user (B) 7.

[0112] However, in some cases, it may be desirable for a first user (A) 5 to transfer the value of tokens to a second user (B) 7 without the involvement of an issuer (I) or other third-party intermediary. For example, such a situation may arise when the second user (B) 7 does not have a service provider, or when the service provider of the second user (B) 7 is not within the same web of trust as the service provider of the first user (A) 5 or the issuer (I) 3 responsible for creating the tokens. In such embodiments, the second user (B) 7 may wish to take precautions to ensure the legitimacy or validity of the tokens being transferred.

[0113] Generally, if the second user (B) 7 has a service provider (SPB) in the same web of trust as the service provider (SPA) of the first user (A) 5, the service provider (SPB) acts as a signer for the transaction of using or redeeming the token, and therefore the second user (B) 7 is confident of the authenticity or validity of the token. However, if the second user (B) 7 does not have a service provider (SPB) or does not have a service provider (SPB) in the same web of trust as the service provider (SPA) of the first user (A) 5, the issuer (I) or an authorized party is not available to attest to the authenticity or verify the validity of the transaction.

[0114] Accordingly, second user (B) 7 may wish to determine the legitimacy of tokens (T1) to be transferred to second user (B) 7. In some embodiments, a verification application including executable computer code is stored in memory 1520 (FIG. 8) of processing device 17 and, when executed by processor 1510 (FIG. 8) of processing device 17, causes processing device 17 to perform methods 600 or 700 for determining the validity of tokens (T) associated with cryptocurrency amounts, described in more detail below with reference to FIGS. 6 and 7, respectively. In some embodiments, second user (B) 7 may manage an electronic wallet (not shown) that may be accessed via a virtual machine environment or terminal associated with processing device 17, and the electronic wallet may include add-on functionality that enables second user (B) 7 to cause processing device 17 to run the verification application.

[0115] A specific example of a transaction transferring a token (T1) from a first user (A) to a second user (B) will now be described with reference to FIG.

[0116] Transfer of a first token (T1) by a first user (A) to a second user (B) In this example, a first user (A) 5 wishes to transfer a token (T) to a second user (B) 7, as shown in FIG. 4. This results in a transaction of a cryptocurrency amount from the first user (A) 5 to the second user (B) 7, which is hereinafter referred to as transaction ID-510. The transfer of the cryptocurrency amount to the second user (B) 7 allows the second user (B) 7 to subsequently use the cryptocurrency amount (B1) as a token for future transactions. The second user (B) 7 can also “detokenize” the cryptocurrency amount (B1) through one or more transactions that remove the metadata (which may include a payment transaction that transferred the cryptocurrency amount (B1) to the second user (B) 7). The second user (B) 7 can then use this cryptocurrency without the restriction of needing authorization (e.g., a signature) from the first user (A) 5 or any other user.

[0117] Before describing transaction ID-510, which transfers the first token, shown in Table 7 below, the source transaction outputs (from transactions ID-500 and ID-400) that are inputs to the current payment transaction ID-510 will be briefly described. These two inputs generally include a cryptocurrency amount associated with the token (T) and another cryptocurrency amount used to pay the transaction fee (e.g., a miner's fee).

[0118] For example, a first user (A) 5 receives a cryptocurrency amount in transaction ID-500. The output to first user (A) 5 in transaction ID-500 can be summarized as follows: [Table 5]

[0119] Line 2 in Table 5 represents the cryptocurrency amount associated with the token (T), which is 10,000,000 satoshis. Line 3 represents the output script, which is equivalent to line 11 in Table 4 above.

[0120] First user (A) 5 may also need to pay a transaction fee (e.g., a miner's fee) for payment transaction ID-510, which is paid in part from the cryptocurrency amount received from previous transaction ID-400. This cryptocurrency amount may be summarized as follows: [Table 6]

[0121] Row 2 of Table 6 shows the cryptocurrency amount from a previous transaction, which is 1000. Row 3 of Table 6 is the output script from this previous transaction. Because the cryptocurrency from this transaction ID-400 is not associated with a token (or the user associated with the token), the redemption script hash is simply a hash of the first user's public key (P1A), shown as PubK-Alice. That is, to use the output from transaction ID-400, it simply requires a signature with the first user's private key (V1A).

[0122] Transaction ID-510, which transfers the first token (T1), is now described with reference to Table 7 below. [Table 7]

[0123] Line 1, "ID-510," is a transaction identifier that identifies this transaction. The second line indicates the "version number," which describes the version of the Bitcoin protocol used. Line 3 indicates the number of inputs for this transaction, showing two inputs.

[0124] Rows 4-8 in Table 7 relate to the first input, i.e., previous transaction ID-500, which funds the current transaction ID-510. Row 4 is the transaction identifier for previous transaction ID-500. Row 5, "IDX-00," is the index of the output of previous transaction ID-500 (in this case, a reference that the first output from previous transaction ID-500 should be used). Row 6 is "Script length," which is an indication of the script length. Row 7 is "ScriptSig," which is the unlocking script for previous transaction ID-500. As shown, previous transaction ID-500 was locked using a first user (A) public key (P1A), represented by PubK-Alice, and a first issuer public key (P1I), represented by PubK-Issuer. Thus, the previous transaction can be unlocked using Alice's corresponding private key (V1A), denoted as Sig-Alice, and the issuer's corresponding first issuer private key (V1I), denoted as Sig-Issuer. Line 8 is the sequence number associated with the input.

[0125] The first user (A) also needs to pay a transaction fee (e.g., a miner's fee) for transfer transaction ID-510, which is paid in part from the cryptocurrency amount received from previous transaction ID-400. Rows 11 through 15 in Table 7 relate to the second output, i.e., the payment of the miner's fee. Row 11 is the transaction identifier for previous transaction ID-400. Row 12, "IDX-01," is the index of the output for previous transaction ID-400. Row 13 is "Script length," which is an indication of the script length. Row 14 is "ScriptSig," which is the unlocking script for previous transaction ID-400. Because the cryptocurrency from this transaction ID-400 is not associated with the token (or the user associated with the token), the redemption script hash is simply the hash of the first user's public key (P1A), denoted as PubK-Alice. That is, to use the output from transaction ID-400, it simply needs to be signed with the first user's private key (V1A). Line 15 is the sequence number associated with the input.

[0126] Line 17 of Table 7 indicates the number of outputs for this transaction, which is 1. Lines 18-21 represent outputs reflecting the cryptocurrency amount associated with the token (T). Line 18 is the output value of the cryptocurrency amount, which in this case is 10,000,000 satoshis. This corresponds to the cryptocurrency amount from the token (T). Line 19 indicates the output script length. Line 20 is the output script, i.e., the locking script that locks the transfer of the token (T) associated with the cryptocurrency amount to the second user (B). It contains the hash (H) of the redemption script (RS) and is represented by: OP_HASH160<redeem script hash> OP_EQUAL

[0127] "OP_HASH160" is the type of hash function, where the input is hashed twice, first with SHA-256 and then with RIPEMD-160. OP_EQUAL provides a Boolean result for verifying the output. The redeem script hash is the hash of the redeem script (RS) in the form described above, in this example: 1 metadata1 metadata2 PubK-Bob 3 OP_CHECKMULTISIG

[0128] This redemption script includes metadata from the token (T) and the issuer public key (P1I), denoted as PubK-Issuer. Metadata1 and metadata2 may contain the metadata described above, including an indication that this is a "payment" transaction. This redemption script requires one of three signatures to spend the 10,000,000 satoshis. In fact, the second user's private key (V1B) may be used to sign and spend the cryptocurrency for subsequent transactions. It is noteworthy that the first user's public key (P1A) is not present in this redemption script. This indicates that the token (T), and therefore the associated cryptocurrency amount, has been transferred to the second user (B) 7 and may therefore be considered spent by the first user (A) 5. Therefore, the second user (B) 7 should be free to spend the token (T) without needing permission (such as implicit permission through the signature of the first user (A) 5).

[0129] In this example, the previous transaction ID-500 (i.e., the unspent transaction output (UTXO)) funding the current transaction ID-510 was signed by issuer (I). Thus, in some embodiments, second user (B) 7 can determine that a first token (T) associated with the cryptocurrency amount associated with transaction ID-510 is valid if the authenticity of the token (T) is attested, e.g., signed, by an authorized signatory, such as issuer (I). For example, a token (T) may be considered to be validated by an authorized signatory if the redemption script (RS) associated with the token (T) and referenced as an input to transaction ID-510 is signed by the authorized signatory or a trusted signer.

[0130] However, consider the case where the service provider (SPA) of first user (A) 5 is not in the same web of trust as issuer (I) and the token (T) associated with transaction ID-510 is not signed by an authorized signatory. In such a situation, the redemption script for previous transaction ID-500, shown in row 7 of Table 7, in this example, would instead take the following form: 1 metadata1 metadata2 PubK-Alice 3 OP_CHECKMULTISIG

[0131] In this embodiment, the redemption script (RS) associated with the token (T), which is referenced as an input to transaction ID-510, is not signed by an authorized signatory, and therefore the second user (B) 7 cannot be certain of the validity of the token (T) by considering the redemption script (RS) referenced as an input alone funding transaction ID-510.

[0132] Title Registration Store 1, in some embodiments, system 1 includes a rights register store 23 that may be controlled or affected by a control / management application executing on one or more processing devices 21. For example, a management application including executable code may be stored in memory 1520 (FIG. 8) of one or more processing devices 21, and one or more processors 1510 (FIG. 8) of one or more processing devices 21 may be configured to execute the management application to perform a method for managing rights register store 23. Rights register store 23 may be configured to record information regarding transactions related to transfers of tokens.

[0133] In some embodiments, the rights registration store 23 maintains a record of changes in ownership of a token (T), i.e., the fact that ownership has changed, without explicitly identifying the current owner of the token (T). Thus, in some embodiments, the rights registration store 23 may include a list or sublist of unspent transaction outputs (UTXOs) that have been validated or verified. For example, when a transaction is recorded in the rights registration store 23, the rights registration store 23 may include an indication of the current owner, i.e., at least one of the transaction identifier and the output script of the transaction, embedded within the metadata of the redemption script hash, including the public key of the current owner. The previous owner may be determined from a public key identified in the unlocking script of the input section of the transaction.

[0134] However, in other embodiments, the rights registration store 23 may additionally or alternatively include identifiers of the current and / or previous owners of the token. For example, the rights registration store 23 may include a "Know Your Customer" (KYC) register of direct and / or indirect clients. In some embodiments, maintaining a KYC register may be a provision in a contract associated with the token, such as a condition of ownership. In such embodiments, a condition of token validity may require a payee, such as second user (B) 7, to register directly with the party (P) or issuer (I). This may be achieved, for example, via an off-block mechanism, such as via a dedicated web page, or by appropriate checks, such as requiring a signature to attest to ownership. In some embodiments, the party (P) or issuer (I) 3 may store this condition in an internal database, such as the data store 11, or in a DHT, such as the DHT configured to store the terms of the contract described above. In some cases, the issuer (I) 3 may need to know the current owner in order to fulfill certain obligations, such as paying any revenue attached to the contract. For example, if the contract relates to joint ownership of a racehorse, the issuer may need to identify the parties to whom a share of the prize money should be paid.

[0135] The one or more processing devices 21 may be configured to receive data from the first processing device 13, the second processing device 15, and / or the third processing device 17, and / or the one or more processing devices 19, via the communications network 8, and store the data in the rights registration store 23. Similarly, the one or more processing devices 21 may be configured to retrieve data from the rights registration store 23, for example, in response to a request for the data and / or automatically, such as at predetermined or periodic intervals, and provide the retrieved data to the first processing device 13, the second processing device 15, and / or the third processing device 17, and / or the one or more processing devices 19, via the communications network 8.

[0136] In some embodiments, recording a transaction in the rights register store 23 involving the transfer of a token (T) issued by the issuer (I) 3 is initiated by the issuer (I) 3 of the token (T). For example, upon creating a token (T) for a user, such as first user (A) 5 or second user (B) 7, and sending the first data output (O1) described above at 314 in connection with method 300 of creating a token, to the blockchain 9, the issuer (I) 3 uses one or more processors 13 to send a request to one or more processors 21 associated with the rights register store 23 via the communications network 8 to a management application of the rights register store 23 to record the transfer of the token. The issuer of the token may also be responsible for maintaining or updating the rights register store 23 with respect to transactions associated with the token, as described in more detail below.

[0137] In some embodiments, the rights registration store 23 may include a distributed hash table (DHT). In some embodiments, the distributed hash table (DHT) may be configured to store agreements associated with tokens. In some embodiments, the distributed hash table (DHT) configured to store agreements associated with tokens may include fields containing one or more links or pointers to the location of associated entries in the distributed hash table (DHT) of the rights registration database 23.

[0138] Maintaining the title registration store Generally, one or more parties (P) are responsible for updating the rights registration store 23 to maintain or keep an accurate record of token transfers, and therefore token ownership changes. In some embodiments, each issuer (I) 3 of a token (T) is responsible for maintaining an accurate record of ownership changes of that token in the rights registration store 23, i.e., a record of transactions involving token transfers that have occurred.

[0139] A method 500 of maintaining a rights register store 23 for recording transfers of tokens issued by an issuer (I), where each token is associated with a cryptocurrency amount, will now be described with reference to Figure 5. In some embodiments, a rights register maintenance application including executable code may be stored in memory 1520 (Figure 8) of one or more processing devices 13, and one or more processors 1510 of the one or more processing devices 13 may be configured to execute the rights register maintenance application to perform the method 500 for maintaining a rights register store for recording transfers of tokens. In other embodiments, method 500 may be performed by a processing device (not shown) associated with an authorized party (P) connected to communications network 8.

[0140] When performing method 500, the maintenance application is configured to monitor 502 the blockchain 9 for transactions involving transfers of tokens issued by an issuer (I).

[0141] A blockchain 9, such as the Bitcoin blockchain, records transactions and may include details of the transactions (TXs), such as an identifier of a previous transaction (a previous transaction identifier), one or more input scripts, and one or more output scripts. As described above, the token associated with a transaction may be determined from metadata in the transaction's input script.

[0142] In response to determining a transaction involving a transfer of a token (T) issued by the issuer (I), the maintenance application is configured to record the transfer of the token (T) in the rights register store 23. For example, in some embodiments, as shown in FIG. 5 , the maintenance application is configured to send a request to record the transfer of the token (T) in the rights register store 23 to a management application hosted by one or more processing devices 21 associated with a second party (P2) responsible for managing the rights register store 23.

[0143] In some embodiments, the request may include data including an indicator of the transaction involving the transfer of the token (T). For example, this data may include a transaction identifier and / or a first data output (O1) of the transaction. In some embodiments, this data has been authenticated by the issuer (I) 3, for example, in that it has been signed with the issuer's signature (V1I). This data may be obtained from token transaction details recorded on the blockchain 9.

[0144] In some embodiments, in response to receiving 508 a request by a second party (P2) from a first party (P1), such as the token issuer (I) 3, to record a transfer of a token, a management application stored in memory (not shown) of one or more processing devices (not shown) associated with the second party (P2) is executed by one or more processors (not shown) of the one or more processing devices (not shown) to enter data into the rights registration store 23 at 510. In some embodiments, for each request or valid request received by the second party (P2), a new entry is created in the rights registration store 23. In some embodiments, if an entry for the token (T) associated with the request already exists, the management application may be configured to update the already existing entry rather than creating another entry for the token (T).

[0145] Validating the token (T) associated with the transaction using the entitlement registration store A method 600 of determining the validity of a token (T) associated with a cryptocurrency amount using the rights registration store 23 will now be described with reference to Figure 6. In some embodiments, a verification application including executable code may be stored in memory 1520 (Figure 8) of the processing device 17, and one or more processors 1510 (Figure 8) of the processing device 17 may be configured to execute the verification application to perform the method 600 of determining the validity of a first token (T1) associated with a first cryptocurrency amount (B1). The method 600 may be performed by a processing device 17 associated with a second user (B) 7.

[0146] A first user (A) may send 602 a first transaction to a second user (B) including a transfer of a first token (T1). In performing method 600, the validation application is configured to receive 604 the first transaction including a transfer of a token (T) from the first user (A) to the second user (B) via the communications network 8. The first transaction may include a blockchain transaction for the transfer of a portion of cryptocurrency, such as that described in connection with Table 7 above. For example, the transaction may include a transaction ID, one or more inputs, and one or more outputs. The one or more inputs may be related to one or more previous transactions, each of which may include an ID of the previous transaction (previous transaction ID) and an unlocking script including a redemption script associated with the first token (T1). At least one of the one or more outputs may be related to a transfer or payment affected by the current transaction or the first transaction and may include a locking script.

[0147] In some embodiments, the validation application is configured to determine whether the authenticity of the token (T) is attested at 606. For example, this may include determining whether a redemption script associated with the token (T) and referenced as an input to the first transaction has been signed by an authorized signatory, such as the token issuer or a trusted service provider.

[0148] The validation application determines 608 an indicator of a second or previous transaction involving a transfer of token (T). The second transaction may be a previous transaction that temporally precedes the first transaction. In some embodiments, the indicator may be a transaction identifier of the previous transaction. For example, the previous transaction may be a transaction identified as an input to the current transaction, and the identifier may be identified as one of multiple input parameters of the current transaction.

[0149] The verification application is configured to, at 610, use the indicator to query the rights registration database 23 to determine whether the second transaction has been recorded in the rights registration store 23. For example, if the second transaction has been recorded in the rights registration store 23, the rights registration store 23 may include an indicator of the second transaction, such as a transaction identifier. Thus, in some embodiments, verification of the validity of a token may be determined without knowing who the previous or last owner was. Thus, embodiments of the present invention provide a novel and advantageous verification technique that solves a technical problem not addressed by the prior art.

[0150] However, in other embodiments, the rights registration store 23 may additionally or alternatively include identifiers of the current and / or previous owners of the token. In some embodiments, the verification application may be configured to query the rights registration store 23 only if the verification application determines at 606 that the authenticity of the token (T) has not been verified.

[0151] In response to determining that the second transaction is recorded or registered in the rights registration store 23, the validation application is configured to determine 612 that the token (T) is valid.

[0152] In some embodiments, in response to determining that the second transaction is not registered in the rights registration store, the validation application is configured to determine 614 that the token (T) is not valid. However, in other embodiments, in response to determining that the second transaction is not registered in the rights registration store, the validation application is configured 614 to perform steps 710-714 of method 700, described below.

[0153] Uses blockchain to verify transactions and associated tokens (T) A method 700 of determining the validity of a token (T) associated with a cryptocurrency amount using blockchain 9 will now be described with reference to Figure 7. In some embodiments, a validation application including executable code may be stored in memory 1520 (Figure 8) of processing device 17, and one or more processors 1510 (Figure 8) of processing device 17 may be configured to execute the validation application to perform method 700 of determining the validity of a token (T) associated with a cryptocurrency amount. Method 700 may be performed by processing device 17 associated with second user (B) 7.

[0154] A first user (A) may send 702 a first transaction to a second user (B) that includes a transfer of tokens (T). In performing method 700, the validation application is configured to perform steps 704 and 708, which correspond to steps 604 and 608 of method 600 described above with reference to Figure 6. In some embodiments, the validation application is configured to perform step 706, which corresponds to step 606 of method 600 described above with reference to Figure 6.

[0155] The validation application is configured to, at 710, query the blockchain 9 using the indicators of previous transactions to determine whether an attested transaction associated with the token (T) can be identified. Attested transactions include transactions associated with the token (T), where the token (T) is authenticated. For example, a token may be considered authenticated or legitimate if a redemption script associated with the token (T) is signed by an authorized signatory, such as the issuer of the token (T) or a trusted service provider. The signature may include a digital cryptographic signature.

[0156] In some embodiments, the validation application may be configured to query the blockchain 9 only if the validation application determines at 706 that the authenticity of the token (T) of the first transaction has not been attested. For example, this may include determining whether a redemption script associated with the token (T) and referenced as an input to the transaction has been signed by an authorized signatory, such as the issuer of the token (T) or a trusted service provider.

[0157] In some embodiments, querying the blockchain 9 includes comparing the indicator of the previous transaction with corresponding indicators of transactions recorded on the blockchain 9 to identify previous transactions having the same indicator as the indicator of the previous transaction. For example, the indicator of the previous transaction may include the previous transaction ID indicated in the first transaction.

[0158] The validation application is configured to iterate (i.e., iterate) through entries in the blockchain 9 to identify authorized transactions associated with the token. Thus, for example, if the most recent transaction identified in the blockchain 9 as being associated with a token (T) is not an authorized transaction, the validation application is configured to identify or locate the transaction associated with the token that immediately precedes the most recent transaction and determine whether this transaction is an authorized transaction. If the transaction associated with the token that immediately precedes the most recent transaction is not an authorized transaction, the validation application is configured to identify or locate the even earlier transaction associated with the token and determine whether this transaction is an authorized transaction.

[0159] In some embodiments, the validation application is configured to determine that the most recent transaction or an earlier transaction is an authorized transaction, where determining that the most recent transaction or an earlier transaction is an authorized transaction includes determining whether a redemption script associated with the token and referenced as an input to the transaction is signed by an authorized signatory, such as the issuer of the token (T) or a trusted service provider.

[0160] In some embodiments, in response to determining that a transaction recorded on the blockchain 9 is not an authenticated transaction, the validation application is configured to determine an indicator of a previous transaction from the transaction's entry and use the indicator of the previous transaction to identify an entry for the previous transaction in the blockchain 9. The indicator may include a previous transaction ID associated with the transaction. For example, in some embodiments, the validation application is configured to identify or locate the transaction immediately preceding or prior to the most recent transaction by determining an identifier of the previous transaction from an input script of the most recent or prior transaction. This process is performed iteratively until no previous transactions can be identified.

[0161] Thus, the present invention provides an advantageous verification technique that involves dynamically building a logical hierarchy of related blockchain transactions. This hierarchy is built using multiple sources, starting with the first transaction, as transactions are recorded in different blocks on the blockchain. In this regard, the present invention identifies and associates relevant data from multiple sources and uses that data in the verification process.

[0162] If the validation application identifies a valid transaction, then method 700 proceeds to step 712. However, if the validation application does not identify a valid transaction, then method 700 proceeds to step 714.

[0163] In response to identifying the authenticated transaction in the blockchain 9, the validation application is configured to determine that the token (T) is valid, at 712. For example, if the validation application determines that the redemption script of the previous transaction was signed by an authorized signer, the validation application identifies the previous transaction as a legitimate transaction.

[0164] In some embodiments, in response to not identifying a transaction in the blockchain 9 whose authenticity is attested, the validation application is configured to determine, at 714, that the token (T) is not valid.

[0165] Processing Device 1, issuer (I) 3, first user (A) 5, and second user (B) 7 may be associated with first processing device 13, second processing device 15, and third processing device 17. Blockchain 9 may also be associated with one or more processing devices 19. Title registration database 23 may also be associated with one or more processing devices 21. Such processing devices may be part of an electronic device such as a computer, tablet computer, mobile communication device, computer server, etc. In addition to the processing device, the electronic device may include a data store 11 and a user interface (not shown).

[0166] 8 illustrates examples of processing devices 13, 15, 17, 19, and 21. Processing devices 13, 15, 17, 19, and 21 include a processor 1510, a memory 1520, and an interface device 1540, which communicate with each other via a bus 1530. Memory 1520 stores instructions and data for implementing methods described herein, including methods 300, 500, 600, and 700, and processor 1510 executes instructions from memory 1520 to perform these methods. Interface device 1540 may include a communications module (not shown) that facilitates communication with communications network 8 and, in some examples, with peripherals such as data store 11 and user interfaces. It should be noted that, although the processing devices may comprise independent network elements, processing devices 13, 15, 17, 19, and 21 may be part of another network element. Furthermore, some functions performed by processing devices 13, 15, 17, 19, 21 may be distributed among multiple network elements. For example, issuer 3 may have multiple processing devices 23 for performing methods 300, 500, 600, and / or 700 in a secure local area network associated with issuer (I) 3.

[0167] When this disclosure describes a user, issuer, merchant, provider, or other entity performing a particular operation (including a signing operation, an issuing operation, a determining operation, a deciding operation, a calculating operation, a sending operation, a receiving operation, a creating operation, etc.), this language is used for clarity of presentation, and it should be understood that these operations are performed by computing devices operated by these entities.

[0168] Signing can involve performing a cryptographic function. A cryptographic function has an input for the plaintext and an input for a key, such as a private key. A processor can perform the cryptographic function to compute a number or string that can be used as a signature. This signature is then provided along with the plaintext to provide the signed text. If even one bit of the message text or the key changes, the signature changes completely. Computing a signature requires little computational power, but recreating a message with a given signature is practically impossible. In this way, if the private key is available, one only needs to modify the plaintext to accompany a valid signature. Furthermore, other entities can easily verify the signature using the publicly available public key.

[0169] In most situations, encrypting and decrypting involve a processor performing a cryptographic function to calculate an output string that represents the encrypted or plaintext message, respectively.

[0170] Key, token, metadata, transaction, offer, contract, signature, script, invitation, and the like refer to data represented as numbers, text, or strings of characters stored in a data memory, such as a variable of type "string" or "int" or other type in program code, or a text file.

[0171] An example of a peer-to-peer ledger is the Bitcoin blockchain. Paying a fee or transferring funds in Bitcoin currency involves creating a transaction on the Bitcoin blockchain, where the fee or funds are output from the transaction. An example Bitcoin transaction includes an input transaction hash, a transaction amount, one or more destinations, one or more payee public keys, and a signature created by calculating a signature using the payer's private key and the input transaction as the input message. A transaction can be verified by checking that the input transaction hash exists in a copy of the Bitcoin blockchain and checking that the signature is correct using the public key. To ensure that the same input transaction hash has not already been used somewhere else, the transaction is broadcast to a network of computing nodes ("miners"). Miners accept the transaction and record it in the blockchain only if the input transaction hash is not already connected and the signature is valid. If the input transaction hash is already linked to a different transaction, the miner rejects the transaction.

[0172] Allocating cryptocurrency for a token includes creating a transaction, where the allocated cryptocurrency and token are represented in metadata fields within the transaction.

[0173] When two items are related, this means that there is a logical connection between them. In a database, for example, identifiers for two items may be stored in the same record to associate the two items with each other. In a transaction, identifiers for two items may be included in a transaction string to associate the two items with each other.

[0174] Using the Bitcoin protocol, redeeming a script and / or unlocking tokens involves using a private key to calculate a signature string for the script and / or transaction. A script may require two or more signatures derived from different private keys or other conditions. The output of this transaction is then provided to the miner.

[0175] Authorizing another entity may include calculating a signature string for the transaction using a private key and providing the signature string to the other entity to enable the other entity to verify the transaction using the signature.

[0176] A user's transaction with another entity may include the other entity storing information about the user, such as an email address, a name, and optionally a public key. For example, the other entity may maintain a database such as SQL, OrientDB, MongoDB, or other DB. In some examples, the other entity may also store one or more of the user's private keys.

[0177] It will be appreciated by those skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments without departing from the broad general scope of the present disclosure, and the present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. [Explanation of symbols]

[0178] 3. Issuer 5. First User 7 Secondary User

Claims

1. 1. A computer-implemented method for determining validity of a token present in a metadata field of a first transaction, comprising: The first transaction is an amount of cryptocurrency associated with said token; a hash of a redemption script, the redemption script including metadata and at least one public encryption key; The method comprises: receiving, via a communications network, the first transaction comprising a transfer of the token from a first user to a second user; determining whether the first transaction is an authenticated transaction associated with the token by determining whether the redemption script is signed with an authenticated signature; If the first transaction is not determined to be an attested transaction, query the peer-to-peer distributed ledger to traverse entries in the peer-to-peer distributed ledger and perform the following until an attested transaction is identified or no previous transaction is identified: i) identifying or locating a previous transaction associated with the token; ii) determining whether the authenticity of the token associated with the previous transaction has been verified; determining whether an authenticated transaction associated with said token can be identified by repeating determining that the token is valid in response to identifying an authenticated transaction in the peer-to-peer distributed ledger; A method comprising:

2. 10. The method of claim 1, wherein querying the peer-to-peer distributed ledger comprises querying the peer-to-peer distributed ledger in response to determining that the authenticity of a token of the first transaction has not been attested.

3. The method of claim 2 , wherein the authenticated signature includes at least one of an issuer of the token and a trusted service provider.

4. 2. The method of claim 1, wherein the metadata is provided in the redemption script at a location designated in a blockchain protocol as a location for a cryptographic key.

5. The steps for querying the peer-to-peer distributed ledger include: a) determining a previous transaction ID indicated in the first transaction; b) identifying a previous transaction recorded in the peer-to-peer distributed ledger, the transaction ID of the previous transaction corresponding to the determined previous transaction ID; c) determining whether the redemption script of the previous transaction is signed with an authenticated signature; d) in response to determining that the redemption script of the previous transaction is signed with an authenticated signature, identifying the previous transaction as an authenticated transaction; e) in response to determining that the redemption script of the previous transaction was not signed with an authenticated signature, determining a previous transaction ID indicated in the previous transaction as a previous transaction ID; identifying an earlier transaction recorded in the peer-to-peer distributed ledger as a previous transaction, the transaction ID of the earlier transaction corresponding to the previous transaction ID; f) repeatedly performing steps c) through e) until a further earlier transaction is identified; The method of claim 1 , comprising:

6. 10. The method of claim 1, further comprising: determining that the token is invalid in response to being unable to identify an attested transaction in the peer-to-peer distributed ledger.

7. 10. A token validation system for determining the validity of a token associated with an amount of cryptocurrency, the system including: a memory storing a validation application; and a processor, the processor configured to execute the validation application to perform the method of claim 1.

8. 10. A computer software program comprising machine-readable instructions that, when executed by a processor, causes the processor to perform the method of claim 1.

Images