A computer-based method and system for verifying tokens for blockchain-based cryptocurrencies.

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 generally relates to distributed ledger technologies such as, but not limited to, the Bitcoin blockchain. The described embodiments relate to a highly secure system and method for verifying tokens for blockchain-based cryptocurrencies. Some embodiments relate to verifying tokens associated with blockchain transactions (TXs) not electronically countersigned by the signatory. Other embodiments relate to a system and a control method executed by a computer configured to enable and improve the transfer and communication of blockchain-implemented tokens between computing nodes.

Background Art

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

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized, distributed system composed of blocks made up of transactions. Each transaction (TX) is a data structure that encodes the transfer of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks are chained together to create a persistent and immutable record of all transactions written to the blockchain from the beginning. A transaction contains a small program known as a script embedded in its input and output, which specifies how and by whom the output of the transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes (miners) perform the work to ensure that each transaction is valid by rejecting invalid transactions from the network. Software clients installed on the nodes perform this verification work on unused transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction—if the transaction is verified, this node relays the transaction to other nodes in the network—ii) be added to a new block built by miners, and iii) be mined, that is, added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, 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 extremely advantageous if blockchain could be used for automated tasks and processes that are not limited to the realm of cryptocurrency. Such solutions would be more diverse in their applications while still being able to leverage the advantages of blockchain (e.g., distributed processing of persistent and tamper-proof records of events).

[0006] One area of ​​current research is the use of blockchain for the implementation of "smart contracts." A smart contract is a computer program designed to automate the execution of machine-readable contract or agreement terms. Unlike traditional contracts, which would be written in natural language, smart contracts are machine-executable programs that contain rules that can process inputs to produce an outcome, and then perform actions according to that outcome. In the context of commercial transactions, for example, these may involve the transfer of property rights and / or assets. Such assets may include real estate, human property (including both tangible and intangible property), digital assets such as software, or any other type of asset. In the digital economy, it is often predicted that exchanges and transfers will be carried out in a timely manner over tremendous distances. This prediction, along with actual technological limitations, means that traditional forms of asset transfer, such as hard copies of documents representing contracts, securities, etc., or the physical delivery of tangible assets themselves, are undesirable. Therefore, smart contracts can provide enhanced 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 across the blockchain. Potentially confidential or secret items can be represented by tokens that do not have an identifiable meaning or value. Thus, tokens function as identifiers that enable real-world items to be referenced from the blockchain. The use of tokenization provides enhanced security and control in terms of the transmission, transfer, and verification of digital entities on the blockchain.

[0008] The descriptions of documents, operations, materials, devices, products, etc. contained herein should not be construed as an acknowledgment that any or all of these matters constitute part of the foundation of the prior art or were common general knowledge in the art relevant to this disclosure that existed prior to the priority date of each claim of this application.

[0009] Throughout this specification, the words “comprise,” “comprises,” or “comprising,” and variations thereof, should be understood to mean the inclusion of any element, integer, or step, or any group of elements, integers, or steps, described herein, and not the exclusion of any other element, integer, or step, or any group of elements, integers, or steps. [Overview of the project]

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

[0011] The present invention can be described as a verification or authentication method and a corresponding system, because the present invention can enable the determination and / or identification of blockchain transactions that include or relate to one or more tokens and are digitally signed by a 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-based method for determining the validity of a token associated with a cryptocurrency amount. The method may include the steps of: a second user receiving a first transaction via a communication network, which includes the transfer of a token from a first user to the second user; querying a peer-to-peer distributed ledger (blockchain) to determine whether it is possible to identify a verified transaction associated with the token, wherein the verified transaction includes a previous transaction associated with the token and the legitimacy of the token is recognized; and determining that the token is valid in response to the identification of a verified transaction.

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

[0014] In some embodiments, determining that a token's authenticity is not proven includes determining that the redeem script associated with the token, which is referenced as input to a first transaction, is not (cryptographically) signed by the signatory. Tokens in a legitimate transaction may be signed by the signatory. For example, the signatory may include at least one of the token's issuer and a trusted service provider.

[0015] In some embodiments, querying a peer-to-peer distributed ledger includes: a) determining the previous transaction ID shown 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 the signer; d) identifying the previous transaction as a legitimate transaction, in accordance with the determination that the redemption script of the previous transaction is signed by the signer; e) identifying the previous transaction ID shown in the previous transaction as a previous transaction ID, in accordance with the determination that the redemption script of the previous transaction is not signed by the signer, identifying a further earlier transaction recorded in the peer-to-peer distributed ledger as a previous transaction, wherein the transaction ID of the further earlier transaction matches the previous transaction ID; and f) iterating through steps c) to e) until no further earlier transactions can be identified.

[0016] Accordingly, the present invention may include performing one or more of the above steps to examine different transactions within each block on the blockchain, starting from the first transaction or "trigger" transaction and progressing through the logical path or hierarchy of transactions until the validity of the token is established or at least sufficiently proven or verification fails.

[0017] In some embodiments, the method further includes the step of determining that a token is invalid in a peer-to-peer distributed ledger if it does not identify a transaction whose authenticity has been proven.

[0018] Some embodiments relate to a computer-based method for determining the validity of a token associated with a cryptocurrency amount, the method comprising: a second user receiving a first transaction via a communication network, which includes the transfer of a token from a first user to the second user; querying a rights registration database to determine whether a second transaction, which includes the transfer of a token, is recorded in the rights registration database; and determining that the token is valid, in accordance with the determination that the second transaction is recorded in the rights registration database. For example, the second transaction may occur chronologically prior to the first transaction.

[0019] In some embodiments, querying the rights registration database includes querying the rights registration database in response to determining that the authenticity of the token has not been proven.

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

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

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

[0023] In some embodiments, the method further includes the steps of: determining whether it is possible to identify a verified authentic transaction associated with a token, in response to determining that a second transaction is not recorded in the rights registration database, by querying a peer-to-peer distributed ledger; and determining that the token is valid in response to identifying a verified authentic transaction.

[0024] In some embodiments, the method is a computer-based method for a first party to maintain a rights registration database for recording the transfer of tokens issued by an issuer, wherein each token is associated with a cryptocurrency amount, and the method includes the steps of: monitoring a peer-to-peer distributed ledger for transactions involving the transfer of tokens issued by an issuer; and recording the token transfer in the rights registration database in response to the determination of a first transaction involving the transfer of tokens issued by an issuer that has been recorded in the peer-to-peer distributed ledger.

