Single-Use Tokens

Abstract

1. A computer-implemented method for issuing one or more single-use tokens for use by one or more respective token redeemers using a blockchain transaction, the method being executed by a token issuer and comprising: generating a token transaction, the token transaction including one or more token outputs, each token output including token data representing a respective single-use token, each single-use token being associated with a respective usable output of the token transaction, the validity of each single-use token being conditioned on the presence of each usable output in a set of unspent transaction outputs of the blockchain; and one or more inputs, at least a first of the inputs including a signature linked to a first public key of the token issuer; and submitting the token transaction to one or more nodes of a blockchain network for recording on the blockchain.

Description

[Technical Field]

[0001] The present disclosure relates to a method for using a blockchain to issue single-use tokens. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a replicated copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain includes a chain of blocks of data, each containing one or more transactions. Each transaction may point to a preceding transaction in a sequence that may span one or more blocks. Transactions may be submitted to the network for inclusion in a new block by a process known as "mining," which involves multiple mining nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in a blockchain are used to transfer digital assets, i.e., data that acts as a store of value. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing for the incorporation of more complex data. For example, this can be used to store electronic documents or even audio or video data on the blockchain.

[0004] Each node in the network can play any one, two, or all three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own copies of mined blocks in the blockchain. To record a transaction in the blockchain, a party sends the transaction to one of the nodes in the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, additional user data remains stored at each of the nodes in the P2P network as an immutable public record. Summary of the Invention

[0005] One of the fundamental features of some blockchain protocols is the prevention of double-spending. This security feature has withstood the test of real life for the past decade and remains unchallenged. One implication of the inability to double-spend is the single-use of unspent outputs of blockchain transactions. The present invention leverages the single-use property of blockchain transaction outputs to enable the issuance of single-use tokens on the blockchain. Single-use tokens can be, for example, movie tickets, gift cards, afternoon tea vouchers, airline tickets, etc. Embodiments not only ensure that tokens are single-use, but also provide immutability, transparency, and auditability of records.

[0006] According to one aspect disclosed herein, there is provided a computer-implemented method for issuing one or more single-use tokens for use by one or more respective token redeemers using a blockchain transaction, the method being executed by a token issuer and including: generating a token transaction, the token transaction including one or more token outputs, each token output including token data representing a respective single-use token, each single-use token being associated with a respective usable output of the token transaction, and the validity of each single-use token being conditioned on the presence of each usable output in a set of unspent transaction outputs of the blockchain; and one or more inputs, at least a first of the inputs including a signature linked to a first public key of the token issuer; and submitting the token transaction to one or more nodes of a blockchain network for recording in the blockchain.

[0007] A token output is the output of a blockchain transaction (a "token transaction") that contains data representing a single-use token. A single-use token is a token that is valid for only a single use; e.g., a single-use token can be exchanged or redeemed only once for a given product (or set of products) or service. Single-use tokens cannot be reused. Each single-use token is associated (or linked) to a respective spendable output of the token transaction. The spendable outputs remain in the blockchain's unspent transaction output (UTXO) set until they are spent (spended) using a later blockchain transaction. If the spendable output of a token transaction is in the UTXO set, the associated single-use token is valid and can be spent, e.g., redeemed for a product or service. If the spendable output of a token transaction is not in the UTXO set, the associated single-use token has been spent (or expired) and therefore cannot be spent.

[0008] According to another aspect disclosed herein, there is provided a token transaction for a blockchain including: one or more token outputs, each token output including token data representing a respective single-use token, each single-use token associated with a respective usable output of the token transaction, and a respective validity of each single-use token being conditioned on the respective usable output being present in a set of unspent transaction outputs of the blockchain; and one or more inputs, at least a first of the inputs including a signature linked to a first public key of a token issuer. [Brief explanation of the drawings]

[0009] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4A] FIG. 2 is a schematic block diagram of a client application. [Figure 4B] 4B is a schematic mock-up of an exemplary user interface that may be presented by the client application of FIG. 4A. [Figure 5] FIG. 1 is a schematic block diagram of some node software for processing transactions. [Figure 6] FIG. 1 is a schematic block diagram of a system for implementing single-use tokens on a blockchain. [Figure 7] 1 is a schematic diagram of the requirements of an exemplary system for issuing prescriptions to patients. [Figure 8] FIG. 1 is a schematic diagram of the role of trusted authorities and medical databases in an exemplary system for issuing prescriptions to patients. [Figure 9] FIG. 6 is an exemplary sequence diagram for a prescriber 601 to issue a prescription to a patient. [Figure 10] FIG. 1 is an exemplary sequence diagram for a patient to redeem a prescription with a pharmacist. DETAILED DESCRIPTION OF THE INVENTION

[0010] Exemplary System Overview FIG. 1 generally illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer's computing equipment, with different ones of the nodes 104 belonging to different peers. Each node 104 includes a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0011] The blockchain 150 includes a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each standard transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the amount of digital assets belonging to a user 103 that the output is cryptographically locked (requiring that user's signature to be unlocked and thereby redeemed or spent). Each input points to the output of a previous transaction 152, thereby linking the transactions.

[0012] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward transactions 152, thereby propagating them. At least some of the nodes 104 assume the role of miners 104M, which mine blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes called "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0013] For a given current transaction 152j, the input (or each input) contains a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. In general, a preceding transaction can be any transaction in the pool 154 or any block 151. While a preceding transaction 152i must exist and be validated for the current transaction to be valid, a preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or transmitted to the network 106. Thus, "preceding" herein refers to something that precedes it in the logical sequence linked by a pointer, not necessarily to the time of creation or transmission in the time sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i is also referred to as an antecedent transaction or a predecessor transaction.

[0014] The input of the current transaction 152j also includes the signature of user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to new user 103b, as defined in the output of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to divide the input amount among multiple users (one of which can be the original user 103a to provide the change). In some cases, a transaction can also have multiple inputs to combine amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0015] The above may be called an "output-based" transaction protocol, and sometimes called an unspent transaction output (UTXO) type protocol (where outputs are called UTXOs). A user's total balance is not defined by any one number stored in the blockchain; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

[0016] An alternative type of transaction protocol, as part of an account-based transaction model, may be called an "account-based" protocol. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of every account is stored and constantly updated by miners separately from the blockchain. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, optional data fields in a transaction may also be signed. This data field may point to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0017] Using any type of transaction protocol, when a user 103 wishes to complete a new transaction 152j, the user sends the new transaction from the user's computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or data center, but could in principle be another user terminal). The nodes 104 check whether the transaction is valid according to a node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 and collectively form a transaction model. The node protocol typically requires the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may involve checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i used by the new transaction, which typically includes at least checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, the condition may be defined at least in part by custom script included in the input and / or output. Alternatively, the condition may be fixed solely by the node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106.At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of nodes 104.

[0018] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has been validly redeemed by the input of another prior transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transition 152i that it attempts to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double-spending, where a user attempts to spend the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because transaction ordering is defined, account balances are always in a single, defined state.

