Blockchain-based token protocol

Abstract

A method for implementing a token protocol using a blockchain is provided, the method comprising: obtaining a token melt transaction comprising: a first input signed by a first party, the first input referencing an output of a first token transfer transaction, the output being locked to a first public key of the first party and comprising a first token amount; and a first output locked to a melting public key of a delegating entity and comprising the first token amount; and creating a token minting transaction comprising: an input signed by the delegating entity using a signature corresponding to the minting public key and an output locking digital assets in an amount sufficient to fund the token transfer transaction, the output being locked to a second public key of the first party and comprising the first token amount.

Description

[Technical Field]

[0001] The present disclosure relates to methods for implementing token protocols, and in particular to methods relating to melting and minting tokens as part of the token protocol. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points backward to a preceding transaction in a sequence that may span one or more blocks, leading back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves multiple nodes each competing to perform a solution to a cryptographic puzzle based on a "proof of work," i.e., a representation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through the mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains may 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 or indexes to data within transactions. There is no pre-specified limit on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly more complex data can be incorporated. For example, this may be used to store electronic documents, or audio or video data, within the blockchain.

[0004] Nodes in the blockchain network (often called "miners") perform a distributed transaction registration and validation process, described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a block template, from which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes in the network, thus allowing each node to record a new block on the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to execute the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) then remains registered and indexed as such at each of the nodes in the blockchain network as an immutable public record.

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is typically awarded a new transaction, called a "coinbase transaction," that distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes, which act as agents of the network and are encouraged to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node behavior. The mere publication of block headers allows participants to guarantee the continued validity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying an amount of a digital asset derivable from an evolving series of transactions. A consumable output is sometimes called a UTXO (“unspent transaction output”). The output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that specifies the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, a pair of transactions is considered, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies an amount of a digital asset and comprises a locking script that specifies one or more conditions for unlocking the output. The second target transaction comprises at least one input comprising a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in the new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred by reference to absolute account balances rather than by referencing backwards the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention [Problem to be solved by the invention]

[0009] In modern society, cash still plays an important role for economic activity in some regions of the world and in various markets. Cash provides instant, peer-to-peer transactions without a central authority and guarantees privacy for all parties involved. Moreover, cash can be used for transactions even when one or more parties do not hold or have access to a bank account. However, as technology evolves, traditional paper-based cash is becoming increasingly obsolete, and new forms of cash are needed. As an alternative to traditional cash, blockchain-based cash, called digital cash, is emerging, which can be exchanged digitally, for example, using a smartphone. Digital cash has all the properties of traditional cash and is minted and backed by a trusted central authority, such as a central bank. However, instead of being printed on paper, digital cash is issued on a blockchain. Blockchain-based digital cash can be exchanged peer-to-peer either online or offline, i.e., with or without an internet connection.

[0010] However, blockchain-based digital cash (and other token protocols) face several challenges, including how to validate recent token transactions so that they can be accepted in token transactions. [Means for solving the problem]

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for executing a token protocol using a blockchain, wherein a token transfer transaction requires inputs signed by respective parties and one or more respective outputs, each output locking a respective amount of digital assets and comprising a respective locking script locked to a respective public key of the respective party and comprising a respective token amount, the method being executed by a delegating entity to obtain a token melt transaction, the token melt transaction comprising: i) a first input signed by a first party, the first input referencing a respective output of the first token transfer transaction, the respective output locked to a first public key of the first party; creating a token minting transaction, the token minting transaction comprising: i) a first input, the first input comprising a first token amount, and ii) a first output, the first input comprising a first token amount, and ii) a first output, the first output being locked to a minting public key of the delegating entity and comprising the first token amount; creating a token minting transaction, the token minting transaction comprising: i) the respective input signed by the delegating entity using a signature corresponding to the minting public key, and ii) respective outputs locking digital assets in a respective amount sufficient to fund one or more respective token transfer transactions, the respective outputs being locked to a second public key of the first party and comprising the first token amount; and submitting the token minting transaction to one or more nodes of the blockchain network.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for executing a token protocol using a blockchain, wherein each token transfer transaction requires inputs signed by respective parties and one or more respective outputs, each output comprising a respective locking script locking a respective amount of digital assets and comprising a respective token amount locked to a respective public key of the respective party, the method being executed by a first party and comprising initiating a melt and mint protocol, the melt and mint protocol creating a token melt transaction, the token melt transaction comprising: i) a first input signed by the first party, the first input locked to the first party's first public key and comprising the first token amount; and ii) a first input referencing a respective output of the first token transfer transaction, and ii) a first output locked to a melting public key of the delegating entity and comprising the first token amount; submitting the token melt transaction to one or more nodes of the blockchain network; and obtaining a token minting transaction, the token minting transaction comprising: i) the respective inputs signed by the delegating entity using a signature corresponding to the minting public key; and ii) respective outputs locking respective amounts of digital assets sufficient to fund the one or more respective token transfer transactions, each output locked to a second public key of the first party and comprising the first token amount.

[0013] Embodiments of the present disclosure relate to a "melt and mint protocol" that reduces the number of checks that must be performed to validate a token. Tokens can be "melted" (i.e., removed from the token protocol so that they cannot be used) and minted (i.e., reissued or reintroduced into the token protocol) at several checkpoints. This means that tokens do not need to be traced back to issuance in order to be validated. A delegating entity is responsible for minting tokens in response to melt requests. Because such delegating entity interaction can cause bottlenecks, for example, during peak hours, the protocol aims to minimize the role of the delegating entity in token transactions without completely eliminating the delegating entity. The delegating entity only needs to check the validity of the token between two transactions (which have a checkpoint role), called melt and mint transactions.

[0014] To assist in understanding 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: [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded in a blockchain. [Figure 3] FIG. 1 is a sequence diagram of an exemplary token issuance protocol. [Figure 4] FIG. 1 is a schematic block diagram of an exemplary system for implementing the Melt and Mint protocol. [Figure 5] FIG. 1 illustrates an exemplary chain of transactions from a mint transaction to a melt transaction. [Figure 6]FIG. 1 is a schematic block diagram of an exemplary system for transferring and validating token transactions. [Figure 7] FIG. 1 illustrates an example payment tree of transactions, starting with a mint transaction and ending with the current token transaction. [Figure 8] FIG. 1 is a schematic block diagram of an exemplary system for submitting token transactions to a blockchain. [Figure 9] FIG. 1 illustrates an exemplary sequence of a token transaction including a double consumption of a token. [Figure 10] FIG. 1 illustrates an exemplary consumption graph for a chain of transactions. DETAILED DESCRIPTION OF THE INVENTION

[0016] 1. Example System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, i.e., typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0017] Each blockchain node 104 comprises a peer computing device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise one or more memory units employing 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.

[0018] A blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be a pruned version of the data, so long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or methodology. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing a quantity of a digital asset, one example of a property being the user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backward to the output of a preceding transaction 152, thereby linking the transactions.

[0019] Each block 151 also has a block pointer 155 that points back to previously created blocks 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer back to an earlier transaction to define an order for the series of transactions (note that the series of transactions 152 is allowed to diverge). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0020] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term herein is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 accepts as valid and that the node 104 is obligated to not accept any other transactions attempting to consume the same output.

[0021] For a given current transaction 152j, the (or each) input comprises a pointer to the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consuming can be described as consuming an output, i.e., allocating it to one or more outputs in another transaction onward. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and even sent to the network 106, but the previous transaction 152i must exist and be valid for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in a logical sequence linked by a pointer, not necessarily to the time of creation or submission in a temporal sequence, and therefore does not necessarily preclude a transaction 152i, 152j from being created or submitted out of order (see the discussion below regarding orphan transactions). A predecessor transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0022] The input of the current transaction 152j also comprises an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to the new user or entity 103b as specified in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a for providing change). In some cases, a transaction may also have multiple inputs to aggregate the amount from multiple outputs of one or more preceding transactions and redistribute it among one or more outputs of the current transaction.

[0023] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or organization, wishes to establish a new transaction 152j (either manually or through an automated process employed by the party), the establishing party sends the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately sends this transaction to one or more blockchain nodes 104 of the network 106 (which today is typically a server or data center, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may, in some instances, send the transaction directly to one or more of the blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain 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 such output-based transaction protocols, this may comprise checking that a cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition specified in the output of a prior transaction 152i that the new transaction consumes (or "allocates"); this condition typically comprises at least checking that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the prior transaction 152i to which the input of the new transaction is linked. The condition may be specified at least in part by a script included in the output of the prior transaction 152i. Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these.Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and so forward the new transaction 152j onto one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0024] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has yet been validly redeemed by the input of another transaction 152j forward according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated (unless flagged as invalid and propagated to warn) or recorded in the blockchain 150. This protects against double spend, whereby a transactor attempts to allocate the same transaction output more than once. On the other hand, the account-based model protects against double spend by maintaining an account balance. Again, because there is a defined order of transactions, the account balance always has a defined single state.

[0025] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions, in a process supported by "proof of work," commonly referred to as mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that, when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition might be that the output of the hash has some predetermined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. A property of a hash function is that the hash has an output that is unpredictable given its input. Therefore, this search can only be performed by brute force, and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0026] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the solution satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and therefore propagates it up to threshold agreement of other nodes enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155, which points back in the chain to the previously created block 151n-1, is also assigned to the new block 151n. The significant amount of effort required to create the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction; otherwise, known as double spending. Once created, blocks 151 cannot be modified since they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0027] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool 154 of unissued transactions at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unissued transactions is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool 154 of unissued transactions, and so on. The protocol also exists to resolve any "forks" that may occur, which are cases where two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In essence, whichever prong of the fork grows the longest becomes the final blockchain 150. Note that when the same transaction appears in both forks, this should not affect users or agents of the network.

[0028] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate additional accepted amounts of digital assets in a new special type of transaction that distributes a specified additional quantity of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is typically called a “coinbase transaction,” but may also be called an “initiation transaction” or “generation transaction.” It typically forms the first transaction of a new block 151n. The proof of work signals the node’s intent to construct the new block to comply with protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is explained below.

[0029] Due to the resources involved in transaction validation and publication, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may also take the form of a user terminal or a group of user terminals networked together.

[0030] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective one or more roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer or in a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0031] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as accumulating entities that accumulate copies of the blockchain 150 (e.g., obtain copies of the blockchain from blockchain nodes 104).

[0032] Some or all of the parties 103 may be connected as part of a different network, for example, a network overlaid on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required roles of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. 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 is understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, 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, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0033] The computing equipment 102 of each party 103 comprises a respective processing unit comprising 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 further 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 employing 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 comprising a respective instance of at least one client application 105 configured to execute on the processing unit. It will be understood that any actions attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises 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 comprise one or more other networked resources, such as cloud computing resources, that are accessed via the user terminal.

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