[0025] In some embodiments, monitoring a peer-to-peer distributed ledger includes identifying a previous transaction ID of a transaction recorded in the peer-to-peer distributed ledger; comparing the identified previous transaction ID with a set of transaction IDs, wherein each transaction ID in the set identifies a transaction associated with a token issued by an issuer; and determining, in response to the identified previous transaction ID matching one of the transaction IDs in the set of transaction IDs, a transaction associated with the previous transaction ID as a record of a first transaction including a transfer of a token issued by the issuer.

[0026] In some embodiments, monitoring a peer-to-peer distributed ledger includes identifying a target transaction ID of a transaction associated with a token issued by an issuer; comparing the target transaction ID with a previous transaction ID of a transaction recorded in the peer-to-peer distributed ledger; and determining, in response to the target transaction ID matching a previous transaction ID of one of the transactions recorded in the peer-to-peer distributed ledger, 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 proving the authenticity of an entry by adding a signature of the issuer to an entry associated with recording a transfer of a token in a rights registration database.

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

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

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

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

[0032] Some embodiments relate to a computer software program including machine-readable instructions that cause a processor to execute any one of the methods described above when executed by the processor.

Brief Description of the Drawings

[0033] Examples of the present disclosure are described with reference to the drawings. [Figure 1] Schematic diagram of an exemplary system for creating and / or transferring tokens according to some embodiments. [Figure 2] Diagram showing an example of a first type of transaction between an issuer and a first user, including creating a token. [Figure 3] Process flow diagram of a method executed by a computer for creating a token according to some embodiments. [Figure 4]A diagram illustrating an example of a second type of transaction between a first user and a second user, which involves transferring tokens. [Figure 5] A processing flow diagram of a computer-based method for maintaining a rights registration database for recording token transfers, according to several embodiments. [Figure 6] A processing flow diagram of a computer-based method for verifying a token, according to several embodiments. [Figure 7] A processing flow diagram of a computer-based method for verifying a token, according to several embodiments. [Figure 8] A diagram showing schematic examples of processing devices for the system of Figure 1, according to several embodiments. [Modes for carrying out the invention]

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

[0035] Some embodiments relate to a system and a method performed by a computer for determining the validity of a token (T) associated with a cryptocurrency amount (B1), wherein the token (T) is transferred, for example, from a first user (A) to a second user (B) by a blockchain transaction Tx that includes (results in) the transfer of the token (T). In some embodiments, the authenticity of the token (T) has not been proven 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 it can identify a verified transaction associated with a token (T). This may or may not be the Bitcoin blockchain. For example, such a verified transaction may include a previous transaction associated with token (T) in which the legitimacy of token (T) is recognized. Depending on whether a verified transaction has been identified, token (T) may be determined to be valid. A “previous” transaction means a transaction that was previously, i.e., in time, written to the blockchain. Recall that blocks (and therefore transactions) are written to the blockchain in chronological order. A previous transaction can be described as a transaction that is earlier in the chain of blocks, i.e., a transaction closer to the originating block.

[0037] In some embodiments, a registration storage resource, such as a database, may be queried to determine whether a second transaction, including the transfer of a token (T), has been registered or recorded in the registration storage, where the second transaction precedes the first transaction in time. Depending on whether it is determined that the second transaction (T2) has been recorded in the registration store, the token (T) may be determined to be valid.

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

[0039] Referring here to Figure 1, a system 1 is shown which includes a first processing device 13 associated with issuer (I) 3, a second processing device 15 associated with first user (A) 5, and a third processing device 17 associated with second user (B) 7. The first processing device 13, the second processing device 15, and the third processing device 17 can communicate with each other via a communication 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 communication network 8.

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

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

[0042] Issuer (I)3 may create the tokens, and could be, for example, a bank, another financial institution, a mint, a company, etc. However, in other examples, the issuer may not be a financial institution, and the present invention is not limited to applications specifically for finance. First user (A)5 may request issuer (I)3 to create the tokens, to exchange some or all of the tokens' value with issuer (I)3, and / or to transfer some or all of the tokens' value to second user (B)7. Similarly, second user (B)7 may request issuer (I)3 to create the tokens, to exchange some or all of the tokens' value with issuer (I)3, and / or to transfer some or all of the tokens' value to 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 detail, one or more processing devices 19 may be configured to receive and record transactions via a communication network 8 from, for example, a first processing device 13, a second processing device 15, and / or a third processing device 17, respectively. 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. Thus, in some embodiments, one or more processing devices 19 may be associated with "miners". Thus, the present invention includes one or more processing devices 19 that communicate with a blockchain-implemented distributed network. The network and various devices communicate with each other to carry out 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 token transfers. One or more processing devices 21 can communicate with a first processing device 13, a second processing device 15, and / or a third processing device 17, and / or one or more processing devices 19 via a communication network 8. In detail, one or more processing devices 21 may be configured to receive and record data related to transactions, including token (T) transfers.

[0045] Overview of token-involved transactions There are three common types of token-related transactions: token creation by issuer (I)3, exchange of part or all of the token's value with issuer (I)3 by first user (A)5 or second user (B)7, and transfer of part or all of the token's value by first user (A)5 or second user (B)7 to second user (B)7 or first user (A)5.

[0046] Referring to Figure 2, the creation of the first token (T1) generally involves the first user (A) transferring fiat currency (e.g., $1,000 AUD) to the issuer (I) 3, and in exchange for this fiat currency, the issuer (I) "tokenizing" a first cryptocurrency amount (B1) so that it has a token value, and transferring this first cryptocurrency amount (B1) to the first user (A). The first token (T1) may represent a contract, such as an agreement in which the issuer (I) agrees to exchange a specified amount of fiat currency (e.g., $1,000 AUD) for the holder of the first token (T1). Therefore, the first token (T1) may be similar to a circulating security. Depending on the specific conditions, the first user (A) 5 may, in the future, exchange the first token (T1) for a value associated with the deposited fiat currency. Such conditions may also allow the first user (A) 5 to transfer at least a portion of the token's value to the second user (B). Such conditions may be specific to the token or may be general conditions between users 5, 7 and the issuer (I) 3.

[0047] Overview of how to create tokens A method 300 for creating a token is described in detail below with reference to Figures 2 and 3. In detail, method 300 includes, in 310, allocating a first cryptocurrency amount (B1) for association with a first token (T1). The method further includes, in 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) containing information associated with the first token (T1), a first user public key (P1A), and a first issuer public key (P1I) associated with an issuer (I), where the first issuer public key (P1I) forms a cryptographic pair with a first issuer private key (V1I). Method 300 also includes, in 314, transmitting a first data output (O1) to a blockchain 9 via a 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) in order to provide the first token (T1) associated with the first user (A)5 and the issuer (I).