[0019] In addition to validation, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is supported by "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a certain, predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output for its input. This search, therefore, can only be performed brute force, consuming a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0020] The miner node 104M that first solves the puzzle publishes it to the network 106, providing a proof of its solution that can later be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to check that the hash output satisfies the condition). The pool 154 of transactions for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 functioning as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. Proof of work helps reduce the risk of double spends because it takes a lot of effort to create a new block 151, and mining nodes 104M are incentivized to avoid including double spends in their blocks because blocks containing double spends are likely to be rejected by other nodes 104. Once created, blocks 151 cannot be modified because they are recognized and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

[0021] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue competing to create blocks from the newly defined unmined pool 154, and so on. There are also protocols for resolving any "forks" that can occur if two miners 104M solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to propagate. In essence, whichever prong of the fork grows the longest results in the final blockchain 150.

[0022] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that suddenly creates a new amount of digital assets (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). The winning node is therefore said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "producing" transaction; it automatically forms part of the new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. Often, a regular (non-producing) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M who created the block 151n containing that transaction.

[0023] Due to the computational resources involved in mining, typically at least each of the miner nodes 104M takes the form of a server including one or more physical server units, or an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0024] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its respective one or more roles and process transactions 152 in accordance with the node protocol. It will be understood that any action attributed to a node 104 herein may be performed by software executing on the respective computing device's processing unit. Additionally, the term "blockchain," as used herein, is a generic term generally referring to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0025] Also connected to the network 101 are computer devices 102 for each of multiple parties 103 acting as consuming users. These act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice, and the second party 103b will be referred to as Bob; however, this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0026] The computing equipment 102 of each party 103 comprises a respective processing unit including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any action attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0027] The client application or software 105 may be initially provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example, downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0028] The client application 105 has at least a "wallet" functionality. It has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 that are propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that they currently own. In an output-based system, this second function involves reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0029] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect other parties' transactions in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to formulate and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol works in conjunction with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow for different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although it may process different subtypes of transactions differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0030] As noted, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process described above. Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. The blockchain 150 also includes a pool 154 of valid transactions waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the originating transaction) includes a pointer back to a previous transaction to define an order for the sequence of transactions (note: the sequence of transactions 152 can diverge). The chain of blocks 151 stretches all the way back to the originating block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the originating block 153 rather than to a preceding transaction.

[0031] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction (using a wallet function in Alice's client application 105) according to the relevant transaction protocol. From her client application 105, Alice then sends the transaction 152 to one of one or more forwarding nodes 104F to which Alice is connected. For example, this may be the forwarding node 104F closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which are described in more detail below. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0032] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will immediately propagate throughout the P2P network 106.

[0033] Once admitted to pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, miner nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152j. (Other miners 104M may be trying to solve the puzzle based on older views of pool 154, but whoever gets there first will define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once proof-of-work is done for pool 154 that contains new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152 contains a pointer back to the previous transaction, the order of transactions is also immutably recorded.

[0034] UTXO-based model Figure 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following description will be given with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible implementations.

[0035] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It may also include, among other information, the transaction ID of the underlying transaction. The transaction data structure may also include a header 201, which may include indicators indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0036] Note that although each output in Figure 2 is shown as a UTXO, a transaction may additionally or alternatively include one or more unspendable transaction outputs.

[0037] Suppose Alice 103a wishes to create transaction 152j to transfer an amount of the digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can refer to any previous (i.e., earlier) transaction that still has unspent output 203 locked for Alice.

[0038] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates the new transaction Tx1, or at least by the time Alice submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent” as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may similarly be interchanged with “preceding” and “successor,” or “earlier” and “later,” “parent” and “child,” etc. This does not necessarily imply the order of their creation, transmission to the network 106, or arrival at any given node 104. However, a subsequent transaction (a later transaction or "child") that points to a preceding transaction (an earlier transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be buffered for a certain amount of time to wait for its parent or discarded, depending on the node protocol and / or minor behavior.

[0039] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a locking script, which defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be validated and therefore the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines unlocking conditions, which include the condition that the unlocking script in the input of the subsequent transaction contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0040] A lock script (commonly called scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A lock script specifies what information is needed to use the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (commonly called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0041] That is, in the illustrated example, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Requires a lock script [Checksig P A ]. [Checksig P A ] is Alice's public key P from her public-private key pair. ATx1's input 202 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0 to identify it among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0042] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > || <P A > [Checksig P A ] where '||' denotes concatenation, '<...>' means to put data on the stack, and '[...]' are functions that compose the unlock script (a stack-based language in this example). Equivalently, the scripts could be executed one after the other using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will create a new lock script containing Alice's public key P as contained in the lock script in the output of Tx0. A, to authenticate that the lock script in Tx1's input contains Alice's signature, who signed the expected portion of data. The expected portion of data itself (the "message") must also be included in the Tx0 instruction to perform this authentication. In an embodiment, the signed data includes the entirety of Tx0 (i.e., a separate element specifying the signed portion of the plaintext data need not be included, as it is already inherently present).

[0043] The details of authentication using public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the plaintext message (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature on the plaintext version of the message, allowing any holder of the public key to authenticate the signature.

[0044] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (i.e., in the illustrated example, Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If it is a mining node 104M, this means adding it to the pool 154 of transactions awaiting work of proof. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106 so that transaction Tx1 is propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it attempts to use outputs already spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0045] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave behind" a portion of the amount defined in the UTXO as spent; another portion is spent. However, it is possible to split an amount from a UTXO among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob all of the amount defined in UTXO0, she can use a reminder to give the remainder to herself or to pay another party in the second output of Tx1.

[0046] In practice, because the reward for generating transactions alone is typically not enough to incentivize mining today, Alice also typically needs to include a fee for the winning miner. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner nodes 104M, and therefore, even if technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force miners 104M to accept transactions 152 if they do not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 is automatically given to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference is automatically awarded to the winning miner 104M. However, it is not necessarily excluded that a miner's fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0047] Note also that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated to block 151 or mined.

[0048] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere in the blockchain 150 is a number stored defining the given party's 103 total balance. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the storage nodes 104S, e.g., the storage node 104S closest to or best connected to each party's computer device 102.

[0049] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ], then [Checksig P A ] = OP_DUP OP_HASH160 <H(P A)> OP_EQUALVERIFY may mean OP_CHECKSIG. "OP_..." refers to a specific opcode in a scripting language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, the occurrence of the signature ("sig") is removed from the script, but additional requirements, such as a hash puzzle, remain for transactions verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for creating an unusable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata may include a document desired to be stored on the blockchain.

[0050] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific portion of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portion of the outputs signed depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature (and is therefore fixed at the time of signing) to select which outputs are signed.

[0051] A lock script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, any condition or conditions can be defined using a scripting language. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0052] FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as that described in connection with FIG. 1, except that additional communication functionality is included. Client applications on Alice's and Bob's respective computing devices 102a, 102b each include the additional communication functionality. That is, it allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the direction of either party or a third party). The side channel 301 allows for the exchange of data outside of the P2P network. Such communication is sometimes referred to as "off-chain." For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being published on the P2P network 106 or progressing on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Alternatively or additionally, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0053] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 301 referenced anywhere herein may include any one or more links over one or more networking technologies or communications media for exchanging data “off-chain,” i.e., separately from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, when Alice and Bob are said to exchange information or particular portions of data, etc., over the side channel 301, it should be noted that this does not necessarily mean that all of these portions of data must be transmitted over the exact same link or the same type of network.