[0035] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of these is to allow each party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which then propagate throughout the network of blockchain nodes 104 and thereby be included in the blockchain 150. The other is to report back to each party the amount of digital assets that they currently own. In an output-based system, this second functionality comprises reconciling the amounts specified in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0036] Note: While various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting; instead, any client functionality described herein may instead be implemented within a set of two or more separate applications that interface via, for example, an API, or one plugged into the other. More generally, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to client application 105, it will be appreciated that this is not limiting.

[0037] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, to truly inspect the transactions of other parties 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 function on each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As noted above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is used with a given node protocol to jointly implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0038] When a given party 103, for example, Alice, wants to send a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction according to the relevant transaction protocol (using a wallet function in her client application 105). Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets some conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

[0039] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this then means that the transaction 152j will soon be propagated throughout the entire network 106, assuming the transaction 152j is valid.

[0040] Once accepted into the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of their respective pool of 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools 154 of transactions, but whoever gets there first defines the set of transactions that will be included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 that includes the new transaction 152j, the new transaction 152j immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to earlier transactions, so that the order of transactions is also immutably recorded.

[0041] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have competing views of which instance is "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it shall accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0042] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred by reference to an absolute account balance, rather than by referencing backward the UTXO of a transaction that precedes it in the sequence of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction account (also called its "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with a transaction. This data field may point backward to a previous transaction, for example, if the data field contains a previous transaction ID.

[0043] 2. UTXO-based model FIG. 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 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0044] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and output fields 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 node 104.

[0045] For example, Alice 103a wishes to create transaction 152j to transfer a certain amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. 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 point backward to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0046] The preceding transaction Tx0 may already be valid and included in a block 151 of the blockchain 150 at the time Alice creates her new transaction Tx1, or at least by the time she sends 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 ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or Tx0 may even be sent 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 the sequence, as defined by transaction pointers specified in the transactions (e.g., which transactions point backward to which other transactions). They may be equivalently substituted for “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” or the like. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (a descendant transaction or “child”) that points to a preceding transaction (an ancestor transaction or “parent”) is not valid until and unless the parent transaction is valid. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or may be buffered for some time to wait for its parent.

[0047] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that specifies the condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script typically specifies an unlocking condition that includes the condition that the unlocking script in the input of the subsequent transaction comprise the cryptographic signature of the party to which the preceding transaction is locked.

[0048] A locking script (also 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) used by blockchain networks. A locking script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlocking script appears in the transaction's output. An unlocking script (also called scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the transaction's input 202.

[0049] So, 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 Locking script [Checksig P A]. [Checksig P A ] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's transaction ID, TxID0. Tx1's input 202 comprises a pointer that points backward into Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises 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 The data (or "message") that needs to be signed by Alice to provide a valid signature may be specified by a locking script, or by a node protocol, or a combination of these.

[0050] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to check whether the unlocking script satisfies a condition specified in the locking script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" denotes a location within the data on the stack, and "[...]" is a function provided by the locking script (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts will create a locking script containing Alice's public key P as included in the locking script in the output of Tx0. A , which authenticates that the unlocking script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (so there is no need to include a separate element in the clear specifying the signed portion of the data, as it is already inherently present).

[0051] The details of authentication via public-private cryptography are well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature on the message, thus allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or the like can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0052] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of pending transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 propagates throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes unspent transaction outputs 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 is already spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks 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.

[0053] 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 for invalidity in most transaction models. Therefore, such a transaction is not propagated or included in block 151.

[0054] 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 fraction of the amount specified in the UTXO as spent while another fraction is consumed. However, the amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount specified in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount specified in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to make a payment to another party.

[0055] In practice, Alice also typically needs to include a fee for any Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and, therefore, while technically valid, may not be propagated or included in the blockchain 150 (the node protocol does not force a blockchain node 104 to accept a transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, 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 may be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of transaction 152's UTXOs 203 itself.

[0056] Alice and Bob's digital assets consist of the 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 across the blockchain 150. There is no single number stored somewhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked to each party and that have not yet been spent in another transaction onward. The wallet function can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0057] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, can accumulate data within the transaction, thereby creating a non-consumable output of the transaction that can immutably record the data in the blockchain 150. For example, the data may comprise a document that is desired to be accumulated in the blockchain.

[0058] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portion of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0059] A locking script may be referred to as a "scriptPubKey," typically referring to the fact that the locking script comprises the public key of the party to which each transaction is locked. An unlocking script may be referred to as a "scriptSig," typically referring to the fact that the unlocking script 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 comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0060] 3. Side Channels As shown in FIG. 1 , the client application on each of Alice's and Bob's computing devices 102 a and 102 b, respectively, may include additional communication functionality. This additional functionality allows Alice 103 a to establish (at the instigation of either the parties or a third party) a separate side channel 107 with Bob 103 b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as “off-chain” communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being registered on the blockchain network 106 or on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner may be referred to as sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0061] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, a side channel 107 as referenced elsewhere herein may comprise any one or more links, via one or more networking technologies or communications media, for exchanging data “off-chain,” i.e., separately from the blockchain 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 107. Thus, it should be noted that when it is said that Alice and Bob exchange several pieces of information or data, or the like, over the side channel 107, this does not necessarily imply that all these pieces of data must be sent over exactly the same links, or even the same type of network.

[0062] 4. Tokens A token may be defined as a unit of value issued by a (trusted) entity. Tokens may be used to represent and manage real-world assets. As used herein, tokens are distinct from the blockchain's underlying digital assets, e.g., satoshis / bitcoin. Tokens are issued and transferred using blockchain transactions, but the value of the transaction (e.g., in satoshis) need not replicate the value of the embedded token (e.g., a transaction moving several satoshis can transfer any amount of tokens). Tokens may be managed and activated using trusted third-party services and / or the blockchain's native scripting language. In the latter case, smart contracts that may be used to govern tokens may be viewed as stateful smart contracts, where the transaction state includes the amount of tokens available.

[0063] Tokens can be permissioned or permissionless. Permissioned tokens are controlled by a central authority (e.g., a government or trusted organization) or a group of pre-approved entities that are responsible for issuing, managing, freezing, and other operations. In contrast, permissionless tokens are a class of tokens whose exchange cannot be controlled by anyone. Anyone can issue permissionless tokens, and their circulation cannot be controlled.

[0064] 4.1 Token Validity Bitcoin is an example of a UTXO-based blockchain 150. Thus, each time one or more tokens are transferred from one public key to another, a new transaction output (UTXO) is created. With each new transaction, the validity of the native token (e.g., Bitcoin) is verified by the blockchain network 106. However, when new tokens are minted and embedded into a UTXO, they are not automatically validated by the nodes 104 and therefore require additional verification.

[0065] A token scheme on top of blockchain 150 is an identified set of digital assets that are issued at a specific time and follow a specific set of rules for transfer. Tokens are issued by a trusted party called an issuer. It can be assumed that all parties can identify newly minted tokens from the issuer. A token may be considered currently valid if it has followed all rules from issuance. How to know that a token is currently valid is the main challenge facing token schemes. It is often useful to think of token validity checking as being performed in two steps. 1. Was the token ever valid? This is usually done when the user receives the token. 2. Is the token currently valid? This is typically done when the user spends the token.

[0066] From a user journey perspective, the first step is important once the user is about to receive the token - they want to know if the token is authentic. The second part is important once the user owns the token - they want to know it hasn't been double-spent.

[0067] Consider the parallel with the blockchain itself: the native blockchain token is the UTXO. In this case, point 1 corresponds to a Merkle proof of a previous transaction, and point 2 corresponds to the acceptance of the transaction containing the UTXO in the blockchain network 106.

[0068] Another approach to token management is to use accounts. In this case, rather than embedding tokens within UTXOs, the amount held by each user is stored in a contract that tracks all balances and provides token transfer functionality. This approach is the preferred solution for blockchains that allow for maintaining state, for example, Ethereum ERC20 tokens. However, it is rarely used in UTXO-based blockchains because the state would need to be maintained within UTXOs, centralizing the protocol and generating large transactions.

[0069] 4.2 Traceback Some token protocols involve so-called "traceback" methods to check whether a token is valid. Traceback is a technique used by token protocols that requires users to set up a token rule set and ensure that the token follows the rule set. The challenge is that the only way to check that a token was ever valid is to trace the token back to issuance. Often, such protocols suggest that the wallet software may be responsible for tracking the token's validity. However, it is unclear here what happens if a person deceives the wallet software. Another challenge is that such protocols are prone to burning tokens if they create token transactions that do not follow the token rules.

[0070] 4.3 Dust Limit The dust limit, dust, prevents transactions of very little value from being issued on the blockchain 150. The reason for having a dust limit is that under standard fee policies, very little value outputs would require a fee to be consumed that is higher than the value of the output itself, making these transactions uneconomical to consume (the cost of the unlocking script would be greater than the UTXO value).

[0071] Another reason for setting a dust limit is to prevent dusting attacks, which are used by fraudsters to de-anonymize transactions and reveal the person or organization behind a wallet. The fraudster can "dust" a large number of addresses, wait for the wallet to consume these dust outputs, and then perform analysis to reveal which of these addresses belong to the same wallet.

[0072] 5. Melt and Mint Protocol FIG. 4 illustrates an exemplary system 400 for implementing the Melt and Mint protocol as part of a token protocol, e.g., a token protocol having some or all of the features described in Section 4 and / or Section 8. For example, the token protocol may be a protocol for implementing a digital cash system. The system 400 includes one or more delegating entities 302, a transferor (or payer) 401, a transferee (or payee) 402, and one or more nodes 104 of a blockchain network 106. The transferor and transferee may also be referred to as a first party and a second party, respectively. The transferor 401 may be configured to perform some or all of the actions attributed to Alice 103a and / or Bob 103b with reference to FIGS. 1 and 2. Similarly, the transferee 402 may be configured as described above. The transferee may be configured to perform some or all of the actions attributed to Alice 103a and / or Bob 103b with reference to FIGS. 1 and 2.

[0073] As described below, the delegating entity 302 is responsible for minting (i.e., issuing, or rather, re-issuing) new tokens in response to a melt request from a token user, e.g., a transferor 401. A transferor is a token user who intends to transfer a certain amount of tokens to a transferee 402, where the transferee is the recipient of that amount of tokens. Here, transferring tokens means transferring ownership of the tokens to the transferee 402.

[0074] A blockchain transaction that transfers ownership of a token is referred to herein as a token transfer transaction, or simply a transfer transaction. According to the token protocol described herein, a transfer transaction may be required to satisfy one or more of the following conditions to be considered a valid transfer transaction: First, the transfer transaction must include at least one input signed by the transferor 401. A transfer transaction may include two or more inputs signed by the transferor 401. Each input in a transfer transaction must reference the output of a previous transfer transaction or the output of a mint transaction. Mint transactions are described below.