[0048] Therefore, Method 300 enables the creation of a token, thereby enabling the transmission of a record of the token to Blockchain 9. The advantage of recording this transaction on Blockchain 9 is that it may enable recipients such as First User (A) 5 to verify the existence of the token (T1). Furthermore, since at least First Metadata (MD1), which includes information associated with the First Token (T1), is hashed, this enables verification of the transaction (on the public record) against the information associated with the token. In one example, the information associated with the First Token (T1) could be the terms of a contract. Therefore, including the terms in the First Redemption Script, which is hashed, can favorably provide First User (A) 5 (or any other user) with the reassurance that no change can alter the terms in such a way that it alters the First Hash (H1). Since the First Hash (H1) was transmitted and recorded on Blockchain 9 when the First Token (T1) was created, it is impossible (or difficult) to change the terms that provide the same First Hash (H1) at a later time.

[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 several embodiments. In this example, the creation of the token is described in the context of a first user (A) 5 depositing cash with issuer (I) 3, and in exchange for that, a token representing the deposited cash. However, it should be understood that this is a non-exclusive example, and 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 the terms and conditions of the token The first user (A) 5 initiates the creation of the first token (T1) in 302 by sending a request for the first token (T1) from the second processing device 15 to the first processing device 13 associated with the issuer (I) 3. For example, the first user (A) 5 makes this request by depositing fiat currency, such as $1000 AUD, with a request for the token (T1) to have this amount. This request may include an offer about a contract, which may include one or more conditions of the contract. For example, the first user (A) 5 may include in this request that the token associated with the $1000 AUD deposit should have a fixed pegging rate against the cryptocurrency. For example, the request may state that the pegging rate is 1000 satoshis / cent (AUD). Please understand that other conditions such as how the token can be redeemed, account maintenance fees, transaction fees, etc., may be included in the offer.

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

[0052] In some embodiments, a request sent to the issuer (I) may simply consist of a request for a first token (T1). In this case, the issuer (I) may send an offer including conditions to the first user (A) 5. The first user (A) 5 can then decide whether to accept the offer, propose a counter-offer, or reject the offer, and this is then sent to the issuer (I). It will be understood that multiple rounds of offers and counter-offers may be sent and received between the issuer (I) and the first user (A) 5 until an agreement is reached. In some embodiments, the conditions may be standardized so that the user accepts the conditions by performing the steps in method 300. In one example, the issuer (I) may have a standardized offer for tokens for its customers, including the first user (A) 5. Such an offer for tokens may be publicly listed, for example, on a public exchange or on the issuer's website. The ongoing offer may also 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 Method 300 includes determining the first user public key (P1A) of a cryptographic pair associated with the first user (A) 5 in 308, where the cryptographic pair includes the first user private key (V1A) and the 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 communication network 8. In another example, the first user public key (P1A) may be stored in the data store 11 (for example, it may be received and stored during the registration of the first user (A) 5). Thus, step 308 of determining 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 from a third party via the communication network 8. The third party may include, for example, a trusted third party that functions as a public directory, such as a certificate authority.

[0054] Allocation of the first amount of cryptocurrency for association with the token Method 300 includes, in 310, allocating a first cryptocurrency amount (B1) for association with a first token (T1). For a record of a transaction involving the first token (T1) to be recorded on a peer-to-peer distributed ledger (blockchain in this example), the token must be associated with a cryptocurrency amount, which is then recorded on the blockchain as a transaction from issuer (I) 3 to first user (A) 5.

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

[0056] The amount of cryptocurrency allocated for a token may be influenced by several of the following considerations. Firstly, the allocated amount of cryptocurrency should ideally have a market value lower than the token's value ("token value") (for this purpose, this means the market value of the cryptocurrency itself, assuming it has a value, without referring to the token value). This is desirable because it avoids any incentive to use the amount of cryptocurrency for its underlying value rather than as a token. This may be analogous to a cash coin, where it is desirable for the face value of a cash coin to be higher than the metal from which it is made, so as not to have an incentive to melt down a cash coin for the value of the metal from which it is made. In some examples, the token value is several times greater than the underlying value of the amount of cryptocurrency. However, it should be understood that some tokens may not have a fixed token value or an easily determinable token value. For example, a token may represent a contract to perform work, in which case its value may change from day to day. In other examples, a contract may only have a value that is determinable on the day it is redeemed.

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

[0058] On the other hand, the amount of cryptocurrency allocated for association with a token cannot be infinitesimally small. Firstly, a cryptocurrency may have a minimum unit value; for example, Bitcoin has a minimum value of 1 satoshi (where 1 Bitcoin (BTC) = 10,000,000 satoshi). Secondly, cryptocurrency transactions may be limited to a minimum size; otherwise, they are not recorded (or the cost of the transaction is close to or exceeds the cost of executing the transaction). This minimum amount is, in some examples, a "dust" limit. Therefore, in some examples, allocating a cryptocurrency amount for a token must be at least the minimum threshold amount (MT1). Thus, the method may include determining a minimum threshold amount (MT1) of cryptocurrency suitable for a first token (T1), and determining a first cryptocurrency amount (B1) that is at least the minimum threshold amount (MT1). In one example, the minimum threshold amount (MT1) of cryptocurrency for "Bitcoin" is 546 satoshi.

[0059] Another consideration when allocating the amount of cryptocurrency 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 in tokens. Such a transaction involves a transaction using the first token (T1) that results in a second token (T2) representing the $200 AUD that remains with the first user (A) 5, which in turn creates a third token (T3) representing the $800 AUD that is transferred to the second user (B) 7. Thus, the result of this transfer is two tokens, the second token (T2) and the third token (T3), each of which must also be allocated a amount of cryptocurrency. If the initial amount of cryptocurrency (B1) is minimal, such as a "dust" limit, then each new token created will also need to be associated with a sufficient amount of cryptocurrency to satisfy the minimum threshold. Therefore, there may be an advantage in allocating a sufficient amount of cryptocurrency (B1) for the initial token (T1) so that the amount is sufficient to be divided and used for an expected number of subsequent tokens.

[0060] In one example, the condition may specify a cryptocurrency amount, or a minimum token value or currency unit. For example, the condition may set the minimum currency unit of the token value to $10 AUD. Therefore, allocating a first cryptocurrency amount (B1) for a first token (T1) with a token value (TV1) of $1000 AUD may involve determining a first amount that ensures there is enough cryptocurrency if the total token value (TV1) is divided into the minimum currency units. In this example, the token value (TV1) can be divided into 100 subsequent tokens (calculated by $1000 / $10). Therefore, a suitable first cryptocurrency amount (B1) could be 100 times the "dust" limit.

[0061] Determination of the first hash (H1) of the first redemption script (RS1) Method 300 further comprises determining a first hash (H1) of a first redemption script (RS1) in 312. In one example, the hash of the redemption script may be used to provide a pay-to-script hash (P2SH) address for a pay-to-script hash transaction. The example includes a hash function used in a P2SH script in the Bitcoin protocol. This may include a combination of SHA256 and SHA256 followed by RIPEMD160.

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

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

[0064] (i) Overview of the redemption script in P2SH As background, in the pay-to-script hash (P2SH) method, the redemption script can take the following form: <NumSigs PubK1 PubK2 ... PubK15 NumKeys OP_CHECKMULTISIG> Here, NumSigs is the number of valid signatures "m" required to satisfy the redemption script in order to unlock the transaction. PubK1, PubK2, ..., PubK15 are public keys corresponding to the signatures that unlock the transaction (up to 15 public keys). NumKeys is the number of public keys "n" (it must be 15 or less).

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

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

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

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

[0069] A practical benefit can be illustrated by the following example: First User (A)5 and Issuer (I)3 may wish to enter into a contract under certain conditions. The contract may include Issuer (I) creating a token, thereby including the specific conditions in metadata embedded in the redemption script. The hash of the redemption script is then recorded on Blockchain 9, which becomes a record of the transaction that is difficult or impossible to alter. Suppose Issuer (I) attempts to deceive First User (A)5, for example, by attempting to alter a clause and claiming that the altered clause was originally present in the agreed-upon contract. First User (A)5 may contest this by placing the altered clause in the metadata of the redemption script, hashing it, and then showing that this does not match the redemption script recorded on the blockchain. Thus, including information associated with the token in at least the first metadata can be useful in ensuring the integrity of the token.

[0070] It should be understood that metadata within a redemption script can itself contain hashes of other information. For example, if a condition is lengthy, a hash of the condition can be used to provide shorter metadata.

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

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

[0073] Therefore, at least the first metadata (MD1) includes both Metadata1 and Metadata2, which occupy two locations within 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] Metadata may include information about tokens in several ways. As described, in one example, conditions may be included in the metadata. In another example, a hash of conditions may be included in the metadata. In yet another example, the metadata may include a pointer to a file containing the terms of the contract. In further embodiments, a combination of one or more of the above may be included in the metadata.

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