[0054] Client Software 4A shows an example implementation of a client application 105 for implementing embodiments of the techniques disclosed herein. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or submitting transactions for propagation through the P2P network 106, in accordance with the techniques described above and as described in further detail below. According to embodiments disclosed herein, the transaction engine 401 of each client 105 includes functionality 403 for generating transactions that include one or more single-use tokens.

[0055] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computing device 102, which includes outputting information to each user 103 via the device's 102's user output means and receiving input from each user 103 via the device's 102's user input means. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may include, for example, one or more touchscreens (the same or different from / to those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or voice recognition algorithms for receiving speech or audio input, one or more gesture-based input devices for receiving input in the form of manual or physical gestures, or one or more mechanical buttons, switches, or joysticks, etc.

[0056] It should be noted that while various functionality herein may be described as being integrated into the same client application 105, this is not necessarily limiting and may instead be implemented as a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between two or more applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. When reference is made anywhere herein to a single or given application 105, etc., it will be understood that this is merely an example and that, more generally, the described functionality may be implemented in any form of software.

[0057] 4B shows a mockup of an example user interface (UI) 400 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b on Bob's device 102b, or by any other party.

[0058] 4B shows UI 400 from Alice's perspective. UI 400 may include one or more UI elements 411, 412, 413 that are rendered as separate UI elements via user output means.

[0059] For example, the UI elements may include one or more user-selectable elements 411, which may be different on-screen buttons, or different options in a menu, etc. User input means are configured to allow the user 103 (in this case Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen or by speaking the name of the desired option (Note: the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to the use of one or more hands). Optionally, the user (Alice) may generate transactions with single-use tokens and define the rules, terms, and / or conditions for the tokens.

[0060] Alternatively or additionally, the UI element may include one or more data entry fields 412 through which a user can generate a token transaction. These data entry fields may be rendered via a user output means, for example on a screen, and data may be entered into the fields through a user input means, for example a keyboard or touch screen. Alternatively, data may be received dictated, for example based on speech recognition.

[0061] Alternatively or additionally, the UI elements may include one or more information elements 413 that are output to output information to the user, for example, this / these may be rendered on a screen or audibly.

[0062] It will be understood that the particular means of rendering the various UI elements, selecting options, and entering data is not important. The functionality of these UI elements will be described in more detail below. It will also be understood that the UI 400 shown in Figure 4B is merely a schematic mockup and may, in fact, include one or more additional UI elements that are not shown for the sake of brevity.

[0063] Node Software FIG. 5 illustrates example node software 500 running on each node 104 of the P2P network 106 in an example UTXO or output-based model. The node software 500 includes a protocol engine 501, a script engine 502, a stack 503, an application-level decision engine 504, and a set of one or more blockchain-related function modules 505. In any given node 104, these may include any one, two, or all three of a mining module 505M, a forwarding module 505F, and a storage module 505S (depending on the node's role or roles). The protocol engine 401 is configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UTXO) j ) is received, the protocol engine 501 j The protocol engine 501 also identifies the unlock script in the Tx j Based on the pointer in the input of Tx i It identifies and extracts Tx i from each node's own pool 154 of pending transactions if Tx is not already on the blockchain 150, or i If already on the blockchain 150, Tx from a copy of the block 151 in the blockchain 150 stored on the respective node or another node 104 i In any case, the script engine 501 may extract Tx i identifies the lock script in the pointed output of and passes it to the script engine 502.

[0064] Therefore, the script engine 502 executes the Tx i The lock script and Txj and an unlock script from the corresponding inputs of . For example, while Figure 2 shows transactions labeled Tx0 and Tx1, the same could be true for any pair of transactions. The script engine 502 executes the two scripts together as described above, which includes placing data on and retrieving data from the stack 503 according to the stack-based scripting language being used (e.g., Script).

[0065] By executing the scripts together, the script engine 502 determines whether the unlock script satisfies one or more criteria defined in the lock script, i.e., whether the lock script "unlocks" the included output. The script engine 502 returns the result of this determination to the protocol engine 501. If the script engine 502 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0066] In an output-based model, the result "true" from the script engine 502 is one of the conditions for the validity of a transaction. Typically, Tx j The total value of the Digital Assets specified in the output(s) of Tx will not exceed the total value indicated by its input(s), and i There are also one or more further protocol-level conditions evaluated by protocol engine 501 that must also be satisfied, such as that the pointed-to output of has not already been consumed by another valid transaction. Protocol engine 501 evaluates the result from script engine 502 along with one or more protocol-level conditions and executes transaction Tx only if they are all true. j The protocol engine 501 outputs an indication of whether the transaction is valid to the application level decision engine 504. Tx jis actually validated, the decision engine 504 j 151. The mining module 505M may choose to control one or both of the mining module 505M and the forwarding module 505F to perform respective blockchain-related functions with respect to Tx j and / or the forwarding module 455F adds the Tx j to another node 104 in the P2P network 106. Note, however, that while in embodiments the decision engine 504 does not choose to forward or mine invalid transactions, this does not necessarily mean that it is obligated to trigger the mining or forwarding of valid transactions simply because they are valid. Optionally, in embodiments, the application-level decision engine 504 may apply one or more additional conditions before triggering either or both of these functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only on the condition that the transaction is valid and has sufficient mining fees remaining.

[0067] It should also be noted that the terms “true” and “false” herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, “true” can refer to any state that indicates a successful or positive outcome, and “false” can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model (not shown in FIG. 4), a “true” outcome may be indicated by a combination of an implicit (protocol-level) validation of the signature by node 104 and an additional positive output of the smart contract (where both individual outcomes are true, the overall outcome is considered to indicate true).

[0068] Single-Use Tokens 6 illustrates an exemplary system 600 for implementing an embodiment of the present invention that provides a method for issuing single-use tokens using blockchain transactions. As shown, a token issuer 601 issues a token transaction Tx token Generate a token transaction Tx and record it on the blockchain 150. token The token transaction Tx is sent to the blockchain network 106. token includes at least one output containing data representing a single-use token, i.e., a single-use token. token The token issuer 601 also includes an input containing the token issuer's 601 signature, i.e., a digital signature generated based on the private key corresponding to the token issuer's public key. The signature signs one, some, or all of the outputs, including the single-use token. The token redeemer 602 redeems the token transaction Tx token A redemption transaction Tx that redeems single-use tokens in redeem Generate a redemption transaction Tx as recorded on the blockchain 150 redeem to the blockchain network 106.

[0069] Token issuer 601 may be the same party referred to as Alice 103a with reference to Figures 1-3. That is, token issuer 601 may operate computing device 102a running client application 105a and may perform any of the actions attributed to Alice 103a. Similarly, token redeemer 602 may be the same party referred to as Bob 103a with reference to Figures 1-3. That is, token redeemer 602 may operate computing device 102b running client application 105b and may perform any of the actions attributed to Bob 103b.

[0070] In some examples, as shown in Figure 6, a token issuer 601 is a party that issues tangible assets to a token redeemer 602 in exchange for redeeming a single-use token. For example, the token issuer 601 may be a supplier of goods and / or services, and the token redeemer 602 may be a customer of the supplier. The token issuer 601 issues a token to the token redeemer, and when the token redeemer 602 uses the token, the token issuer 601 gives something to the token redeemer 602 in exchange.

[0071] In other examples, the token issuer 601 is a party that issues an intangible asset to a token redeemer 602 in exchange for the redemption of a single-use token. The single-use token may represent ownership of an intangible asset. For example, a single-use token may be issued in a redemption transaction Tx redeem A token redeemer 602 may represent ownership of votes that can be cast by redeeming a single-use token via

[0072] In some examples, the token redeemer 602 may provide assets to a third party (not shown in FIG. 6) when a single-use token is used. For example, the third party may provide the token redeemer 602 with information needed to redeem the single-use transaction (e.g., the transaction identifier TxID of the token transaction), and in exchange, the token redeemer 602 provides goods or services to the third party. The advantage of this is that the redemption transaction serves as an immutable record that the third party received the goods or services.

[0073] A token transaction includes one or more single-use tokens. Each single-use token is included in a separate output of the token transaction, and each single-use token is associated with a separate spendable output of the token transaction. Thus, when a token transaction is sent to nodes in the blockchain network 106 and recorded in the blockchain 150, each single-use token is linked to a separate unspent transaction output (UTXO). UTXO-based blockchains inherently have the properties of single-use transactions. Mining nodes are incentivized to ensure that transactions are not double-spended. Thus, any token linked to a UTXO cannot be spent more than once.

[0074] The token (i.e., the token data) may be encrypted. For example, the token data may be encrypted using the private key of the token issuer 601 or the token redeemer 602, or a common secret known to both the token issuer 601 and the token redeemer 602. Alternatively, the token may be a hash of the token data.

[0075] There are two ways to link (or associate) a token with a UTXO. First, the single-use token can be embedded within a non-spendable output of a token transaction, for example, the OP_RETURN payload. Non-spendable outputs cannot be spent, i.e., they are not unlocked. This first method indirectly links or associates the token with a UTXO. The table below shows a token transaction that embeds a single-use token within a non-spendable output: [Table 1]

[0076] The token issuer 601 can generate transactions and issue tokens. A transaction has at least one input and two outputs. The first output is a usable output. The status of the first output represents the validity of the single-use token. If the first output is used, the token is considered used. If the first output is unused, the token is still valid for use. The output may be identified as TXID1||0. The second output is an unusable output that contains all information about the token. For example, the token issuer 601 may put the terms and conditions of the token into the second output.

[0077] The input, or more precisely the signature in the input, links the two outputs. The token issuer 601 may sign the transaction to acknowledge that the first output is associated with (i.e., linked to) the second output.

[0078] An example of "[some locking script]" is: OP_HASH256 <h1>OP_EQUALVERIFY [P2PKH P A ] where h1 is the hash value of the OP_RETURN payload and P A is the public key of the token redeemer 602 or a third party. Including the hash puzzle in the locking script strengthens the linkage between the token and the UTXO.

[0079] The token issuer 601 may issue a transaction identifier for the token transaction to the token redeemer 602.

[0080] Second, the single-use token may be embedded within the usable output of the token transaction. Thus, the token is directly associated with the usable output in that the token is included within the usable output. For example, the token may be placed between the OP_PUSHDATA and OP_DROP opcodes. The opcodes are operation codes that operate on data contained within the transaction's lock or unlock script. For example, the opcodes may push (i.e., add) data onto a stack (e.g., an alternate stack), drop (i.e., remove) data from a stack, or perform a function (e.g., add, subtract, hash, etc.) on data on the stack. Those skilled in the art will be familiar with the opcodes themselves. The second method links the single-use token directly with the UTXO. Unlike the first method (i.e., linking the token with an unspendable output), the level of linkage is at the output level, not the transaction level. The following table shows a token transaction that embeds a single-use token within a usable output. [Table 2]

[0081] This particular example transaction has one input and one output. The output includes information about the token in the lock script. The input includes a signature from the token issuer 601 acknowledging the linkage between the token and the UTXO. As mentioned above, if the UTXO is spent, the token is spent and cannot be spent again. If the UTXO is unspent, the token is still valid for use.

[0082] An example lock script is below: <Token Data> OP_DROP [1-out-2 MultiSig K issuer Penalty kick A ]

[0083] The final part of the locking script is to allow either the token issuer 601 or the token redeemer 602 to spend the UTXO. When the token redeemer 602 uses the token, they are expected to spend the UTXO to reflect the token's use or redemption. The token issuer 601 can also be the party that uses the UTXO to indicate that the token has been used or revoked. More advanced locking scripts can be used to fit scenarios with different requirements.

[0084] The token issuer 601 may issue a transaction identifier for the token transaction to the token redeemer 602. The token issuer 601 may also provide an identifier for a particular output of the token transaction.

[0085] In these embodiments, a single token transaction may contain multiple single-use tokens. That is, a token transaction may include multiple spendable outputs, each containing a single-use token. Each token is associated with the spendable output (UTXO) that it contains. Thus, the validity of a given token depends only on the output being in the UTXO set, i.e., whether or not the output has been spent.

[0086] One, some, or all of the usable outputs associated with the single-use token (whether or not including the single-use token) may be locked to the token issuer's 601 public key and / or the token redeemer's 602 public key. For example, the usable outputs may be pay-to-public-key-hash (P2PKH) outputs locked to the token issuer's 601 public key, or the token redeemer's 602 public key, or a third party's public key. A P2PKH output includes a hash of a public key (public key hash) and requires that the inputs of the redemption transaction include, not necessarily in that order, a public key that hashes to the public key hash along with a signature generated using that public key. Alternatively, the usable outputs may be multi-signature outputs locked to one or both of the token issuer's 601 and token redeemer's 602 public keys, respectively. A multi-signature output is an n-of-m output containing a total of m public keys, requiring that the input for the redemption transaction contain at least n signatures corresponding to the public keys in the multi-signature output (i.e., generated based on their corresponding private keys). The same public key may be included more than once in the output.

[0087] In some examples, the usable output may include a hash of the single-use token. In embodiments where the token transaction includes multiple tokens, each usable output may include a hash of its respective token. The usable output may require that the input of the redemption transaction include a pre-image of the hash, i.e., the token data.

[0088] In some examples, the token issuer 601 may be the only party signing a token transaction. For example, the token issuer 601 includes a single input that signs the entire transaction. As another example, the token issuer may include multiple signatures within a single input. Each signature may have a different signature flag, i.e., each signature may sign a different number of inputs and / or outputs and therefore may sign different messages. The signature flag indicates which parts of the transaction the signature signs. The default is SIGHASH_ALL, which signs all parts of the transaction. Unsigned parts of the transaction can be modified. SIGHASH_NONE signals that only inputs are signed and that anyone can add or change outputs. SIGHASH_SINGLE signals that all inputs and corresponding outputs are signed, i.e., the signature in the first input signs the first output.

[0089] A token issuer 601 may also include multiple inputs, each signing a separate output. Alternatively, a token issuer 601 may include multiple inputs, where some sign one input and some sign all inputs. As described below, different signature flags may be used to sign different parts of a transaction.

[0090] When the token issuer 601 includes multiple signatures in a token transaction (whether they are included in the same input or different inputs), the signatures may be generated based on public keys that are linked to each other. For example, a second public key may be generated based on a first public key, e.g., a certified public key, and the first and second public keys (or rather, corresponding private keys) are used to generate multiple signatures, i.e., a first signature based on the first public key and a second signature based on the second public key. Alternatively, the second public key may be generated by appending the first public key to a third public key (e.g., a certified public key), and the first and second public keys (or rather, corresponding private keys) are used to generate multiple signatures.

[0091] In other examples, the token issuer 601 may include one or more inputs to sign the token transaction, and a different party (e.g., a second token issuer) may also include one or more inputs to sign the token transaction. For example, the second token issuer may grant the first token issuer 601 the authority to issue tokens by signing the token transaction.

[0092] A second, different token issuer may generate a token transaction template that includes the second token issuer's signature in the inputs. The second token issuer may then send the template transaction to the first token issuer 601, which adds an input that includes the signature of the first token issuer 601.

[0093] To renew or cancel a single-use token, the token issuer 601 may generate a renew transaction or a cancel transaction, respectively. The input of the renew or cancel transaction references the output associated with the token to be renewed or canceled and includes the data necessary to unlock the referenced output, e.g., a signature, pre-image, etc. If the token is being renewed, the renew transaction includes the renewed single-use token. If the token is being canceled, the cancel transaction includes data signaling that the token has been canceled.

[0094] Exemplary Use Case 1 - Medical Prescriptions The following describes how medical prescriptions can be issued on-chain to achieve traceability and patient confidentiality.

[0095] Main Actors · Patient Prescribers Pharmacist Trusted institutions Medical Database (Medical_DB)

[0096] Key Stages Prescribers register their credentials The prescriber signs the prescription transaction (i.e., the token transaction). Patient redeems prescription / Pharmacist dispenses prescription Prescribers cancel or amend prescriptions

[0097] Requirements 1. Patient identity confidentiality: Public and unauthorized actors should not be able to link patient IDs with prescriptions. 2. Patients may have the right to correct or erase their personally identifiable information. 3. The prescriber should be able to check the patient's identity. 4. Prescriptions should only be issued by authorized prescribers. Pharmacists and auditors should be able to check this authorization. 5. Authorized system actors should be able to access a patient's prescription history in a secure manner. 6. Medication utilization or inventory databases can be checked and should detect overuse. 7. Actors such as prescribers, pharmacists, and patients should be authenticated and authorized accordingly. 8. Authorized prescribers should be able to modify / cancel prescriptions that have not yet been dispensed or redeemed. 9. Prescriptions should only be filled by licensed pharmacists. 10. The prescriber may send the prescription directly to the patient's designated pharmacy without the patient being involved in the communication.

[0098] The requirements for an exemplary system are shown in FIG.

[0099] Prescription data typically includes personal identifying information (PII). A typical prescription might include: Patient's name, date of birth, and address Name and quantity of medication Important Notices for Patients and Pharmacists Prescription date Name of the prescriber

[0100] By uploading prescription data onto a blockchain, we generally benefit from the availability, immutability, and transparency characteristics of blockchain data storage. Most importantly, blockchain's ability to prevent double-spending. Personally identifiable information (PII) should not be held on a public, permissionless blockchain. Patient confidentiality is another important legal requirement, which means that only authorized access is given to PII. A solution that meets these requirements is to store only the part of prescription data that is not PII on the blockchain, which has the following characteristics: 1) PII such as patient names, dates of birth, and addresses will not be stored on the blockchain. 2) Non-PII prescription data such as drug name and quantity, as well as prescription dates, are stored on-chain. 3) The patient's wallet uses different receiving addresses for different transactions, i.e., one-time addresses P OTA can be used 4) The link between patient identities and their transaction addresses is kept off-chain, on a trusted server. When a pharmacist or prescriber needs to authenticate a patient's identity, they need to check if the address comes from the patient's wallet. The trusted server is then responsible for identifying and / or authenticating the patient to authorized actors.

[0101] This would satisfy the requirements of all use cases while having a system that provides auditability, availability, and integrity. Additionally, the trusted authority may perform the following tasks: 1. Registering users (including patients, prescribers, and pharmacists), which involves performing identification, authentication, and authorization checks. 2. Managing users' public key certificates. This includes signing, renewing, and revoking certificates that map users' identities and roles to their public keys, certificates that provide users with their authorized scopes (e.g., the drugs they are allowed to prescribe), and certificates for other entities such as hospitals and Medical_DB. 3. Controlling access to data mapping patient identities to their wallet addresses. This data is stored in the Medical_DB.

[0102] The Medical_DB 802 is a secure database managed by a trusted authority 801. The Medical_DB performs the following functions: 1. Store the link between patient identities and their public keys. This includes storing the patient's PII and the patient's transaction history. 2. Perform prescription checks during transactional prescription creation. These include checking the following: a. Prescriber Authorization b. Patient Identification and Authentication c. The patient's medical history. 3. If the prescription passes the check, the Medical_DB 802 co-signs the prescription transaction with the prescriber 601. 4. Interact with the blockchain to extract the patient's medical history.

[0103] A use case diagram for Trusted Authority and Medical_DB 802 is shown in FIG.

[0104] In the described system, authorized actors can perform different actions according to their roles and attributes. This is effectively an attribute-based access control model. For example: Prescribers can search patient medical history Prescribers can check patient identification and perform authentication checks Prescribers can create and sign prescription transactions Patients can check their prescription history Patients can co-sign reimbursement transactions.

[0105] 9 and 10 show an example sequence diagram when a prescriber (token issuer 601) and Medical_DB 802 issue a prescription to a patient 602. In this example, Medical_DB 802 is assumed to be a trusted authority that authenticates the prescriber 601 and co-signs the prescription transaction with the prescriber 601. The patient (token redeemer 602) redeems the prescription, and a pharmacist dispenses the prescription. That is, the patient 602 retrieves the prescription by using a prescription transaction (token transaction).

[0106] More specifically, as shown in Figure 9, the prescriber 601 first obtains a wallet address from the patient 602. After authenticating with Medical_DB 802 and the prescription being checked and verified, the prescriber 601 and Medical_DB 802 generate a prescription transaction (equivalent to a token transaction) that includes the single-use prescription. Both the prescriber 601 and Medical_DB 802 include their respective signatures in the transaction. The prescriber 601 then submits the prescription transaction to the blockchain.

[0107] As shown in Figure 10, patient 602 provides a prescription transaction including a prescription to pharmacist 1001. The pharmacist checks the signature in Medical_DB802. Pharmacist 1001 provides a wallet address to patient 602, who then generates a redemption transaction that is sent to the pharmacist's wallet address. Pharmacist 1001 can also sign the redemption transaction. Patient 602 or pharmacist 1001 submits the redemption transaction to the blockchain, and in exchange, the pharmacist provides the prescription to patient 602.

[0108] In some examples, the prescriber (token issuer 601) may need to register with a trusted authority, for example, an on-chain Certificate Authority (CA) 801 that registers prescribers and authorizes them for a set of authorized medications. There are various ways in which such a system can be realized using blockchain. The CA 801 may issue tokens to the prescriber to process transactions.

number

number

[0109] To authenticate her wallet, prescriber Alice 601 executes the following:

number

[0110] Alice only needs one public key to be certified by a CA; all other keys can be linked in a provable way.

number

[0111] A digital signature that can be linked to the public key of a public key certificate is referred to as a linkable signature below. A signer uses a linkable signature to sign a message using two digital signatures, the public key of which is linked to the public key of the public key certificate, as described above. Ai and

number

number

[0112] Preferably, the SIGHASH flag should not be the same in any two OP_CHECKSIGs, as doing so could compromise the signer's private key in implementations that do not properly implement a secure random key generator.

[0113] In the following, the term linkable signature refers to one of the above forms: Attestation Transaction

number

[0114] An example prescription transaction that references a registration transaction is shown below. [Table 6]

[0115] Prescriber Alice uses a pair of linkable signatures to create a TxID prescription-1 Alice signs her valid

number

[0116] TxID prescription-1 The first output of the TxID is used by the patient when redeeming the prescription or by the prescriber when expiring it. prescription-1 To check whether a prescription has been signed by an authorized prescriber, a party (e.g., a pharmacist) does the following:

number

[0117] An example of a lock script usable by patient signature or prescriber linkable signature could be: <m=1><P _A > <P POTA ><n=2> OP_CHECKMULTISIGVERIFY where: <P POTA > is the one-time address of the patient 602, and P A belongs to the prescriber.

[0118] An example of a lock script usable by patient signature or prescriber linkable signature could be:

number

[0119] Prescription transactions may be generated with the signature of an additional trusted authority (i.e., a second, different token issuer). Prescription transactions are signed by the prescriber 601 and a trusted entity called "Medical DB" 802. In this example, the prescriber's signature does not need to be known to the pharmacist to verify. Thus, the pharmacist may rely on the Medical_DB signature to check that the prescription is signed by an authorized prescriber. This scenario is what is described in Figures 9 and 10. In general, the Medical_DB signature may be used to prove either: The transaction is prescribed by an authorized prescriber Transaction prescriptions are redeemable Patients are authenticated · The patient's medical history is checked

[0120] The prescription transaction may then be given by: [Table 7]

[0121] The token issuer's identification address allows the pharmacist 1001 to identify the token issuer and / or trusted authority, allowing the pharmacist 1001 to check that the prescription is authorized by that entity. Either the prescriber 601 or the patient can use the TxID prescription ||0 can be used by the prescriber 601 to cancel or renew a prescription and by the patient 602 to redeem a prescription.

[0122] When a patient 602 redeems their prescription transaction from a pharmacist, a redemption transaction is created. One of its inputs is the TxID. prescription ||0 is a usable output. The redemption transaction can be signed by the patient 602 and the pharmacist. Note that the patient 602 does not sign using a linkable signature to protect privacy. The following transaction can be generated: [Table 8]

[0123] If prescription transactions assume on-chain CA, pharmacists would need to check the following:

number

[0124] Occasionally, a prescription transaction may need to be cancelled or updated. Assuming the token data is embedded in an unusable transaction output (using OP_RETURN), the transaction TxID prescription The prescription is cancelled or renewed by using the available output of ||0.

[0125] Prescription cancellation is done via the prescription transaction TxID prescription This is achieved when ||0 is used and the flag "Cancel" in the output of the usage transaction confirms the cancellation of the prescription.

[0126] Changes to prescriptions can be made through TxID prescription This can be achieved by using ||0 and having the flag "update" in the output of the usage transaction. The new prescription is inserted in the output. For a transaction with the flag "update" to be accepted for redemption, it must be signed by the prescriber's linkable signature and co-signed by the Medical_DB's linkable signature.

[0127] If the token data is embedded in a usable output, cancellation and renewal is accomplished by using that output.

[0128] It is also possible to have one transaction for both prescribing and dispensing the medication. In this scenario, the prescriber 601 can sign the transaction using the SIGHASH flag Single|AnyoneCanPay. The transaction is then passed off-chain to the patient 602. When dispensing the medication, the pharmacist's wallet address is added to the output. The pharmacist would also have to sign the transaction and therefore add their own input. This transaction may require interaction between the pharmacist 1001 and the prescriber 601. It is also possible to have the patient 602 nominate a pharmacy of their choice and send the prescription directly to that pharmacy. The advantage of such a configuration is that it allows the pharmacy enough time to order and prepare the prescription, allowing for more timely management of consumables.

[0129] This use case leverages blockchain to provide a system for recording prescriptions that is auditable, available, and immutable. Anyone can easily access the blockchain data and download the blockchain. Prescriptions can be easily identified within the blockchain through the use of prescription flags. Combining these two points means that anyone can monitor prescription metadata from a single set of records without unnecessary barriers or permissions. While auditing the use of "classified drugs" is a specific motivation for the need to have auditability, the protocol enables auditability of all prescriptions.

[0130] The example described has the following characteristics: · The names and quantities of medications and their prescription dates can be audited without the patient's identity. · Drugs (classified or not) may be irrefutably linked to the identity of the prescriber and / or the healthcare institution that authenticated and authorized the prescriber 601. Combining off-chain PII patient data allows authorized individuals to have controlled access to check a patient's prescription history. These checks can be crucial in emergency situations and when a patient's medical condition does not allow for certain types of prescriptions. · Prescribers may be checked against the medicines they have issued and whether they are authorised to issue such medicines. Patients can be identified and authenticated in a privacy-sensitive manner by prescribers and pharmacists and any other authorized actors, without risking their personal data becoming accessible in the public domain. The Medical_DB 802, which co-signs the prescription with the prescriber, ensures that 1) the prescriber 601 is qualified and authorized, 2) the patient is properly identified and authenticated, and 3) the patient's prescription history is checked against the signed transaction prescription. The Medical_DB 802 has its own checks audited. The transparency of the system ensures that any incorrect configuration or incorrect behavior can be detected and traced to its source. · Policies can be automated and systems configured to track, flag and alert in case of violations. Policies can be automated to be enforced during prescription issuance, such as: - Blacklisting pregnant patients and patients with some medical conditions from certain medications unless an additional signature from an authorized prescriber 601 is required; and / or - Blacklisting drugs so that they cannot be administered above a certain amount or in combination with other drugs.

[0131] The described system can be used to provide tracking of medication from the supplier who supplies the medication to the pharmacy all the way to the patient 602. This proposes the following: When a new drug arrives, the drug supplier (the token issuer) and the pharmacist (the second token issuer) will send a transaction TxID supply (Token transaction) will be issued. TxID supply is signed by both using linkable signatures. Transaction TxID supply would contain data about the code and quantity of the medication the pharmacist will receive (token data). The transaction-usable output is available for pharmacist signature using a redemption transaction. Drug inventory maintained by pharmacists is managed by TxID redeem Quantity in TxID supply The amount of the drug in the formula (I) can be calculated at any time by subtracting the amount of the drug in the formula (I).

[0132] Exemplary Use Case 2 - Parking Assume that a parking lot manager, Charlie (token issuer 601), wants to issue parking tokens to customers. The first step is for Charlie to create a list of parking tokens using one of the two methods described above, i.e., to include the tokens in the usable output or the unusable output. Without loss of generality, the following example uses a token transaction with the token in the usable output. [Table 9] If Alice wants to park her car for 10 hours, Charlie creates the following transaction (the redemption transaction): [Table 10] Here, TXID3||0 represents one of the parking tokens generated by Charlie, and h A is the hash value of Alice's vehicle registration number. Charlie can add a timestamp to make the hash value unique each time.

[0133] When Alice presents this transaction at the exit, the gatekeeper will do the following: 1. Check that the out-points referenced in the input are unused, 2. Check the validity of the signature on the input, 3. Check whether the hash value of the vehicle registration number matches the output hash value. 4. Create a new version (the transaction with the highest sequence number) to charge Alice for her actual parking time.

[0134] Note that if Alice parked for more than 10 hours, TXID4 would be valid and accepted by the miner before she left the parking lot. This would cause check 1 to fail. If Alice parked for less than 10 hours, TXID4 would be invalid due to its lock time. Therefore, the outpoint referenced in the input is still unused (check 1 passes). If both checks 2 and 3 are successful, the gatekeeper creates the final transaction. [Table 11]

[0135] The above transaction assumes that Alice pays for parking through some other means. However, payment can be integrated into a parking token system by adding another input from Alice to TXID4. [Table 12] [Table 13]

[0136] In the first of the two transactions, Alice pays for 10 hours of parking. Later, if the parking is less than 10 hours, Alice can still update the transaction and only pay for the actual parking time. Also, by having Alice sign TXID4, we can use it to prove that Alice did indeed enter the parking lot at the said time, which is <h A >, i.e., Alice or Charlie can use it if they want to dispute the time they entered the parking lot.

[0137] conclusion It will be understood that the above embodiments have been described by way of example only. More generally, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0138] Statement 1. A computer-implemented method for issuing one or more single-use tokens for use by one or more respective token redeemers using a blockchain transaction, the method being executed by a token issuer and comprising: generating a token transaction, the token transaction including one or more token outputs, each token output including token data representing a respective single-use token, each single-use token being associated with a respective usable output of the token transaction, and the validity of each single-use token being conditioned on the presence of each usable output in a set of unspent transaction outputs of the blockchain; and one or more inputs, at least a first of the inputs including a signature linked to a first public key of the token issuer; and submitting the token transaction to one or more nodes of a blockchain network for recording on the blockchain.