[0075] The second of the conditions is that the transfer transaction must include one or more outputs, where each output is locked to a respective public key of a token user, e.g., the transferee 402. One or more outputs may be locked to the transferor 401. Each output includes a respective token amount that specifies the amount of tokens to be transferred (assigned) to the owner of the respective public key to which the output is locked. The token amount may be included as a string or in another manner. In some examples, the token amount is included in a portion of the output that is not executed during script execution (specifically, the output locking script). For example, the token amount may follow an OP_RETURN opcode or equivalent.

[0076] The third of the conditions is that the sum of the token amounts across the outputs of the transfer transaction must equal the sum of the token amounts included in the outputs of the previous transfer or mint transactions referenced by the inputs of the current transfer transaction. As an example, if the current transfer transaction references a single output containing 50 tokens, the sum of the tokens included in the outputs of the current transfer transaction must also be 50 tokens; for example, the current transfer transaction may include five outputs each containing 10 tokens.

[0077] Each output of a transfer transaction locks a respective amount of the underlying digital asset on the blockchain 150. The underlying asset is different from a token. While the token amount is added as data in the locking script of the transaction output, the underlying digital asset is the basis of the transaction and is required by the blockchain protocol. Taking Bitcoin as an example, the underlying asset is a unit called a satoshi. The fourth condition is that each token output (a token output is an output that includes a token amount) of a transfer transaction must lock a sufficient amount of the underlying asset. The sufficient amount may be a predetermined amount. The sufficient amount may be a fixed amount or a minimum amount. In some examples, the sufficient amount may be a percentage (i.e., a fraction) of the amount of the underlying asset locked by the output referenced by the previous transfer transaction input.

[0078] A transfer transaction may be subject to one or more additional conditions to be considered valid. These additional conditions are described below.

[0079] In response to determining that the transferor 401 cannot generate a valid transfer transaction due to an insufficient amount of digital assets to create two or more token transactions, the transferor 401 may initiate a melt and mint protocol with the delegating entity 302. Initiating the melt and mint protocol may comprise sending a request to the delegating entity 302. The transferor 401 has an insufficient amount of digital assets if the outputs of the current token transaction together lock less than the sufficient amount required to be locked by the respective outputs of two or more transfer transactions. The transferor has at least an amount of digital assets sufficient to create a melt transaction (i.e., one token transaction), but less than the amount required to create two token transactions (e.g., two transfer transactions).

[0080] The transferor 401 generates a melt transaction. The melt transaction comprises an input that references the output of a most recent transfer transaction, where the output is locked to a first public key associated with the transferor 401. The input is signed with a signature generated using a first private key corresponding to the first public key. The referenced output comprises a first token amount, e.g., 40 tokens. The melt transaction comprises an output locked to a melting public key associated with the delegating entity 302. The output of the melt transaction comprises the first token amount, e.g., 40 tokens. That is, the melt transaction melts the transferor's existing tokens. Here, melting tokens effectively means transferring the tokens to the delegating entity 302 so that they are no longer available for use by token users. The transferor 401 submits the melt transaction to the blockchain network 106 directly or via an intermediate party, e.g., the delegating entity 302.

[0081] The delegating entity 302 obtains the melt transaction. For example, the delegating entity 302 may obtain the melt transaction from the blockchain 150 and / or the delegating entity may receive the melt transaction from the transferor 401.

[0082] The delegating entity 302 generates a mint transaction. The mint transaction comprises an input signed with a signature generated using a private key corresponding to a minting public key associated with the delegating entity 302. The minting public key may be the same or different from the melting public key. In some examples, the mint transaction input references the output of the melt transaction. In other examples, to preserve privacy, the mint transaction input does not reference the output of the melt transaction. The mint transaction comprises an output locked to a second public key associated with the transferor 401. The second public key may be the same or different from the delegating entity 302. Using a different public key preserves privacy. The delegating entity 302 may receive the second public key from the transferor 401. The output of the mint transaction comprises a first token amount, i.e., the mint transaction mints the same number of tokens melted by the melt transaction. The output of the mint transaction locks an amount of digital assets sufficient to fund (i.e., create) one or more further transfer transactions. The amount of digital assets locked may be predetermined. The amount may be fixed, i.e., each mint transaction locks the same amount of digital assets. The delegating entity 302 submits the mint transaction to the blockchain network 106 directly or through an intermediate party, e.g., the transferor 401.

[0083] The transferor 401 obtains a mint transaction. For example, the transferor 401 may obtain the mint transaction from the blockchain 150 and / or the transferor 401 may receive the mint transaction from the delegating entity 302. Having obtained the mint transaction, the transferor 401 may generate a next transfer transaction that transfers some or all of the first token amount to the transferee 402. That is, the transferor 401 may generate a token transaction that references the output of the mint transaction and comprises inputs signed with a signature generated using a private key corresponding to the second public key. The token transaction includes one or more outputs, each comprising a respective token amount. The sum of the token amounts equals the first token amount. At least one of the outputs comprises the second token amount and is locked to a public key associated with the transferee 402. Furthermore, each output locks a sufficient amount of digital assets. The transferor 401 submits a token transaction to the blockchain network 106 directly or via an intermediate party, for example, a delegating entity 302 or a transferee 402.

[0084] Figure 5 shows an exemplary melt and mint protocol. From top to bottom, the top transaction shows an exemplary mint transaction signed with a minting signature and having two token outputs: one locked to Alice's public key and one locked to Frank's public key. 50 tokens are issued to both Alice and Frank. The next transaction then shows Alice transferring 40 tokens to Bob and 10 tokens back to herself. In several later transactions, Dave transfers 40 tokens to Frank. Frank is then unable to generate a token transaction due to insufficient funds, so he initiates the melt and mint protocol by generating a melt transaction. The melt transaction is signed by Frank and locks the 40 tokens to the melting public key. The delegating entity 302 then mints the 40 tokens using the minting transaction and locks them to Frank's public key.

[0085] In some examples, in response to receiving a request from the transferor 401, the delegating entity 302 may send a digital certificate to the transferor 401, where the digital certificate comprises the melting public key. The certificate certifies that the melting public key is controlled by the delegating entity 302. The transferor 401 may use the certificate to generate a melt transaction, for example, by extracting the melting public key. In some examples, the transferor 401 may verify that the digital certificate is a valid certificate and may proceed with the melt and mint protocol only if the certificate is valid. Validating the certificate may comprise verifying that the certificate has not been revoked. How to verify that a digital certificate is valid is well known to those skilled in the art. Proceeding with the melt and mint protocol may comprise generating the melt transaction.

[0086] Before proceeding with the melt and mint protocols, the delegating entity 302 may verify the identity of the transferor. Proceeding with the melt and mint protocols may comprise generating a mint transaction. In some examples, to verify the identity of the transferor 401, the transferor 401 may send a digital certificate to the delegating entity, where the certificate comprises an identity public key associated with the transferor 401. In some examples, the certificate may be publicly accessible. The certificate certifies that the identity public key is controlled by the transferor 401. The transferor 401 may sign the certificate with a signature generated using a private key corresponding to the ephemeral public key. The delegating entity 302 may verify that the identity public key is based on (i.e., linked to or derivable from) the first public key and the ephemeral key.

[0087] In some examples, the delegating entity 302 may verify that the melt transaction generated by the transferor 401 is part of a chain of token transactions that traces back to one or more mint transactions before proceeding with the melt and mint protocol.

[0088] In some examples, the delegating entity 302 may proceed with the melt and mint protocols only when it determines that the melt transaction is a valid token transaction. Validating token transactions is described below in Section 6. The delegating entity 302 may use some or all of the techniques described in Section 6 to validate mint transactions.

[0089] 6. Token Transfer and Activation FIG. 6 illustrates an exemplary system 600 for implementing a transfer (e.g., payment) protocol and a validation protocol as part of a token protocol, e.g., a token protocol having some or all of the features described in Section 4 and / or Section 8. For example, the token protocol may be a protocol for implementing a digital cash system. The transfer and validation protocols may be used together with or separately from the melt and mint protocols described in Section 5. For example, the delegating entity 302 may use the validation protocol to validate a melt transaction. The transferor 401 may use the transfer protocol to transfer tokens from a mint transaction. The transferee 402 may use the validation protocol to validate a transfer transaction generated by the transferor 401, as described.

[0090] When transferring tokens as part of the token protocol, the transferor 401 may generate a "candidate" transfer transaction. A candidate transfer transaction is a transfer transaction that, if validated by the transferee 402, will be submitted to the blockchain network 106. In some instances, there may be no difference between the candidate transfer transaction received by the transferee 402 and the corresponding transfer transaction sent to the blockchain network 106, in which case the term "candidate" is simply used as a label for the transaction sent by the transferor 401.

[0091] A candidate transfer transaction has at least one input signed by the transferor 401 and referencing the output of a previous token transaction (either a previous transfer transaction or a mint transaction). A candidate transfer transaction may have two or more inputs, each referencing a respective token output. A transaction is a mint transaction if it is signed with a minting signature generated by the delegating entity 302. Each referenced output contains a respective token amount. A candidate transfer transaction has at least one output locked to the transferee's 402 public key. A candidate transfer transaction may have two or more outputs. Each output contains a respective token amount. The sum of the token amounts contained in the outputs of the candidate transfer transaction must equal the sum of the token amounts contained in the outputs referenced by the candidate transfer transaction's inputs. Each output locks a respective amount of the underlying digital asset.

[0092] The transferor 401 sends candidate transfer transactions to the transferee 402. The transferor 401 also sends one or more lists, one for each input of the candidate transfer transaction, to the transferee 402. Each list contains transactions tracing back from the candidate transfer transaction, via the transactions referenced by each input, to one or more respective mint transactions. For example, referring to FIG. 7 and taking TxAliceBob as an example of a candidate transfer transaction, one list would contain each transaction in the chain of transactions tracing back from TxAliceBob via input IN_1 to mint transactions TxMint1 and TxMint2. Another list would contain each transaction in the chain of transactions tracing back from TxAliceBob via input IN_2 to mint transactions TxMint3 and TxMint4. Note that the lists may be sent together as one overall list. The list may contain references to the transactions, e.g., their respective transaction identifiers, or the list may contain the transactions themselves.

[0093] As noted, each mint transaction is signed with a respective minting signature corresponding to a respective minting public key. The transferor 401 may also send to the transferee 402 a respective certificate certifying each minting public key as associated with a respective delegating entity.

[0094] The transferee 402 uses the validation protocol to validate the candidate transfer transaction. The delegating entity 302 may also use the validation protocol to validate the Melt transaction described in the section above.

[0095] The transferee 402 receives the candidate transfer transaction and a list of transactions that trace back from the candidate transfer transaction to the mint transaction. The transferee 402 uses the list to verify that each input of the candidate transfer transaction traces back to its respective mint transaction. The transferee 402 also verifies that the sum of the token amounts contained in the outputs of the candidate transfer transaction equals the sum of the token amounts contained in the outputs of the transactions referenced by the candidate transfer transaction's inputs. Both verifications must pass for the candidate transfer transaction to be considered valid.