[0076] This example contains only minimal information about tokens and transactions. This example includes providing a pointer to a smart contract, which may be useful when the size of the contract prevents including such details in the metadata. Furthermore, since metadata can be made public or transmitted over insecure networks, it may be desirable for specific details of tokens to be hidden or kept secret for privacy reasons.

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

[0078] The first 20 bytes of Metadata2 are the hash of the actual contract file, using SHA256 and RIPEMD-160, which are applied to the actual contract file. Since the actual contract file is searchable and retrievalable, this allows for transaction verification 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 embodiment. The content of the remaining 12 bytes of Metadata2 may be used depending on the type of contract.

[0079] (ii) metadata containing the main parameters of the token Another specific 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. Specifically, the bytes assigned 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 metadata can lead to better processing efficiency, as it allows the issuer (I)3 to process tokens in a transaction without having to search the contract file for key information required to process the transaction in some cases.

[0082] In addition to the information described above, the token history, i.e., other information related to tokens preceding the token, may also be included. For example, if a first user (A)5 wishes to redeem a portion of a first token (T1), and a second token (T2) is created by the 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, 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 2-byte field indicating the fiat currency (FiatDenomination) and a 1-byte field called the PeggingRate. The pegging rate is set by the issuer (I). Several different rates may be set for the same fiat currency, but different tokens (with different contracts) will be required for each different rate. The choice of rate is at the discretion of the issuer (I), but the issuer (I) may give similar consideration to the pegging rate as to the allocation of cryptocurrency for the tokens described above.

[0084] In one example, PeggingRate is an 8-bit code value as follows: The leftmost bit is used as a flag: The exchange rate is expressed as 1 = satoshis / cent (where "cent" refers to 1 / 100th of a legal tender and is the minimum legal amount). The rate is expressed as 0 = cents / satoshi. The 7 bits on the right represent the rate as a power of 10 in binary, for example: USD 10000010 means an exchange rate of 100 satoshis / cent (flag is on). PHP 00000000 means a rate of 1 centavo / satoshi (flag is 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 "issuance" (where tokens are created from cryptocurrency), a payment (where at least a portion of the token value is transferred from one user to another), or an exchange (where tokens are transferred to an issuer (I) and exchanged for legitimate cryptocurrency).

[0086] In some examples, the "Padding" in Metadata1 and Metadata2 contains a randomly generated value for each transaction. The result is that each of Metadata1 and Metadata2 changes between transactions. The advantage is that this can reduce the risk and motivation for a malicious actor to attempt to determine (for the purpose of signing a redemption script using such a private key) a cryptographic pair that would match one or both of Metadata1 and Metadata2. This can be important for standardized tokens if the majority of the rest of Metadata1 or Metadata2 is the same.

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

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

[0089] Sending the first data output (O1) to the blockchain Method 300 further includes, in 314, issuer (I) 3 transmitting a first data output (O1) to blockchain 9 via communication network 8. This first data output (O1) may include an indication of a transaction transferring a first cryptocurrency amount (B1) to first user (A) 5, i.e., recording that an underlying cryptocurrency amount (B1) associated with a first token (T1) has been transferred to 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 first user (A) 5 and issuer (I). Thus, the first hash (H1) is recorded on blockchain 9 and may be used to prove or verify the existence of the token (T1), the relationship between issuer (I) and first user (A) 5, and / or the conditions of the token.

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

[0091] A specific example of a transaction that creates the first token (T1) will be explained next with reference to Figure 2.

[0092] Deposit of $1,000 AUD to Issuer (I) by User 1 (A) 5 for the equivalent value in tokens. In this example, User 1 (A) 5 wishes to deposit $1000 AUD with Issuer (I), and Issuer (I) creates a first token (T1) with a token value (TV1) of $1000 AUD by associating the first token (T1) with a first cryptocurrency amount (B1) of 10,000,000 in exchange.

[0093] To create a token, the issuer (I) needs to possess cryptocurrency. This may be provided from a previous transaction, or it may be provided in response to a request from the first user (A)5 seeking the first token (T1). This is shown on the left side of Figure 2 as "Amount of First (Non-Tokenized) Cryptocurrency".

[0094] Table 3 below shows the source transaction output in the form of Transaction ID / Satoshi amount / Locking script. This source transaction output represents the cryptocurrency acquired by the issuer (I) from previous transactions, and at least a portion of this cryptocurrency will be used to associate it 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 in this output.<PubK-Issuer hash> This output indicates that the transaction is locked using the first issuer's public key (P1I). In other words, the transaction can be unlocked using the issuer's corresponding first issuer's private key (V1I).

[0096] As described above, method 300 includes allocating a suitable amount of first cryptocurrency (B1) for the first token (T1) in 310. However, the amount of cryptocurrency held by the issuer (I) may not exactly match the amount of first cryptocurrency (B1). In this example, the required amount of first cryptocurrency (B1) is 10,000,000, which is far less than the 5,000,000 from transaction ID-201. Therefore, the transaction creating the first token (T1) may include providing the issuer (I) with cryptocurrency change for the excess amount of cryptocurrency not required for this token. Furthermore, token creation may be a transaction that requires payment of a transaction fee to the miner. This is illustrated by referring to Table 4 below, which shows a transaction that creates a token. [Table 4]

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

[0098] Rows 4-7 in Table 4 relate to the "input," i.e., the previous transaction ID-201 that funded the current transaction ID-210. Row 5, "IDX-00," is the index of the output of the previous transaction ID-201 (in this case, a reference indicating that the first output from the previous transaction ID-201 should be used). Row 6 is "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 the PubK-Issuer. Therefore, the previous transaction can be unlocked using the issuer's corresponding first issuer private key (V1I), represented by the Sig-Issuer. Row 7 is the sequence number associated with the input. In Bitcoin transactions, each Bitcoin transaction contains a 4-byte field called a "sequence number," which is no longer used by Bitcoin Core. Depending on the issuer's implementation, the option is to use this field to assign the transaction input to the output. A sequence number can represent a string of 1-bit flags, where the position of each flag, starting with the rightmost bit, indicates that the input has contributed a portion of its funds to the output on which that flag is set. In this example, the sequence number "0000000000000000000000000000011" indicates that the input is credited to outputs 1 and 2, which will be explained below.

[0099] Row 8 in Table 4 shows 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 10000000 satoshi. 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). This contains the first hash (H1) of the first redemption script (RS1) and is represented as follows: OP_HASH160<redeem script hash> OP_EQUAL