[0139] Statement 2. The method of claim 1, wherein a token transaction includes multiple token outputs.

[0140] Statement 3. The method of statement 1 or statement 2, wherein each single-use token is associated with a respective usable output in that each token output is a respective usable transaction output.

[0141] Statement 4. The method of statement 3, wherein one or more of the one or more token outputs is an m-of-n multi-signature output, and wherein each m-of-n multi-signature output is configured such that, in order to be unlocked by a token redemption transaction input, the token redemption transaction input must include at least m signatures linked to each of the n public keys.

[0142] Statement 5. The method of statement 4, wherein each m-of-n multisignature output requires that the input of the token redemption transaction include a signature linked to the token redeemer's second public key and / or a signature linked to the token issuer's public key.

[0143] The second public key may be the same as the first public key, or alternatively, the first public key and the second public key may be different public keys.

[0144] Statement 6. The method of any of statements 3 to 5, wherein one or more of the one or more token outputs includes a respective if-else statement defining two or more alternative conditions, each alternative condition being configured such that the token transaction input must satisfy the defined condition in order to be unlocked by the token redemption transaction input.

[0145] Statement 7. The method according to statement 1, wherein the token transaction includes a single token output, and the token output is an unusable output.

[0146] Statement 8. The method of statement 7, wherein the usable output associated with the single-use token of the single token output is an m-of-n multi-signature output configured such that, in order to be unlocked by input of a token redemption transaction, the input of the token redemption transaction must include a signature linked to the token redeemer's public key and / or a signature linked to a second public key of the token issuer.