[0096] Upon determining that the candidate transfer transaction is a valid token transaction, the transferee 402 may either directly or indirectly submit the candidate transfer transaction (now referred to as a transfer transaction) to the blockchain network 106.

[0097] As described below, a candidate transfer transaction may undergo one or more additional checks to be considered valid. For example, the transferee 402 may verify that each mint transaction is signed with a signature corresponding to a respective minting public key controlled by the respective delegation entity 302. The transferee 402 may use a certificate received from the transferor to perform this verification. The transferee 402 may additionally check that the certificate is valid.

[0098] In some examples, the transferee may verify that the candidate transfer transaction has a transaction fee sufficient to ensure that the candidate transfer transaction is not sent to the secondary memory pool of the blockchain node 104. A transaction is collected in the secondary memory pool (or secondary transaction pool) if it does not include a minimum transaction fee. This can prevent the transaction from being recorded on the blockchain 150. The transaction fee is typically not explicitly specified in the transaction. Instead, the transaction fee is the difference between the sum of the amounts of digital assets locked by each output of the transaction and the sum of the amounts of digital assets locked by each output referenced by each input of the transaction. The transferee 401 may verify that the transaction fee is at least a predetermined minimum value.

[0099] In some examples, a candidate transfer transaction may be considered valid only if each transaction in the chain of transactions tracing back to the mint transaction is also valid. Thus, the transferee 402 may verify that each transaction in the chain of transactions is also valid.

[0100] As described, the delegating entity 302 may use the validation protocol to validate a melt transaction. The delegating entity 302 performs steps equivalent to those described as being performed by the transferee 402, where the candidate transfer transaction is instead a melt transaction.

[0101] 7. Submitting a transaction to the blockchain 8 illustrates an example system 800 for facilitating the submission of a transaction to a blockchain network 106. The system 800 includes a first party, a second party, a third party, and one or more nodes 104 of the blockchain network 106. The first party and the second party may be the transferor 401 and the transferee 402, respectively, as described with reference to FIGS. 4-7. The third party may be a trusted third party 801.

[0102] The first party 401 may operate a device that is unable (i.e., not configured) to connect to (i.e., send data to) the blockchain network 106. In that case, the first party 401 may be unable to submit transactions to the blockchain network 106. As an example, the first party may be unable to connect to the blockchain network 106 via the Internet. The first party 401 may be unable to connect to the blockchain network 106 at all (e.g., the device does not have the capability), or the first party 401 may be temporarily unable to connect to the network 106 (e.g., due to a lack of coverage in the region in which the first party 401 is located). The transaction may involve any purpose or protocol, for example, the token protocol described herein. This prevents the first party 401 from utilizing the blockchain. The third party 801 operates a device that is able (i.e., configured) to connect to (i.e., send data to) the blockchain network 106.

[0103] The first party 401 operates a device capable of sending data to the third party 801. Similarly, the third party 801 operates a device capable of receiving data from the first party. The first party 401 sends a first message to the third party 801, the message comprising data for generating a transaction. The third party 801 receives the first message and generates the first transaction based on the message. In some examples, the message comprises at least some of the transaction. In other examples, the first message comprises the complete transaction. The message is sent over a first connection. The first connection may be a wireless connection. That is, the first party 401 may send the message over a wireless connection. For example, the message may be sent over a mobile (cellular) connection such as General Packet Radio Service (GPRS). The message may be sent via Short Message Service (SMS) or Multimedia Messaging Service (MMS). Other types of wireless connections that may be used include a Bluetooth connection, a Near Field Communication (NFC) connection, and low frequency radio (Tetra).

[0104] The third party 801 sends a first transaction to the blockchain network 106 over a second connection based on the first message. The second connection is different from the first connection. The second connection may be a packet-switched network 101, typically a wide-area internetwork such as the Internet. The third party 801 may transform the first message into the first transaction. That is, the third party 801 may generate the first transaction using data included in the first message (e.g., one or more signatures, one or more public keys, one or more token amounts, etc.).

[0105] In some examples, the third party 801 may receive a second message from the blockchain network 106. The second message is received over a second connection, e.g., the Internet. The third party 801 then sends the second message (or a message based on the second message) to the first party and / or the second party over the first connection. In these examples, the second party 402 also cannot send or receive data from the blockchain network 106. As an example, the second message may comprise a confirmation (e.g., a Merkle proof) indicating that the first transaction has been recorded on the blockchain.

[0106] As an example, the system 800 may be used to facilitate the transmission of a token transaction to the blockchain network 106. The transferor 401 may send a message including a candidate transfer transaction, or data for generating a candidate transfer transaction, to the transferee 402. Candidate transfer transactions are described above with reference to FIGS. 6 and 7. The transferor 401 and the transferee 402 may communicate over any suitable connection common to both parties, e.g., a first connection. The transferee 402 then sends the transfer transaction (i.e., the candidate transfer transaction validated by the transferee 402) to a trusted third party 801 over the first connection, e.g., via GPRS. Rather than sending the transfer transaction itself, the transferee 402 may send a message including data for generating the transfer transaction. The trusted third party 801 submits the transfer transaction to the blockchain network 106 over a second connection, e.g., via the Internet. The trusted third party 801 may obtain confirmation from the blockchain network 106 over the second connection and send a response to the transferee 402 over the first connection. The transferee may forward the response to the transferor 401.

[0107] 8. Digital Cash This section briefly describes an exemplary digital cash protocol. Digital cash may be implemented using a blockchain-based token protocol. Embodiments of the present disclosure may be implemented in the context of this exemplary digital cash protocol.

[0108] 8.1 Blockchain Network The blockchain network 106 ensures that digital cash payments cannot be double-spent and allows for transparency of token distribution because the blockchain 150 is public. Furthermore, through its consensus mechanism, the blockchain network 106 ensures proper execution of digital cash payments.

[0109] 8.2 Issuer A token issuer institution (e.g., a central bank) issues digital cash in the form of tokens. Each issuance is published to the blockchain network 106. The issuer establishes a network connection with the blockchain network 106 and a delegating entity, described below.

[0110] 8.3 Delegating Entities Delegating entities may be highly regulated, trusted third-party entities (e.g., commercial banks) that each have associated wallets. The role of a delegating entity is to: Receive newly issued tokens and store them using the delegating entity's wallet; Communicating with users (e.g., distributing issued tokens to users); and sending the transaction to the blockchain network 106.

[0111] The entity establishes a network connection with the blockchain network 106, issuers, and user wallets. Some issuers may be delegating entities.

[0112] 8.4 Users A user (e.g., a citizen wishing to exchange digital cash payments) has an associated user wallet that receives tokens from delegating entities and also makes digital cash payments to other user wallets. The wallet may be connected to the blockchain network 106 according to a P2P payment protocol and also establishes connections with other user wallets and with one or more delegating entities. A user may not be an issuer or a delegating entity. Alice 103a and / or Bob 103b may be users of the token protocol.

[0113] 8.5 Digital Certificates and PKI This section describes a public key infrastructure (PKI) that may be used by token issuers, delegating entities, and users. It is envisioned that several trusted third parties (TTPs) and certificate authorities (CAs) may be implemented, for example, by central banks and government organizations.

[0114] 8.5.1 PKI Each user has a secret key, sk id and the associated public key pk id You can generate the public key pk id is certified by a CA (see Section 8.5.2) once the user proves their identity. This proof of identity can have two Know-Your-Client (KYC) tiers: 1. Any user verifies their identity using their national ID, or 2. The user has verified their phone number and / or email address.

[0115] A second option may limit how many transactions a user can perform and the value of each digital cash payment a user can make. Proof-of-attestation (i.e., digital certificates generated in Section 8.5.2) may be added on-chain.

[0116] sk id and pk id is called the identity key. In addition, users may also store a personal master key generated by their wallet application. From this master key, users can derive keys, for example, using the BIP32 strengthened key derivation protocol. These keys are called ephemeral keys, and they should preferably be used only once.

[0117] The token issuer and delegating entity PKI may comprise one or more master keys that are securely stored offline (i.e., cold storage). These master keys are used to generate online Level 1 keys (L1) that have limited time validity (e.g., monthly validity) that are maintained online and used for attestation. From these keys, the token issuer and delegating entity can derive Level 2 keys (L2) that are used to sign transactions. The L2 keys have even stricter time validity (e.g., daily). Like the user identity keys, the L1 and L2 keys are certified by a CA.

[0118] The PKI structure just described can be deployed with a randomly generated L2 key, which can then be verified using a signature from a valid L1 key. Here, public keys are linked to output points, and it is possible to check whether a public key is valid by simply checking whether the corresponding output point is in the UTXO set. In other words, a public key is valid until the associated UTXO remains in the memory pool UTXO set, and it can be invalidated by consuming the associated UTXO.

[0119] 8.5.2 Digital Certificates Each digital certificate may contain some or all of the following information: · A hash of private information such as a phone number, email address, or national ID (for users) or registration number (for token issuers or delegated entities). Attestation tier, which refers to what type of KYC the user has performed. The delegation entity's tier will always refer to the strongest KYC process. · The identity public key in the case of a user, or the L1 or L2 public key in the case of a delegating entity. ·Date of certificate issuance. · Certificate expiration date. A digital signature over the above items, created using the CA's private key.

[0120] The time validity of the L1 and L2 keys is managed through digital certificate issuance and expiration dates.

[0121] The CA publishes a public key that is associated with the private key used for signing. The public key may be available on a website or web repository. As explained in the section above, new keys can be issued and old keys can be revoked. When a key is revoked, the digital certificate must be reissued.

[0122] Note that digital certificates can be renewed before their expiration date; this does not invalidate the previous certificates unless they have expired.

[0123] Upon receiving a digital certificate, an entity or user establishes its validity by checking: 1. The current date is between the issue date and the expiration date, 2. And the digital signature is valid.

[0124] 8.6 Token Issuance and Structure Tokens can be issued only by the token issuer and are not pegged to an underlying digital asset. Each token has a value expressed in terms of the token issuer's currency, as well as additional information proving its issuance.

[0125] Upon issuance, the token is embedded in a transaction and addressed to one of the delegating entities. The delegating entity can be selected randomly, or the delegating entity requests the latest token for distribution. If the user is entitled to receive the token (e.g., if the user is requesting a digital cash transfer), the delegating entity is responsible for sending the token to the user's wallet.

[0126] Table 1 shows an example of a token issuance transaction.

[0127] [Table 1]

[0128] Where the <token specification> can be:

[0129] [Table 2]