[0101] "OP_HASH160" is the type of hash function, where the input is hashed twice, first by SHA-256 and then by 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 contain 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 50000000 satoshi, the issuer (I) can expect to receive the remaining satoshi. Line 12 is the output value for the second output, which is 39999000. 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 have free use of the second output. Therefore, the output script (i.e., the locking script) is:<PubK-Issuer hash> It includes only the first issuer public key (P1I) represented by .

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

[0105] Summary of the exchange of part or all of the token value by the first user (A) with the issuer (I). Generally, tokens are redeemed with issuer (I) 3. In some embodiments, if 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 issuer (I). Thus, in such embodiments, users 5, 7 (or their respective processing devices 15, 17) do not sign the redemption script. Instead, issuer (I) 3, authorized by users 5, 7, signs the redemption script. For example, first user (A) 5 may send a request to issuer (I) 3 to redeem a token, implicitly or explicitly, and this request also includes authorization from first user (A) 5 for issuer (I) 3 to use first user private key (V1A) to redeem the token.

[0106] The method for redeeming the first token (T1) may include, by issuer (I) 3, receiving a request from first user (A) 5 to redeem the first token (T1) via the communication network 8, determining the first redemption script (RS1) associated with the first token (T1), and obtaining the first user private key (V1A) from, for example, the data store 11 or another entity or node. The issuer can 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 issuer (I) 3, as the service provider for first user (A) 5, can securely perform these steps in the first processing device 13 without transmitting the signed or unsigned first redemption script (RS1) via the communication network 8.

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

[0108] Transfer of part or all of the token value by User 1 (A) to User 2 (B) In some embodiments, one or more additional tokens may be created to enable a first user (A) 5 to transfer the value or a portion thereof of a first token (T1) 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 transfer to the second user (B) the same or similar rights that are actually associated with the first token (T1). A new token in the form of a third token (T3) is created, but the third token (T3) may have similar characteristics to 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 conditions 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] For example, first user (A) 5 may wish to transfer the entire value of first token (T1) to second user (B). In such a case, this may involve the creation of a third token (T3) associated with the amount of first cryptocurrency (B1) to be transferred to second user (B) 7. Conveniently, the third token (T3) is the transfer of first token (T1) and the rights associated with first token (T1) to second user (B) 7.

[0110] In a further example, only the first portion (R1) of the total value of the first token (T1) is 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] Transfer of tokens by the first user (A) to the second user (B) without the involvement of the issuer (I) or any other third-party intermediary. In the example described in the section above, the transfer of token value from the first user (A) 5 to the second user (B) involves the issuer (I) 3 as an intermediary to facilitate the transfer. This is distinct from a direct transaction of the first amount of cryptocurrency (B1) from the first user (A) 5 to the second user (B) 7.

[0112] However, in some cases, it may be desirable for the first user (A) 5 to transfer the value of the tokens to the second user (B) 7 without the involvement of the issuer (I) or any 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 second user (B) 7's service provider is not located within the same web of trust as the first user (A) 5's service provider or the issuer (I) 3, which is 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) within the same Web of Trust as the first user (A)5's service provider (SPA), the service provider (SPB) acts as the signer for the transaction regarding the use or redemption of 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) within the same Web of Trust as the first user (A)5's service provider (SPA), the issuer (I) or authorized party is not available to prove the authenticity of the transaction or verify the validity of the transaction.

[0114] Therefore, the second user (B)7 may wish to determine the legitimacy of the token (T1) being transferred to the second user (B)7. In some embodiments, a verification application containing executable computer code is stored in the memory 1520 (Figure 8) of the processing device 17 and executed by the processor 1510 (Figure 8) of the processing device 17, causing the processing device 17 to execute a method 600 or 700 for determining the validity of a token (T) associated with a cryptocurrency amount, which is described in more detail below with reference to Figures 6 and 7, respectively. In some embodiments, the second user (B)7 may manage an electronic wallet (not shown) that can be accessed via a virtual machine environment or terminal associated with the processing device 17, and the electronic wallet may include add-on functionality that enables the second user (B)7 to cause the processing device 17 to execute the verification application.

[0115] A specific example of a transaction transferring a token (T1) from the first user (A) to the second user (B) will be explained next with reference to Figure 4.