[0147] Statement 9. The method of any of the preceding statements, wherein each spendable output associated with the respective token output single-use token is a pay-to-public-key-hash output configured such that, in order to be unlocked by input in a token redemption transaction, the input in the token redemption transaction must include the token redeemer's public key and / or the token issuer's second public key.

[0148] Statement 10. The method of statement 9, wherein each usable output associated with a single-use token of the respective token output includes a hash of token data representing that single-use token.

[0149] Statement 11. The method of any of the preceding statements, wherein the token transaction includes multiple inputs, and at least one of the multiple inputs includes a signature linked to a public key of a second, different token issuer.

[0150] Statement 12. The method of any of the preceding statements, wherein the token transaction includes a plurality of inputs, at least one of the plurality of inputs includes a signature linked to a third public key of the token issuer, and the first public key and the third public key are linked to each other.

[0151] Statement 13. The method of any of the preceding statements, wherein a first input of the token transaction inputs includes a signature linked to a third public key of the token issuer, and the first public key and the third public key are linked to each other.

[0152] Statement 14. The method of statement 12 or statement 13, wherein the first public key and the third public key are linked to a second public key of the token issuer.

[0153] Statement 15. The method of statement 14, wherein the second public key is a certified public key.

[0154] Statement 16. The method of any of the preceding statements, wherein the token transaction includes multiple inputs, and at least one of the multiple token inputs includes a signature linked to the token redeemer's public key.