[0130] 8.7 Delegated Entity Wallets Each delegating entity has an associated wallet that tracks the tokens that it can distribute to other users. The capabilities supported by that wallet may include one or more of the following: Track the total amount of tokens available for distribution. For each token, record the output location (the UTXO index and transaction ID in which the token is placed). Set up a key wallet and create a private / public key pair as explained above. Record the CA's public key. · Communicate with other delegated entities. Receive issued tokens from the token issuer. · Distribute issued tokens to users.

[0131] How a delegating entity can receive payments from a token issuer is detailed below. Figure 3 shows an example protocol for issuing tokens. 1. The delegating entity 302 and the token issuer 301 exchange their digital certificates off-chain. 2. The delegation entity 302 and token issuer 301 check the validity of the received digital certificate. If the certificate is valid, the remaining steps are executed. If not, the protocol stops. 3. The token issuer 301 issues a transaction TxID with a payment addressed to the public key contained in the certificate of the delegating entity 302. issue Create a. 4. The transaction is sent by the token issuer 301 to the blockchain network 106. 5. The issuer 301 receives confirmation from the blockchain network 106 that the transaction is valid. 6. Issuer 301 sends a copy of the transaction off-chain to delegating entity 302. Delegating entity 302 now knows the transaction details and the amount of issued digital cash that delegating entity 302 can distribute to user wallets.

[0132] Because the token issuer 301 and delegating entities 302 have associated digital certificates and transactions are issued on-chain, the protocol for issuing tokens is secure when the majority of delegating entities 302 behave well.

[0133] 8.8 User Wallet A user wallet may have one or more of the following capabilities: Track the total amount of tokens available to users. For each token, record the output location (UTXO index and transaction ID where the token is placed). Set up a key wallet and create a private / public key pair as explained above. ·Memorize the CA's public key and update it frequently. Communicate with delegation entities and other user wallets (e.g., via TCP / IP). User wallets may also have the ability to connect to the blockchain network 106. Send and receive digital cash.

[0134] To distribute issued tokens to user wallets, the delegation entity 302 receives the TxID issue A user may create the following transactions shown in Table 2, which consume the output of

[0135] [Table 3]

[0136] Transaction TxID user The second input funds the transaction for any required transaction fees.

[0137] A user can receive a token from the delegation entity 302 in their wallet if: · A user receives a transfer (e.g., a Digital Cash withdrawal) from their bank (acting as a delegating entity) to their Digital Cash wallet. The user executes the Melt and Mint protocols described below.

[0138] Penalty kick user To calculate , a user wallet may choose one of the following options: Any penalty kick user pk as follows id and pk e It is calculated from Penalty kick user = pk id + pk e where pk id is the identity public key, and pk e Recall that is the ephemeral public key of the user wallet. Alternatively, the PK can be derived by the wallet using a key derivation mechanism such as BIP32. user is derived.

[0139] In the latter case, the user wallet will e =PK user -PK id By defining PK user and pk id You can create a link between the ephemeral key pk and e may be used to link user digital certificates and identity public keys to transaction payment and on-chain public keys.

[0140] Penalty kick user may be used only once, and pk id The correlation is based on the on-chain public key PK user is the identity public key pk id To achieve this, we must ensure that sufficient randomness is provided to the ephemeral public key pk e =PK user -PK id It is sufficient that

[0141] 8.9 Melt and Mint Protocol This section details how users can send and receive digital cash payments using a Layer 2 protocol with reduced involvement of the delegation entity 302 compared to some protocols. The protocol aims to strike a balance between addressing the traceback problem and decentralization. Any of the examples described in this section may be used with the Melt and Mint protocols described in Section 5 above.

[0142] A user-to-user digital cash payment is called a peer-to-peer (P2P) transaction, peer-to-peer payment, or peer-to-peer transfer. Unless otherwise specified, the term X Token refers to a single UTXO containing a digital cash payment of value X.

[0143] Melt and Mint are protocols that reduce the number of checks that must be performed to validate a token - tokens do not have to be traced back to issuance, thereby solving the trace-back-to-issuance problem. The role of the delegating entity 302 in P2P transactions is minimized without completely removing it, as it may cause a bottleneck during peak hours. In this solution, the delegating entity 302 must check the validity of the token between two transactions (which have a checkpoint role), called melt and mint transactions. The two transactions are defined as follows: A Melt transaction (representing a Melt checkpoint) in which a token is sent from a user (e.g., a transferor 401) to a delegation entity 302. A minting transaction (representing a minting checkpoint) in which the token is returned from the delegation entity 302 to the same user.

[0144] After the mint transaction, on average there will be T chained transactions before the melt transaction.

[0145] Each user wallet may store units of the underlying digital asset, e.g., satoshis. These satoshis are placed in the value of each UTXO containing the token. They are received from the delegating entity 302, for example, when the user wallet requests a transfer from a bank to their digital cash wallet, or through the Melt and Mint protocols. Receiving satoshis from the delegating entity 302 acts as a top-up system for users, where the role of the satoshis is to cover the transaction fees of P2P payments without involving the delegating entity 302 in the payment process. The structure of a P2P payment is shown below in Table 3.

[0146] [Table 4]

[0147] The above transaction requires transferor Alice 401 to spend Z=X+Y tokens contained in a UTXO worth s satoshis. In addition, Alice sends half of Alice's satoshis to transferee Bob 402 and receives back the remaining satoshis minus the transaction fee. Bob 402 therefore has s / 2 satoshis in Bob's 402 wallet, thereby spending Bob's 402's X tokens. The choice to send s / 2 to Bob 402 is arbitrary; other choices may be made by the wallet.

[0148] Whenever a transferor 401 user wallet wishes to spend tokens placed in a UTXO for which it has insufficient satoshis to create at least two more transactions, then the melt and mint protocol at threshold T performs the following steps: 1. The user wallet 401 requests a Melt checkpoint from the delegation entity 302. 2. The delegation entity 302 wallet sends their digital certificate to the user wallet 401. 3. The user wallet 401 checks the validity of the certificate received in step 2. 4. The user wallet 401 consumes the UTXO and sends the satoshis and tokens to the public key of the delegation entity 302 contained in the certificate. The created transaction is a Melt transaction. 5. User wallet 401 receives the public key PK' into which user wallet 401 wishes to receive tokens. user is derived. 6. The delegation entity 302 verifies the identity of the user wallet, i.e. The user wallet 401 sends the digital certificate to the delegation entity 302. b. The delegation entity 302 checks the digital certificate. c. User Wallet 401 is pk e =PK user -pk id The signature is sent via those digital certificates created using the PK user is the public key included in the input of the Melt transaction. d. The delegation entity 302 checks the signature received in step 6c. e. The delegation entity 302 uses the pk id PK id =PK user -pk e Check that the following is satisfied. 7. The delegation entity 302 checks that all tokens are valid by tracing them back to their respective mint transactions using the validation protocol described below. 8. The delegating entity 302 creates a mint transaction with a payment to the address provided by the user 401. The payment is included in a UTXO that comprises: a. The same amount of tokens sent by the user wallet 401 to the delegating entity through a Melt transaction. b. Enough associated satoshi values ​​to cover, on average, T transactions, until step 1 needs to be performed again.

[0149] If the delegating entity 302 did not allocate enough satoshis in step 8b, the user 401 can choose to execute the melt and mint protocol early. Alternatively, the user 401 cannot make any more token payments if they do not have enough satoshis remaining in their wallet. This situation can occur if an excessive number of UTXOs are created in the chain of transactions. How many satoshis the delegating entity 302 must allocate is further estimated below.

[0150] Figure 5 shows the chain of transactions between mint transaction TxID0 and melt transaction.

[0151] In summary, Melt and Mint offer the following characteristics: The delegation entity 302 waits for requests to melt and mint tokens. The delegating entity 302 pays only the mint transaction fee to cover a chain of T transactions. · When running Melt and Mint, payment traceability from the public perspective is reduced, as the Melt public key is always different from the Mint public key.

[0152] 8.10 P2P Payments and Token Activation To perform a P2P payment, this section assumes that both parties involved are online. The payer (transferor) 401 is the user, and the payee (transferee) 402 is either the user or the delegating entity 302. Any of the examples described in this section may be used in conjunction with the transfer and activation protocols described in Section 6 above.

[0153] To receive the token, the payer 401 and payee 402 follow the following protocol: 1. Payer 401 sends the following to Payee 402: a. Transactions involving Token Payments; and b. A list of transactions linking the payment to the minting transaction. 2. The payer 401 sends the payee 402 the digital certificate of the delegating entity 302 that created the minting transaction to which the payer's transaction will be chained. 3. The payee 402 verifies the validity of the transaction and whether the token rules were correctly enforced. This is done by tracing back the token payment to the minting transaction, which is identified using the delegating entity's digital certificate. 4. The recipient 402 submits the transaction to the blockchain.

[0154] Step 3 will be illustrated in more detail using the specific example shown in Figure 7. Figure 7 shows a diagram of transactions received by Bob 402. The arrows represent the consumption of outputs. The transaction labeled TxMint is a minting transaction created by the delegating entity 302. The right-most transaction is a payment from Alice 401 to Bob 402 and the change back to Alice 401. The diagram shows the payment tree that Bob 402 needs to validate in order to accept payments from Alice 401, where the leaves are represented by minting transactions. In general, the set of transactions received by Bob 402 may form a directed acyclic graph (DAG). How Bob 402 can validate the tokens received from Alice 401 is detailed next. The transactions Bob 402 receives from Alice 401 have the following format, shown in Table 4:

[0155] [Table 5]

[0156] Suppose Alice 401 unlocks Z tokens and z satoshis. To validate this transaction, Bob 402 checks that: 1. Z (number of tokens unlocked) = X (tokens received) + Y (change tokens sent back to Alice). 2. Check that the token specification has the required format. 3. z=x+y+fee (transaction fee paid to miners) to ensure that the transaction is not added to the secondary memory pool of the blockchain node 104, which may prevent the transaction from being recorded on the blockchain 150.

[0157] Additionally, Bob 402 receives the TxID AliceBobIn some cases, Bob 402 may need to validate a transaction that includes an output point consumed by Alice 401 in . To do this, Bob 402 performs the same check to ensure that the received token is valid, as follows:

[0158] Minting Transaction TxID mint For each transaction up to (see Table 5), Bob 402 performs the following steps: 1. Check whether the sum of the input tokens is the same as the sum of the output tokens. 2. Check whether there are sufficient transaction fees being paid. 3. Check whether the token specification is followed.

[0159] Essentially, Bob 402 performs a DAG traversal algorithm (e.g., Depth First Search (DFS) and Breadth First Search (BFS)) to check the validity of the payment received from Alice 401.

[0160] [Table 6]

[0161] Recall that for each minting transaction, Bob 402 also receives a digital certificate to identify delegating entity 302. To check whether the above transaction is a minting transaction, Bob 402 shall check the following: 1. The PK in the corresponding digital certificate mint Whether it is placed. 2. The delegating entity's digital certificate is valid. It may happen that the certificate has expired. In this case, the user wallet 401 can either accept the payment at their own risk or ask the delegating entity 302 to perform the validation and check the payment validity using on-chain data.