[0116] Transfer of the first token (T1) from the first user (A) to the second user (B) In this example, the first user (A) 5 wishes to transfer token (T) to the second user (B), as shown in Figure 4. This results in a transaction of cryptocurrency amount from the first user (A) 5 to the second user (B) 7, which will be referred to as transaction ID-510 below. The transfer of cryptocurrency amount to the second user (B) 7 enables 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) by one or more transactions that remove metadata (which may include the 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 requiring permission (such as a signature) from the first user (A) 5 or other users.

[0117] Before describing transaction ID-510, which transfers the first token, as 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 are 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., miner's fee).

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

[0119] Row 2 in Table 5 represents the amount of cryptocurrency associated with the token (T), which is 10,000,000 satoshi. Row 3 represents the output script, which is equivalent to row 11 in Table 4 mentioned above.

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

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

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

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

[0124] Rows 4-8 in Table 7 relate to the first input, i.e., the previous transaction ID-500 that funded the current transaction ID-510. Row 4 is the transaction identifier of the previous transaction ID-500. Row 5, "IDX-00", is the index of the output of the previous transaction ID-500 (in this case, a reference indicating that the first output from the previous transaction ID-500 should be used). Row 6 is "Script length", an indication of the script length. Row 7 is "ScriptSig", the unlocking script for the previous transaction ID-500. As shown, the previous transaction ID-500 was locked using the first user (A) public key (P1A) represented by PubK-Alice and the first issuer public key (P1I) represented by PubK-Issuer. Therefore, previous transactions can be unlocked using Alice's corresponding private key (V1A), represented as Sig-Alice, and the issuer's corresponding first issuer private key (V1I), represented as Sig-Issuer. Row 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 amount of cryptocurrency received from the previous transaction ID-400. Rows 11-15 in Table 7 relate to the second output, namely the payment of the miner's fee. Row 11 is the transaction identifier for the previous transaction ID-400. Row 12, "IDX-01", is the index of the output for the previous transaction ID-400. Row 13 is "Script length", which is the indication of the script length. Row 14 is "ScriptSig", which is the unlocking script for the previous transaction ID-400. Since the cryptocurrency from this transaction ID-400 is not associated with a token (or a user associated with a token), the redemption script hash is simply the hash of the first user's public key (P1A), which is shown as PubK-Alice. In other words, to use the output from transaction ID-400, this simply requires signing with the first user's private key (V1A). Line 15 is the sequence number associated with the input.

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

[0127] "OP_HASH160" is the type of hash function, where the input is hashed twice, first by SHA-256 and then by 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, which in this example is: 1 metadata1 metadata2 PubK-Bob 3 OP_CHECKMULTISIG

[0128] This redemption script includes metadata from the token (T) and the issuer's public key (P1I), which is shown as the PubK-Issuer. metadata1 and metadata2 may include the metadata mentioned above, including an indication that this is a “payment” transaction. This redemption script requires one of three signatures to use 10,000,000 satoshi. In fact, the second user's private key (V1B) may be used to sign and use the cryptocurrency for the subsequent transaction. It is worth noting that the first user's public key (P1A) is not present in this redemption script. This can be considered as the token (T), and therefore the associated amount of cryptocurrency, being transferred to the second user (B)7 and thus used by the first user (A)5. Therefore, the second user (B)7 should be free to use the token (T) without requiring permission (such as implicit permission through the first user (A)5's signature).

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

[0130] However, consider a scenario where the service provider (SPA) of the first user (A)5 is not located within the same Web of Trust as the issuer (I), and the token (T) associated with transaction ID-510 is not signed by the signatory. In such a situation, the redemption script for the previous transaction ID-500, shown in row 7 of Table 7, would instead take the following form in this example: 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 input to transaction ID-510, is not signed by the signatory, and therefore the second user (B) 7 cannot be certain of the legitimacy of the token (T) by considering the redemption script (RS) as referenced solely as input providing funds to transaction ID-510.

[0132] Rights Registration Store As illustrated with reference to Figure 1, in some embodiments, System 1 includes a rights registration store 23 that can be controlled or influenced by a control / management application running on one or more processing devices 21. For example, a management application containing executable code may be stored in the memory 1520 (Figure) of one or more processing devices 21, and one or more processors 1510 (Figure 8) of one or more processing devices 21 may be configured to run the management application which performs a method for managing the rights registration store 23. The rights registration store 23 may be configured to record information about transactions related to the transfer of tokens.

[0133] In some embodiments, the registration store 23 holds 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 registration store 23 may include a list or sublist of validated or validated unused transaction outputs (UTXOs). For example, if a transaction is recorded in the registration store 23, the registration store 23 may include at least one of a transaction identifier and an output script for the transaction, including an indication of the current owner, i.e., the current owner's public key, embedded in the metadata of the redemption script hash. The previous owner may be determined from the public key identified in the unlocking script of the transaction's input section.

[0134] However, in other embodiments, the rights registration store 23 may additionally or alternatively include identifiers of the token's current and / or previous owners. For example, the rights registration store 23 may include “Know Your Customer” (KYC) registers for direct and / or indirect clients. In some embodiments, the maintenance of KYC registers may be a clause in the contract associated with the token, such as a condition of ownership. In such embodiments, the condition of the token's validity may require a payee, such as a second user (B) 7, to register directly with the party (P) or issuer (I). This can be achieved, for example, through an off-blocking mechanism such as via a dedicated webpage, or by appropriate checks such as requiring a signature to prove 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 a DHT configured to store the contract conditions 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 concerns the joint ownership of a racehorse, the issuer may need to identify which party is entitled to receive their share of the prize money.

[0135] 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 one or more processing devices 19 via the communication network 8, and to store the data in the rights registration store 23. Similarly, one or more processing devices 21 may be configured to retrieve data from the rights registration store 23 automatically, for example, in response to a request for data and / or at predetermined or periodic intervals, and to provide the retrieved data to the first processing device 13, the second processing device 15, and / or the third processing device 17, and / or one or more processing devices 19 via the communication network 8.

[0136] In some embodiments, recording a transaction involving the transfer of a token (T) issued by issuer (I)3 in the rights registration store 23 is initiated by the issuer (I)3 of that token (T). For example, in addition to creating a token (T) for a user such as first user (A)5 or second user (B)7, issuer (I)3 sends the first data output (O1) described above in 314 in connection with the method 300 for creating the token to blockchain 9, then, using one or more processors 13, sends a request to the management application of the rights registration store 23 to record the transfer of the token, via the communication network 8 to one or more processors 21 associated with the rights registration store 23. The token issuer may also be responsible for maintaining or updating the rights registration store 23 with respect to transactions associated with the token, as will be 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 contracts associated with tokens. In some embodiments, the distributed hash table (DHT) configured to store contracts associated with tokens may include fields containing one or more links or pointers that point to the location of the relevant entry in the distributed hash table (DHT) of the rights registration database 23.

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