[0155] Statement 17. The method of any of the preceding statements, including receiving a token transaction template from a second, different token issuer or token redeemer, and generating a token transaction based on the token transaction template.

[0156] Statement 18. The method of any of the preceding statements, wherein the token data representing each single-use token includes a reference to an attestation transaction that includes the token issuer's first public key or a attested public key linked to the issuer's first public key.

[0157] Statement 19. The method of any of the preceding statements, comprising generating a token update transaction, where the token update transaction includes an input that references one of the one or more token outputs of the token transaction, and where the token update transaction includes a token update output, where the token update output includes token data representing updated versions of each single-use token for the referenced input of the token transaction, and transmitting the token update transaction to one or more nodes of the blockchain network for recording on the blockchain.

[0158] Statement 20. The method of any of the preceding statements, comprising generating a token cancellation transaction, where the token cancellation transaction includes an input that references one of the one or more token outputs of the token transaction, and where the token cancellation transaction includes a token cancellation output, where the token cancellation output includes token data representing a canceled version of each single-use token of the referenced input of the token transaction, and transmitting the token cancellation transaction to one or more nodes of the blockchain network for recording on the blockchain.

[0159] Statement 21. The method of any of the preceding statements, including sending a transaction identifier for the token transaction to the token redeemer, and / or sending a respective transaction output identifier for one or more respective usable outputs associated with the respective single-use token to the token redeemer.