[0162] When Bob makes a digital cash payment, he may also send the following to the next recipient so that the recipient can validate the payment: 1. Bob sends the transaction payment to the recipient. 2. For each input, Bob sends the complete payment DAG of transactions (or trees). 3. Bob sends Alice all of the digital certificates of the delegating entities involved in each minting transaction that is part of her payment DAG. 4. Bob can now delete each digital certificate sent to him that corresponds to a delegating entity.

[0163] Finally, all of the above steps may be similarly performed by the delegation entity 302 upon receiving the token from the user wallet 401. This occurs through a Melt transaction as described above. The activation protocol is the same.

[0164] The token validation process can be quite large in terms of communication (step 1) and validation (step 3) because the number of transactions grows exponentially in the number of outputs. Therefore, if there are too many transactions (e.g., more than 10) to send to the payee, the payer can first request an early execution of the melt and mint, and then send the payment to the payee at a later time. This reduces the communication to only two transactions (the mint transaction, and the transaction containing the token payment).

[0165] 8.11 Online and Offline Payments User wallets are typically deployed on phones that have the computing power to enable ECDSA signatures and perform SHA256 hashes. However, depending on location, token payments may be made online or offline, and the checks that the payee 402 must perform depend on their connectivity to the blockchain network 106. Devices may be differentiated by their connectivity level. Level 1 - Internet connection Level 2 - Mobile coverage (e.g., GPRS) Level 3 - Low frequency (e.g., 300Mhz) wireless coverage Level 4 - Offline

[0166] Users 401, 402 have connectivity level 3 if they own a device that can convert between radio and GPRS signals (e.g., issued by an authority). The conversion between radio and Internet signals can be achieved through the radio access network or using Tetra. The advantage is low implementation costs because the radio infrastructure already exists and has a larger area than the Internet. The only cost incurred is the device that can convert between radio and Internet signals.

[0167] Levels 2 and 3 involve trusted third parties 801 that receive messages from users 401, 402, transform them into transactions, and forward them to the blockchain 150. These trusted parties 801 may be mobile or wireless companies, or companies building the underlying network infrastructure. The trusted third party 801 does not necessarily have to be one of the delegating entities 302; that is optional.

[0168] Users 401, 402 with Level 4 connectivity can receive payments through short-range wireless protocols (e.g., Bluetooth) but do not have a means to connect to the blockchain 150 (either directly or through a trusted third party 801).

[0169] Depending on the connectivity level, different checks or communication protocols need to be established between the payer 401, payee 402, and the blockchain network 106. The payer 401 can have any connectivity level as long as it can communicate with the payee 402. Each payment protocol is detailed for each connectivity level of the payee 402, assuming that melting and reminting does not have to be performed. Any of the examples described in this section may be used in conjunction with the payment protocols described in Section 7 above.

[0170] 8.11.1 Level 1 Protocol This is the protocol detailed in Section 8.10 and is repeated here for completeness. 1. Payer 401 sends the following to Payee 402: a. Transactions involving Token Payments; and b. A list of transactions linking the payment to the minting transaction. 2. The payer 401 sends the payee 402 the digital certificate of the delegating entity 302 that created the minting transaction to which the payer's transaction will be chained. 3. The payee 402 verifies the validity of the transaction and whether the token rules were correctly enforced. This is done by tracing back the token payment to the minting transaction, which is identified using the delegating entity's digital certificate. 4. The recipient 402 submits the transaction to the blockchain.

[0171] 8.11.2 Level 2 and 3 Protocols 1. Payer 401 and Payee 402 perform steps 1-3 of the Level 1 protocol. 2. The payee 402 submits the transaction to a trusted third party 801 via SMS or wirelessly. 3. The trusted third party 801 submits the transaction to the blockchain 150 and receives a response from the blockchain network 106. 4. The trusted third party 801 sends the response to the recipient 402 via SMS or wirelessly. 5. If the response from the blockchain network 106 is that the transaction is valid, the payee 402 accepts the payment.

[0172] 8.11.3 Level 4 Protocol 1. Payer 401 and Payee 402 perform steps 1-3 of the Level 1 protocol. 2. The payer 401 sends the Merkle proof of the minting transaction and the corresponding block header to the payee 402. 3. Recipient 402 performs the checks detailed in Section 8.13. 4. The recipient 402 accepts the payment when all checks are performed successfully. In case of double spending, once the recipient 402 gains better connectivity (level 3 or higher), the protocol in Section 6.2 is executed.

[0173] Even though the payee 402 performs checks on offline payments, they still rely on a degree of trust between the payer 401 and the payee 402. To mitigate the risk of offline transactions, the payee 402 may choose to accept only a limited payment value from the payer 401. The risk of such payments may be modeled by the payee's wallet using a mathematical utility function.

[0174] 8.12 Melt and Mint Integration If the payee 402 is always online (level 1 connectivity), they may choose to perform a melt and mint before every token payment. By invoking a melt and mint, there is no traceable link between the transactions from a public perspective, and the delegating entity 302 has no knowledge of the token payment being made until melt and mint is invoked by the payee 402.

[0175] Levels 2, 3, and 4 connectivity, on the other hand, always rely on melting and minting, with a threshold of T transactions. When a user exhausts their available fare or reaches the threshold T, a reminting must be performed. In the case of levels 2 and 3, users can request a reminting. However, in the case of level 4, users must increase their connectivity level to at least 3. This can be achieved as follows: Any user finds a geographic area that has wireless or mobile coverage; or One of the delegation entities may have a mobile station that can be requested by the user or that periodically passes through the user's domain, with at least Level 3 connectivity, to which the user connects for reminting purposes.

[0176] 8.13 Offline Payment Verification To enable offline payments between users, it is necessary to ensure that transaction validity can be verified and that users can be held accountable if they are cheating. Referring to the example transaction chain in Figure 5, assume that Alice 401 wants to make a payment to Bob 402 and that Bob 402 is offline. Bob 402 receives the following from Alice 401 (e.g., via Bluetooth): Transaction TxID1 from Alice 401, Minting transaction TxID0, A Merkle inclusion proof of transaction TxID0 in the block, and The block header in which TxID0 is included.

[0177] Bob 402 is required to store a list of public keys from several CAs. Since it is expected that only a few institutions will have the CA role, this does not have significant storage overhead. The verification protocol is split into a payment verification part and an identity verification part.

[0178] 8.13.1 Payment Validation 1. Bob 402 computes the Merkle root using the Merkle proof for TxID0. 2. If the Merkle root is not the same as the one in the block header, Charlie103c rejects the payment. 3. Otherwise, Bob 402 checks whether the difficulty target in the block header in which the transaction is stored is above a predetermined threshold. If not, it stops the protocol because Alice 401 may have sent an invalid Merkle proof and header. 4. Bob 402 gets Alice's signature and public key pk=pk id +pk e Check whether TxID1 consumes Alice's UTXO in TxID0 using pk id is the identity public key, and pk e Recall that is an ephemeral public key that can only be used once. 5. Bob 402 checks the token is valid. If not, the payment is rejected.

[0179] 8.13.2 Identity Verification 6. Alice 401 is pk e and pk e sends Alice's 401 digital certificate, signed using the private key associated with , to Bob 402. 7. Additionally, Alice 401 may also use any digital certificates and ephemeral keys pk of the user in the chain of transactions from the minting transaction to the current transaction. e to Bob 402. 8. Bob 402 checks the validity of each digital certificate. a. PK via digital certificate e Whether the signature created using is valid. b. The identity public key in the digital certificate is pk-pk e Whether it is or not. c. Whether the digital certificate is valid.

[0180] When Bob 402 wants to send a payment to an offline user requesting identity verification, Bob 402 sends Bob's 402 pk e along with Bob's 402 digital certificate and all digital certificates and keys that Bob 402 received from Alice 401.

[0181] 8.13.3 Public Key Formats To allow offline payment verification, the public key must be in the format pk=pk id +pk e This is not the case. Alice 401 can still prove her identity to Bob 402 if she receives a payment to a P2PKH using the public key pk' associated with the private key sk'. This means that Alice 401 can prove her identity to Bob 402 if she receives a payment to a P2PKH using the public key pk' associated with the private key sk'. e =sk'-sk id and the associated public key pk' e =pk'-pk id Then, Alice 401 defines pk' e Step 5 can be performed using the private key sk' e A signature can be created using:

[0182] 8.13.4 Security If Alice 401 submits a different version of TxID1 on the blockchain, she has signed two different transactions that consume Alice's 401 UTXO in TxID0. If Alice 401 provides Bob 402 with Alice's 401 digital certificate, Alice 401 is identifiable by trusted third party 801, and Alice 401 is legally responsible for double-spending and defrauding Bob 402.

[0183] Whoever sends the payment to Bob 402 must be Alice 401, i.e., Alice 401 cannot be impersonated by Charlie 103c without knowledge of Alice's private key. The reason is as follows: if TxID1 consumes Alice's UTXO in TxID0, Charlie 103c has knowledge of the private key sk. If Bob 402 has pk e , checks the signature via the digital certificate (step 7a), so Charlie 103c also has Alice's private key sk e As a result, Charlie 103c has knowledge of the private key sk id Therefore, Charlie 103c must be Alice 401.

[0184] 8.13.5 Proof of Work vs. Proof of Stake Charlie103c can be confident that the transaction is valid and that the inclusion of TxID0 in the block is appropriate based on the Merkle proof and the block header. With proof of work, a new block requires some amount of time to occur, so users can verify the validity of the chain even if it is received from an untrusted source. A malicious user cannot create a forged chain with the same embedded proof of work without wasting a significant amount of computing power and money. Proof of stake cannot guarantee the same level of security because the inclusion of a transaction in the blockchain is based on machine voting, which cannot be easily verified offline.

[0185] 8.13.6 Using a false name On-chain pk = pk id +pk e However, the payee (Bob) 402 does not have offline information (pk e +Digital certificates) can be used to always prove the identity of the payer 401. Thus, the verification protocol reduces the risk of offline transactions.

[0186] 8.14 Offline Payment Settlement In this section, we show how all recipients 402 who received offline payments and who have been double-spent can be refunded. To do this, we introduce two additional trusted third parties 801, called the enforcer entity 901 and the settlement entity 902. The settlement entity 902 is responsible for responding to the double-spend notification and correctly issuing payments to any users who have been double-spent. The enforcer entity 901 is responsible for capturing the damage done by the double-spending user. To illustrate the process and clarify the idea, we use the example given in FIG. 9, where Alice 103a, Frank 103f, merchant 1 903a, merchant 2 903b, and merchant 3 903c, as well as the enforcer entity 901 and the settlement entity 902, have at least level 3 connectivity.