[0139] A method 500 for maintaining a rights registration store 23 for recording the transfer of tokens issued by an issuer (I), where each token is associated with a cryptocurrency amount, is described below with reference to Figure 5. In some embodiments, a rights registration maintenance application, including executable code, may be stored in the 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 run the rights registration maintenance application that performs the method 500 for maintaining a rights registration store for recording the transfer of tokens. In other embodiments, the method 500 may be performed by a processing device (not shown) associated with an authorized party (P) connected to a communication network 8.

[0140] When executing Method 500, the maintenance application is configured in 502 to monitor Blockchain 9 for transactions that include the transfer of tokens issued by Issuer (I).

[0141] Blockchains such as the Bitcoin blockchain record transactions and may include transaction details (TXs), such as the identifier of a previous transaction (previous transaction identifier), one or more input scripts, and one or more output scripts. As mentioned above, the token associated with a transaction can be identified from the metadata of the transaction's input script.

[0142] In response to identifying a transaction involving the transfer of a token (T) issued by an issuer (I), the maintenance application is configured to record the token (T) transfer in the rights registration store 23. For example, in some embodiments, as shown in Figure 5, the maintenance application is configured to send a request to record the token (T) transfer in the rights registration 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 registration store 23.

[0143] In some embodiments, the above requirement may include data that includes an indicator of a transaction involving the transfer of a token (T). For example, this data may include the transaction identifier and / or first data output (O1) of the transaction. In some embodiments, the authenticity of this data is verified by issuer (I)3, for example, by being signed with issuer signature (V1I). This data may be obtained from the transaction details of the token recorded on blockchain 9.

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

[0145] Verification of transaction-associated tokens (T) using a rights registration store. A method 600 for determining the validity of a token (T) associated with a cryptocurrency amount using a rights registration store 23 is described below with reference to Figure 6. In some embodiments, a verification application containing executable code may be stored in the memory 1520 of the processing device 17 (Figure 8), and one or more processors 1510 of the processing device 17 (Figure 8) are configured to run the verification application which performs the method 600 for determining the validity of a first token (T1) associated with a first cryptocurrency amount (B1). The method 600 may be performed by the processing device 17 associated with a second user (B) 7.

[0146] The first user (A) can send a first transaction to the second user (B) in 602, which includes the transfer of the first token (T1). When executing method 600, the verification application is configured in 604 to receive the first transaction, which includes the transfer of token (T) from the first user (A) to the second user (B), via the communication network 8. The first transaction may include a blockchain transaction for the transfer of some cryptocurrency, such as those described in relation to Table 7 above. For example, a transaction may include a transaction ID, one or more inputs, and one or more outputs. One or more inputs may relate to one or more previous transactions, each including an unlocking script which includes the ID of the previous transaction (previous transaction ID) and a redemption script associated with the first token (T1). At least one of the one or more outputs may relate 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 verification application is configured in 606 to determine whether the authenticity of the token (T) has been proven. For example, this may include determining whether the redemption script associated with the token (T), which is referenced as input to the first transaction, has been signed by a signatory, such as the token issuer or a trusted service provider.

[0148] The verification application determines, in 608, an indicator of a second transaction or a previous transaction that involves the transfer of token (T). The second transaction may be a previous transaction that is temporally earlier than 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 several input parameters of the current transaction.

[0149] The verification application in 610 is configured to use an indicator to query the rights registration database 23 to determine whether the second transaction is recorded in the rights registration store 23. For example, if the second transaction is 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, the validity of a token can be determined without knowing who the previous or last owner was. Accordingly, embodiments of the present invention provide a novel and advantageous verification technique that solves technical problems not addressed by the prior art.

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

[0151] In response to determining that the second transaction has been recorded or registered in the rights registration store 23, the verification application is configured to determine in 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 verification application is configured to determine in 614 that the token (T) is invalid. However, in other embodiments, in response to determining that the second transaction is not registered in the rights registration store, the verification application is configured to perform steps 710-714 of method 700 as described below in 614.

[0153] Validation of transaction-associated tokens (T) using blockchain. A method 700 for determining the validity of a token (T) associated with a cryptocurrency amount using blockchain 9 is described below with reference to Figure 7. In some embodiments, a verification application containing executable code may be stored in the memory 1520 of the processing device 17 (Figure 8), and one or more processors 1510 of the processing device 17 (Figure 8) are configured to execute the verification application which performs the method 700 for determining the validity of a token (T) associated with a cryptocurrency amount. The method 700 may be executed by the processing device 17 associated with a second user (B) 7.

[0154] The first user (A) can send a first transaction, including the transfer of a token (T), to the second user (B) in 702. When executing method 700, the verification application is configured to execute steps 704 and 708, which correspond to steps 604 and 608 of method 600 described above in relation to Figure 6. In some embodiments, the verification application is configured to execute step 706, which corresponds to step 606 of method 600 described above in relation to Figure 6.

[0155] The verification application is configured to query blockchain 9 at 710 using indicators of previous transactions to determine whether it can identify a verified transaction associated with token (T). A verified transaction includes a transaction associated with token (T) in which the legitimacy of token (T) is recognized. For example, a token may be recognized or considered legitimate if the redemption script associated with token (T) is signed by an authorized signatory such as the issuer of token (T) or a trusted service provider. The signature may include a digital cryptographic signature.

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

[0157] In some embodiments, querying blockchain 9 involves comparing the indicator of a previous transaction with the corresponding indicator of a transaction recorded in blockchain 9 to identify a previous transaction that has the same indicator as the previous transaction's indicator. For example, the indicator of a previous transaction may include the previous transaction ID shown in the first transaction.

[0158] The verification application is configured to iteratively identify legitimate transactions associated with tokens for entries in Blockchain 9. Therefore, for example, if the most recent transaction identified in Blockchain 9, associated with token (T), is not a legitimate transaction, the verification application is configured to identify or locate the token-associated transaction immediately preceding the most recent transaction and determine whether this transaction is legitimate. If the token-associated transaction immediately preceding the most recent transaction is not a legitimate transaction, the verification application is configured to identify or locate an even earlier transaction associated with the token and determine whether this transaction is legitimate.

[0159] In some embodiments, the verification application is configured to determine whether the most recent or earlier transaction is a valid transaction, including determining whether the redemption script associated with the token, which is referenced as input to the transaction, is signed by a signatory such as the issuer of the token (T) or a trusted service provider.

[0160] In some embodiments, when a transaction recorded on blockchain 9 is determined not to be a valid transaction, the verification application is configured to identify an indicator of a previous transaction from the transaction entry and to use the indicator of the previous transaction to identify an entry for the previous transaction in blockchain 9. The indicator may include a previous transaction ID associated with the transaction. For example, in some embodiments, the verification application is configured to identify or pinpoint a transaction immediately preceding or even earlier than the most recent transaction by determining the identifier of a previous transaction from the input script of the most recent or earlier transaction. This process is performed iteratively until it is no longer possible to identify a previous transaction.