[0160] Statement 22. A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, the memory storing code configured to be executed on the processing device, the code, when on the processing device, being configured to perform a method according to any of statements 1 to 21.

[0161] Statement 23. A computer program embodied on a computer-readable storage and configured to perform the method of any of statements 1 to 21 when executed on a computing device according to statement 22.

[0162] Statement 24. A token transaction for a blockchain, comprising: one or more token outputs, each token output including token data representing a respective single-use token, each single-use token being associated with a respective usable output of the token transaction, and the validity of each single-use token being conditioned on the respective usable output being present in a set of unspent transaction outputs of the blockchain; and one or more inputs, at least a first of the inputs including a signature linked to a first public key of a token issuer.

[0163] Statement 25. A computer-readable storage medium storing the token transaction of statement 24.

[0164] According to another aspect of the teachings disclosed herein, a method may be provided that includes the actions of a token issuer and a token redeemer.

[0165] According to another aspect of the teachings disclosed herein, there may be provided a system comprising computer devices of a token issuer and a token redeemer.

[0166] Other variations may be apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is not limited by the disclosed embodiments, but only by the appended claims.< / h1>

Claims

1. 1. A computer-implemented method for issuing one or more single-use tokens for use by one or more respective token redeemers using blockchain transactions, the method being performed by a token issuer and comprising: generating a token transaction, the token transaction comprising: one or more token outputs, each token output including token data representing a respective single-use token, each single-use token associated with a respective usable output of the token transaction, and the validity of each single-use token being conditioned on the respective usable output being present in a set of unspent transaction outputs of the blockchain; one or more inputs, at least a first of the inputs including a signature generated based on a private key corresponding to a first public key of the token issuer, at least one input including a signature generated based on a private key corresponding to a third public key of the token issuer, the first public key and the third public key being linked to each other, the first public key and the third public key being linked to a second public key of the token issuer, and the second public key being a certified public key; and transmitting the token transaction to one or more nodes in a blockchain network for recording in the blockchain; A method comprising:

2. The method of claim 1 , wherein the token transaction includes multiple token outputs.

3. 3. The method of claim 1 or 2, wherein each single-use token is associated with a respective usable output in that each token output is the respective usable transaction output.

4. 4. The method of claim 3, wherein one or more of the one or more token outputs is an m-of-n multi-signature output, and each m-of-n multi-signature output is configured such that, in order to be unlocked by a token redemption transaction input, the input must include at least m signatures generated based on private keys corresponding to each of n public keys.

5. 5. The method of claim 4, wherein each m-of-n multi-signature output requires that the inputs of the token redemption transaction include a signature generated based on a private key corresponding to a second public key of a token redeemer and / or a signature generated based on a private key corresponding to the first or third public key of the token issuer.

6. 6. The method of any one of claims 3 to 5, wherein one or more of the one or more token outputs include respective if-else statements defining two or more alternative conditions, each alternative condition configured such that the input of the token transaction must satisfy the defined condition in order to be unlocked by the input of a token redemption transaction.

7. The method of claim 1 , wherein the token transaction includes a single token output, the token output being an unusable output.

8. 8. The method of claim 7, wherein the usable output associated with the single-use token of the single token output is an m-of-n multi-signature output configured such that, in order to be unlocked by input of a token redemption transaction, the input of the token redemption transaction must include a signature generated based on a private key corresponding to a second public key of a token redeemer and / or a signature generated based on a private key corresponding to a second public key of the token issuer.

9. 9. The method of claim 1, wherein the respective usable output associated with the single-use token of the respective token output is a pay-to-public-key-hash output configured such that, in order to be unlocked by input of a token redemption transaction, the input of the token redemption transaction must include a second public key of a token redeemer and / or the second public key of the token issuer.

10. 10. The method of claim 9, wherein the respective usable output associated with the single-use token of the respective token output includes a hash of the token data representing that single-use token.

11. 11. The method of claim 1, wherein the token transaction includes multiple inputs, and at least one of the multiple inputs includes a signature generated based on a private key that corresponds to a public key of a second, different token issuer.

12. The method of claim 1 , wherein the token transaction includes multiple inputs.

13. 13. The method of claim 1, wherein the first one of the inputs for the token transaction includes a signature generated based on a private key of the token issuer that corresponds to the third public key.

14. 14. The method of claim 1, wherein the token transaction includes a plurality of inputs, and at least one of the plurality of token inputs includes a signature generated based on a private key corresponding to a second public key of a token redeemer.

15. receiving a token transaction template from a second, different token issuer or the token redeemer; generating the token transaction based on the token transaction template; 15. The method of any one of claims 1 to 14, comprising:

16. 16. The method of claim 1, wherein the token data representing each single-use token includes a reference to an attestation transaction that includes the first public key of the token issuer or the attested public key linked to the first public key of the token issuer.

17. generating a token update transaction, the token update transaction including an input that references one of the one or more token outputs of the token transaction, the token update transaction including a token update output, the token update output including token data representing an updated version of the respective single-use token for the referenced input of the token transaction; sending the token update transaction to one or more nodes of a blockchain network for recording in the blockchain; 17. The method of any one of claims 1 to 16, comprising:

18. generating a token cancellation transaction, the token cancellation transaction including an input that references one of the one or more token outputs of the token transaction, the token cancellation transaction including a token cancellation output, the token cancellation output including token data representing a canceled version of the respective single-use token of the referenced input of the token transaction; sending the token cancellation transaction to one or more nodes of a blockchain network for recording in the blockchain; 18. The method of any one of claims 1 to 17, comprising:

19. sending a transaction identifier of the token transaction to the token redeemer; and / or sending to the token redeemer a respective transaction output identifier for one or more respective usable outputs associated with each single-use token; 19. The method of any one of claims 1 to 18, comprising:

20. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 20. A computing device comprising: a memory storing code configured to be executed on the processing unit, the code configured, when on the processing unit, to perform the method of any one of claims 1 to 19.

21. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 19 when executed on a computing device according to claim 20.

Images