[0187] We first explore the case where all users have digital certificates for the first KYC tier, and later explain how this requirement can be reduced. The flow of the payment scenario given in Figure 9 is as follows: 1. Alice 103a double-spends by consuming the same UTXO to make payments to Bob 103b and Frank 103f. 2. All offline participants, unaware that their payments depend on Alice's payment, exchange payments offline. Note: All payments are exchanged using an offline payment verification protocol, so all participants know all digital certificates of all payers up to Alice 103a. 3. Dave 103d makes a payment to merchant 1 903a, which is online. The payment follows the Level 1 payment protocol. 4. Merchant 1 903a detects a double spend when attempting to settle the transaction received from Dave 103d. 5. Alice 103a receives notification that she has double-spent, as well as the option to create transactions to pay the tokens to Bob 103b, Charlie 103c, Dave 103d, and Merchant 1 903a.

[0188] If Alice 103a does not create a transaction, a. Merchant 1 903a sends the dual spend proof along with the digital certificates of Alice 103a, Bob 103b, Charlie 103c, and Dave 103d to the settlement entity 902. b. The settlement entity 902 stores the chain of payments from Alice 103a to Merchant 1 903a and sends a digital proof of Alice's behavior to the enforcer entity 901. c. The settlement entity 902 creates new transactions to pay the damages to Bob 103b, Charlie 103c, and Dave 103d. The transaction created to make the payment to Charlie 103c is given in Table 6. d. The settlement entity 902 sends them to the blockchain network 106. When Bob 103b, Charlie 103c, and Dave 103d come online, they are notified of these payments. 6. Mallory 103m makes a payment to merchant 2 903b, which is online. The payment follows the Level 1 payment protocol. 7. Merchant 2 903b detects a double spend when attempting to settle the transaction received from Mallory 103m. 8. Alice 103a receives notification that she has double-spent, as well as the option to create transactions to pay the tokens to Bob 103b, Erin 103e, Mallory 103m, and Merchant 1 903a. If Alice 103a does not create a transaction, a. Merchant 2 903b sends the dual spend proof to the payment entity 902 along with the digital certificates of Alice 103a, Bob 103b, Erin 103e, and Mallory 103m. b. The settlement entity 902 stores the chain of payments from Alice 103a to Merchant 2 903b and sends additional proof of Alice's behavior to the enforcer entity 901. c. The settlement entity 902 creates a new transaction to make a payment to Erin 103e and Mallory 103m. The transaction created to make a payment to Erin 103e is given in Table 7. d. The settlement entity 902 sends the transaction to the blockchain network 106. When Bob 103b, Erin 103e, and Mallory 103m come online, they are notified of these payments. 9. For any transaction that Alice 103a declines to create, the enforcer entity 901 contacts Alice 103a. Alice 103a shall pay the delegating entity 302 the cost of all fees for the transaction that the settlement entity 902 must create, as well as the original payment that Alice 103a made to Bob 103b.

[0189] [Table 7]

[0190] [Table 8]

[0191] Note that if Bob 103b ends up double-spending when making payments to Erin 103e and Charlie 103c, he will also receive a notification to create an additional transaction. If Bob 103b remains offline, the enforcer entity 901 and settlement entity 902 shall intervene as in the protocol above.

[0192] To reduce the reliance on user digital certificates with the first KYC tier, one of the following alternative protocols may be used to increase user privacy:

[0193] 8.14.1 Alternative 1 In the above scenario, Merchants 1 and 2 will reject payments when they detect that they cannot mine transactions on the blockchain (steps 4 and 7). Furthermore, all offline users will lose any tokens created as change outputs as a result of creating transactions linked to Alice's payment. In this case, users do not need to use digital certificates, and offline payments should only be accepted within the web of trust.

[0194] 8.14.2 Alternative form 2 All protocol steps are followed, except that digital certificates have various KYC tiers and Alice 103a may not be liable for the double spend. Therefore, there is no need for an enforcer entity. In this case, the only proof the settlement entity receives is the double spend and the transaction being created offline. Therefore, the settlement entity can choose to cover all damages to offline users up to some token value. This alternative may be costly for the settlement entity if users create a sidechain that claims the double spend occurred in order to receive additional payments.

[0195] 8.14.3 Alternative form 3 This alternative combines the above protocol with alternative 1 to create a hybrid solution. The user has the option to request a digital certificate from a CA, but this is not required. For example, when Dave receives payment from Charlie, Dave can perform the following checks: 1. Check that everyone in the chain of payment (from Alice to Dave himself) has a digital certificate for the first KYC tier. 2. If yes, Dave accepts the payment. 3. If not (e.g., Bob does not have such a digital certificate), Dave can accept the payment at Dave's own risk. a. Dave receives any payments from any double spends made by users with first KYC tier digital credentials. b. Dave has no way to identify users who do not have the first KYC tier digital certificate who have double-spent with the settlement entity and the enforcer entity. In this case, the settlement entity has the option but is not required to cover Dave's losses.

[0196] 8.15 Transaction Fees A statistical model may be used to estimate how much value of the underlying asset (e.g., satoshis) is needed to feed the chain for T transactions, and to run the melt and mint protocol. We formulate one solution below, referring to the chain of transactions in Section 5.1.

[0197] The transaction outputs form a consumption graph. The graph is denoted by TxID0, ..., TxID5, and TxID melt Suppose we have a tree of height 6 (T=5) formed from N. Each node is a transaction output, and each outgoing edge from node N represents the consumption of UTXO associated with N. Figure 10 shows an example.

[0198] Furthermore, we associate a value V with each node N, which represents the amount of fees it can cover for subsequent transactions. For example, the root node shall cover its input fees and fees for all subsequent transactions, and shall limit each UTXO value to the dust limit l. dRetain beyond TxID melt The UTXO value of d The minting amount V is assumed to be the associated value of the root node. mint More formally, define V mint teeth,

[0199]

number

[0200] where fee is defined as in and fee out are the fees required to create P2PKH inputs and outputs, respectively, for every transaction.

[0201] The branching factor of the tree is defined as the average amount of branches that each node has in the tree. In this case, the minting amount for T=5 is

[0202]

number

[0203] where r in is the branching factor for the tree formed from TxID0, ..., TxID5, and r out TxID1, ..., TxID melt is the branching factor for the tree formed from r as follows: in Regarding out can be calculated.

[0204]

number

[0205] Any r in For r out ≦2, and r out = 2. In this case,

[0206]

number

[0207] It becomes. fee in , fee out , and l d is constant, so V mint To obtain an estimate for the branching factor r in We need an estimate for r using the following melt and mint protocol to heuristically estimate the value r in Determine. 1. Initial branching factor r in-0 Start with (e.g., 3). 2. Amount

[0208]

number

[0209] Use to mint coins. 3. Transactions TxID0, TxID1, ..., TxID5, TxID melt Execute. V mint If is too small, perform step 4. If not, perform step 5. 4. r as a branching factor in-0 +1 for early minting and step 2. 5. Branching factor r of the chain of transactions TxID0, ..., TxID5 in Calculate. 6. Moving Average Branching Factor

[0210]

number

[0211] Calculate. 7. For the next minting transaction, the branching factor r in-1 Perform step 2 using

[0212] For example, if the first six transactions are in Assume that the network has a branching factor of 0.5SAT / bytes and a branching factor of 3 (branching factor in Figure 10). in =74SAT, fee out =17SAT, and l d = 135SAT. In this case, the minting amount is V mint =74·1093+17·254+17280=102480SAT This becomes:

[0213] 7. Further Special Notes Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited not by the described embodiments, but only by the appended claims.

[0214] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0215] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, network entities may perform the function of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be nodes of the suitable Bitcoin network 106).

[0216] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, issuing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and issue blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0217] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in a similar manner as described above with reference to blockchain node 104.

[0218] Some embodiments are described with respect to a blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and in general, embodiments may use any type of suitable consensus mechanism, such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The node that is chosen is often called a validator. Blockchain nodes can look up their tokens for some time to have the opportunity to become a validator. Generally, the node that locks the largest stake for the longest period of time has the best chance of becoming the next validator.

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

[0220] Statement 1. A computer-implemented method for executing a token protocol using a blockchain, wherein a token transfer transaction requires inputs signed by respective parties and one or more respective outputs, each output comprising a respective locking script locking a respective amount of digital assets and comprising a respective token amount locked to a respective public key of a respective party, the method being executed by a delegating entity; Obtaining a token melt transaction, the token melt transaction comprising: i) a first input signed by a first party, the first input referencing respective outputs of a first token transfer transaction, each output locked to a first public key of the first party and comprising a first token amount; and ii) a first output locked to a melting public key of a delegating entity and comprising the first token amount; creating token minting transactions, the token minting transactions comprising: i) respective inputs signed by the delegating entity using a signature corresponding to the minting public key; and ii) respective outputs locking respective amounts of digital assets sufficient to fund one or more respective token transfer transactions, each output comprising a first token amount locked to a second public key of the first party; Submitting a token minting transaction to one or more nodes in the blockchain network; Equipped with.

[0221] Statement 2. The method of statement 1, receiving a request from a first party to initiate a Melt and Mint protocol; and in response, sending a delegating entity digital certificate to the first party, the delegating entity digital certificate comprising the delegating entity's melting public key.

[0222] Statement 3. The method of Statement 1 or Statement 2, wherein said creation of the token minting transaction is conditioned on verifying the identity of the first party.

[0223] Statement 4. The method of Statement 3, wherein said verifying the identity of the first party comprises: Obtaining a first party digital certificate comprising the first party's identity public key; receiving a signature from a first party based on the first party digital certificate; Validating the signature using an ephemeral public key obtained from the first party; and verifying that the identity public key is based on the first public key and the ephemeral public key of the party.

[0224] Statement 5. The method of any preceding statement, wherein the melting public key is different compared to the minting public key.

[0225] Statement 6. The method of any preceding statement, wherein said creating a token mint transaction is conditioned on determining that the token melt transaction is part of a chain of token transactions that traces back to one or more token mint transactions.

[0226] Statement 7. The method of any preceding statement, wherein said creation of a token mint transaction is conditioned on validating a token melt transaction, and said validating the token melt transaction: obtaining from a first party a list of transactions tracing back to one or more respective token minting transactions, linking the token melt transaction to each of the token minting transactions; using the list of transactions to verify that the first input of the token melt transaction can be traced back to a respective token mint transaction; and verifying that the first token amount provided by the first output of the token melt transaction is equal to the first token amount provided by each output of the first transfer transaction.

[0227] Statement 8. The method of statement 7, wherein said validating a token melt transaction comprises: For each token minting transaction in the list of transactions, obtaining a respective delegating entity digital certificate, the delegating entity digital certificate comprising a respective minting public key of each delegating entity used to sign a respective input of a respective token minting transaction; and verifying that each signature used to sign each input of each token minting transaction corresponds to a respective minting public key provided by a respective delegating entity digital certificate.