[0161] Accordingly, the present invention provides an advantageous verification technique that includes the dynamic construction of a logical hierarchy of related blockchain transactions. This hierarchy is constructed using multiple sources, starting from the first transaction, because the 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 such data in the verification process.

[0162] If the verification application identifies a transaction that is deemed legitimate, method 700 proceeds to step 712. On the other hand, if the verification application does not identify a transaction that is deemed legitimate, method 700 proceeds to step 714.

[0163] In Blockchain 9, the verification application is configured to determine in 712 that a token (T) is valid, depending on whether it has identified a transaction whose authenticity has been proven. For example, if the verification application determines that the redemption script for a previous transaction was signed by the signatory, the verification application identifies the previous transaction as a valid transaction.

[0164] In some embodiments, in blockchain 9, the verification application is configured to determine in 714 that the token (T) is invalid if it does not identify a transaction whose authenticity has been proven.

[0165] Processing device As described above in relation to Figure 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. Rights registration database 23 may also be associated with one or more processing devices 21. Such processing devices may be part of electronic devices such as computers, tablet computers, mobile communication devices, and computer servers. In addition to processing devices, electronic devices may include a data store 11 and a user interface (not shown).

[0166] Figure 8 shows 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. The memory 1520 stores instructions and data for implementing methods of the present disclosure, including methods 300, 500, 600, and 700, and the processor 1510 executes these methods by executing instructions from the memory 1520. The interface device 1540 facilitates communication with a communication network 8 and may include a communication module (not shown) that facilitates communication with peripherals and user interfaces such as a data store 11 in some examples. Note that processing devices may include independent network elements, but 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, and 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] Where this disclosure states that a user, issuer, merchant, provider, or other entity performs certain actions (including, but not limited to, signing, issuing, determining, calculating, transmitting, receiving, and creating), this statement is used for clarity of presentation. It should be understood that these actions are performed by computing devices operated by these entities.

[0168] Signing a message may involve executing a cryptographic function. A cryptographic function takes inputs of plaintext and inputs of a key, such as a private key. A processor can execute 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 deliver the signed text. If even one bit of the message text or key changes, the signature changes completely. Computing a signature requires only minimal computational power, but recreating a message with a given signature is practically impossible. Thus, if a private key is available, all that is needed is to modify the plaintext and accompany it with a valid signature. Furthermore, other entities can easily verify the signature using a publicly available public key.

[0169] In most situations, encryption and decryption involve a processor executing cryptographic functions to calculate output strings that represent the encrypted message or the plaintext message, respectively.

[0170] Keys, tokens, metadata, transactions, offers, contracts, signatures, scripts, invitations, and similar items refer to data that is represented as numbers, text, or strings stored in data memory, such as variables of the program code type "string" or "int" or other types, or text files.

[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, from which the fee or funds are output. An example of a Bitcoin transaction includes an input transaction hash, a transaction amount, one or more recipients, the public keys of one or more payees, and a signature created by calculating the 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 by checking that the signature is correct using the public keys. To ensure that the same input transaction hash is not already used anywhere else, the transaction is broadcast to a network of computing nodes ("miners"). A miner accepts the transaction and records it on the blockchain only if the input transaction hash is not already linked 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 involves creating a transaction in which the allocated cryptocurrency and token are represented in a metadata field within the transaction.

[0173] When two items are associated, this means that a logical connection exists 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 compute 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 using a private key to calculate a transaction signature string and providing that signature string to the other entity so that the other entity can use the signature to verify the transaction.

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

[0177] Those skilled in the art will understand that numerous modifications and / or changes are possible to the embodiments described above without departing from the broad general scope of this disclosure. Therefore, these embodiments should be considered in all respects as illustrative rather than restrictive. [Explanation of symbols]

[0178] 3. Publisher 5. First User 7. Second User

Claims

1. A computer-based method for determining the validity of a token present in the metadata field of a first transaction, The first transaction was, The amount of cryptocurrency associated with the aforementioned token, A hash of a redemption script, wherein the redemption script includes metadata and at least one public cryptographic key, and includes a hash of a redemption script, The aforementioned method, The steps include receiving the first transaction, which includes the transfer of the token from the first user to the second user, via a communication network, The step of determining whether the first transaction is a verified transaction associated with the token by determining whether the redemption script is signed with a verified signature, If the first transaction is not determined to be a verified transaction, the peer-to-peer distributed ledger is queried, passing through entries in the peer-to-peer distributed ledger, and until a verified transaction is identified or a previous transaction is not identified, the following: i) Identifying or identifying previous transactions associated with the token, ii) To determine whether the authenticity of the token associated with the preceding transaction has been proven, The process involves repeating the steps to determine whether a transaction associated with the token, whose authenticity has been proven, can be identified. The steps include determining that the token is valid in response to identifying a transaction whose authenticity has been verified in the peer-to-peer distributed ledger, A method that includes this.

2. The method according to claim 1, wherein the step of querying the peer-to-peer distributed ledger includes the step of querying the peer-to-peer distributed ledger in response to determining that the authenticity of the token of the first transaction has not been proven.

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

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

5. The steps to query a peer-to-peer distributed ledger are: a) A step of determining the previous transaction ID shown in the first transaction, b) A step of identifying a previous transaction recorded in the peer-to-peer distributed ledger, wherein the transaction ID of the previous transaction corresponds to the determined previous transaction ID, c) A step of determining whether the redemption script for the previous transaction is signed with a signature whose authenticity has been proven, d) In response to determining that the redemption script for the preceding transaction is signed with a certified authentic signature, the step of identifying the preceding transaction as a certified authentic transaction, e) In response to determining that the redemption script for the preceding transaction is not signed with a verified signature, The step of determining the previous transaction ID shown in the aforementioned previous transaction as the previous transaction ID, A step of identifying an earlier transaction recorded in the peer-to-peer distributed ledger as a previous transaction, wherein the transaction ID of the earlier transaction corresponds to the previous transaction ID, f) The step of repeatedly executing steps c) to e) until an even earlier transaction is identified, The method according to claim 1, including the method described in claim 1.

6. The method according to claim 1, further comprising the step of determining that the token is invalid in response to the inability to identify an authentic transaction in the peer-to-peer distributed ledger.

7. A token verification system for determining the validity of tokens associated with a quantity of cryptocurrency, the system comprising: a memory for storing a verification application; and a processor, the processor being configured to execute the verification application to perform the method according to claim 1.

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

Images