[0228] Statement 9. The method of statement 8, wherein said validating the token melt transaction comprises verifying that each delegation entity digital certificate is a valid certificate.

[0229] Statement 10. The method of any of statements 7-9, wherein said enabling of a token melt transaction comprises: verifying that the respective amounts of digital assets locked by the first outputs of the token melt transaction are equal to the sum of the respective amounts of digital assets locked by the respective outputs of the first token transfer transactions referenced by the first inputs of the token melt transaction and a transaction fee to be collected by the blockchain node for the token minting transaction to be recorded on the blockchain.

[0230] Statement 11. The method of any of statements 7-10, wherein said validating the token melt transaction comprises validating each transaction that traces back to a respective token mint transaction that links the token melt transaction to the respective token mint transaction.

[0231] Statement 12. A computer-implemented method for executing a token protocol using a blockchain, wherein each token transfer transaction requires inputs signed by a respective party and one or more respective outputs, each output comprising a respective locking script locking a respective amount of digital assets and comprising a respective token amount locked to a respective public key of a respective party, the method being executed by a first party; initiating a Melt and Mint protocol, the Melt and Mint protocol comprising: creating a token melt transaction, the token melt transaction comprising: i) a first input signed by a first party, the first input referencing a respective output of a first token transfer transaction, the first input being locked to the first party's first public key and comprising a first token amount; and ii) a first output locked to a delegating entity's melting public key and comprising the first token amount; submitting the token melt transaction to one or more nodes of a blockchain network; Obtaining a token minting transaction, the token minting transaction comprising: i) respective inputs signed by the delegating entity using a signature corresponding to the minting public key; and ii) respective outputs locking respective amounts of digital assets sufficient to fund one or more respective token transfer transactions, each output locked to a second public key of the first party and comprising a first token amount.

[0232] Statement 13. The method of statement 12, creating a second token transfer transaction, the second token transfer transaction comprising: i) a second input signed by the first party, the second input referencing a respective output of the token minting transaction; and ii) one or more respective second outputs, each second output locking a respective amount of digital assets, each second output comprising a respective locking script locked to a respective public key of a respective party, and a respective token amount, the sum of the respective token amounts equal to the first token amount; and submitting the second token transfer transaction to one or more nodes of the blockchain network.

[0233] Statement 14. The method of Statement 12 or Statement 13, wherein initiating the Melt and Mint Protocol: Requesting a token melt transaction from a delegating entity; receiving a delegating entity digital certificate from the delegating entity, the delegating entity digital certificate comprising the delegating entity's melting public key.

[0234] Statement 15. The method of statement 14, wherein creating the token melt transaction is conditioned on a delegating entity digital certificate received from the delegating entity being valid.

[0235] Statement 16. The method of any of statements 12-15, wherein the first party's first public key is different compared to the first party's second public key.

[0236] Statement 17. The method of any of statements 12-16, wherein the delegating entity has access to a first party digital certificate comprising the first party's identity public key, and the method further comprises: generating a signature based on the first party digital certificate using a private key corresponding to the ephemeral public key, the ephemeral public key being based on the first party's first public key and the first party's identity public key; and sending the signature to the delegating entity.

[0237] The method may comprise the first party sending a first party digital certificate to the delegating entity.

[0238] Statement 18. The method of any of statements 12-17, comprising sending the first party's second public key to the delegation entity.

[0239] Statement 19. The method of any of statements 12-18, wherein said initiating is responsive to a determination that the first party cannot create the next token transfer transaction due to an insufficient amount of digital assets.

[0240] Statement 20. 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 execute on the processing device, the code configured, when on the processing device, to perform the method of any of statements 1-19.

[0241] Statement 21. A computer program embodied on computer-readable storage and configured to, when executed on one or more processors, perform the method of any of statements 1-19.

[0242] According to another aspect disclosed herein, a method may be provided that comprises actions of a first party and a delegating entity.

[0243] According to another aspect disclosed herein, a system may be provided that includes computer devices of a first party and a delegating entity. [Explanation of symbols]

[0244] 100 systems 101 Packet Switched Network 102 Computer terminals and computer equipment 103 Users, Entities, Parties, and Agents 103a Alice 103b Bob 103c Charlie 103d Dave 103e Erin 103f Frank 103m Mallory 104 nodes, blockchain nodes, Bitcoin nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) networks, decentralized networks, blockchain networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input, input field 203 Output, Output Field 203 UTXO 301 Token Issuer 302 Delegated Entity 400 System 401 Transferor, Payer, First Party, User Wallet, Alice, User 402 Transferee, Recipient, Second Party, Bob, User 600 System 800 System 801 Trusted Third Party 901 Enforcer Entity 902 Settlement Entities 903a Retailer 1 903b Retailer 2 903c Retailer 3

Claims

1. 1. A computer-implemented method for executing a token protocol using a blockchain, wherein a token transfer transaction requires inputs signed by respective parties and one or more respective outputs, each output comprising a respective locking script locking a respective amount of digital assets and comprising a respective token amount locked to a respective public key of a respective party, the method being executed by a delegating entity; obtaining a token melt transaction, the token melt transaction comprising: i) a first input signed by a first party, the first input referencing each output of a first token transfer transaction, the each output being locked to a first public key of the first party and comprising a first token amount; and ii) a first output locked to a melting public key of the delegating entity and comprising the first token amount; creating token minting transactions, the token minting transactions comprising: i) respective inputs signed by the delegating entity using a signature corresponding to a minting public key; and ii) respective outputs locking a respective amount of the digital assets sufficient to fund one or more respective token transfer transactions, the respective outputs comprising the first token amount locked to a second public key of the first party; submitting the token minting transaction to one or more nodes of a blockchain network; A method comprising:

2. receiving a request from the first party to initiate a melt and mint protocol; and in response, sending a delegating entity digital certificate to the first party, the delegating entity digital certificate comprising the melting public key of the delegating entity.

3. 3. The method of claim 1 or 2, wherein the creation of the token minting transaction is conditioned on verifying the identity of the first party.

4. said verifying said identity of said first party comprising: obtaining a first party digital certificate comprising the first party's identity public key; receiving a signature from the first party based on the first party digital certificate; validating the signature using an ephemeral public key obtained from the first party; verifying that the identity public key is based on the first public key and the ephemeral public key of the party; The method of claim 3, comprising:

5. 5. The method of claim 1, wherein the melting public key is different compared to the minting public key.

6. 6. The method of claim 1, wherein the creation of the token mint transaction is conditioned on determining that the token melt transaction is part of a chain of token transactions that traces back to one or more token mint transactions.

7. The creation of the token mint transaction is conditioned on validating the token melt transaction, and the validating of the token melt transaction: obtaining from the first party a list of transactions tracing back to one or more respective token mint transactions, linking the token melt transaction to the respective token mint transactions; using the list of transactions to verify that the first input of the token melt transaction can be traced back to a respective token mint transaction; verifying that the first token amount provided by the first output of the token melt transaction is equal to the first token amount provided by the respective output of the first transfer transaction; 7. The method of claim 1, comprising:

8. The validation of the token melt transaction includes: For each token minting transaction included in said list of transactions, obtaining a respective delegating entity digital certificate, the delegating entity digital certificate comprising a respective minting public key of each delegating entity used to sign the respective input of the respective token minting transaction; verifying that each signature used to sign the respective input of the respective token minting transaction corresponds to a respective minting public key provided by a respective delegating entity digital certificate; The method of claim 7, comprising:

9. 9. The method of claim 8, wherein the validating the token melt transaction comprises verifying that each delegation entity digital certificate is a valid certificate.

10. The validation of the token melt transaction includes: verifying that the respective amounts of the digital assets locked by the first outputs of the token melt transaction are equal to the sum of the respective amounts of the digital assets locked by the respective outputs of the first token transfer transactions referenced by the first inputs of the token melt transaction and a transaction fee to be collected by a blockchain node for the token mint transaction to be recorded on the blockchain.

10. The method of claim 7, comprising:

11. 11. The method of claim 7, wherein the validation of the token melt transaction comprises validating each transaction that traces back to a respective token mint transaction that links the token melt transaction to the respective token mint transaction.

12. 1. A computer-implemented method of executing a token protocol using a blockchain, wherein each token transfer transaction requires inputs signed by a respective party and one or more respective outputs, each output comprising a respective locking script that locks a respective amount of digital assets and comprises a respective token amount locked to a respective public key of a respective party, the method being executed by a first party; initiating a melt and mint protocol, the melt and mint protocol comprising: creating a token melt transaction, the token melt transaction comprising: i) a first input signed by the first party, the first input referencing a respective output of a first token transfer transaction, the first input being locked to the first party's first public key and comprising a first token amount; and ii) providing a first output locked to the delegating entity's melting public key and comprising the first token amount. submitting the token melt transaction to one or more nodes of a blockchain network; obtaining token minting transactions, the token minting transactions comprising: i) respective inputs signed by the delegating entity using a signature corresponding to a minting public key; and ii) respective outputs locking the digital assets in respective amounts sufficient to fund one or more respective token transfer transactions, the respective outputs being locked to a second public key of the first party and comprising the first token amount; A method comprising:

13. creating a second token transfer transaction, the second token transfer transaction comprising: i) a second input signed by the first party, the second input referencing the respective output of the token minting transaction; and ii) one or more respective second outputs, each second output locking the digital asset in a respective amount, each second output comprising a respective locking script locked to a respective public key of a respective party, and a respective token amount, the sum of the respective token amounts equal to the first token amount; submitting the second token transfer transaction to one or more nodes of a blockchain network; The method of claim 12, comprising:

14. initiating the melt and mint protocol comprises: requesting a token melt transaction from the delegating entity; and receiving a delegating entity digital certificate from the delegating entity, the delegating entity digital certificate comprising the melting public key of the delegating entity.

15. 15. The method of claim 14, wherein the step of creating the token melt transaction is conditioned on the delegating entity digital certificate received from the delegating entity being valid.

16. 16. The method of claim 12, wherein the first public key of the first party is different compared to the second public key of the first party.

17. the delegating entity has access to a first party digital certificate comprising the first party's identity public key, and the method comprises: generating a signature based on the first party digital certificate using a private key corresponding to an ephemeral public key, the ephemeral public key being based on the first public key of the first party and the identity public key of the first party; sending the signature to the delegation entity; 17. The method of any one of claims 12 to 16, comprising:

18. 18. The method of claim 12, comprising sending the second public key of the first party to the delegation entity.

19. 19. The method of claim 12, wherein the initiating step is responsive to a determination that the first party cannot create a subsequent token transfer transaction due to an insufficient amount of the digital assets.

20. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to run on the processing device, the code configured to perform the method of any one of claims 1 to 19 when present on the processing device.

21. 20. 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 one or more processors.

Images