Blockchain-based token protocol

Abstract

A computer-implemented method for validating token transactions as part of a token protocol using a blockchain, the method comprising: obtaining candidate token transactions; and for each input of each of the candidate token transactions that reference the respective token transactions, obtaining a respective list of transactions tracing back to the respective token minting transaction that connects the candidate token transfer transaction to the respective token minting transaction; and validating the candidate token transfer transactions by verifying that each input of each of the candidate token transactions references or can be traced back to the respective token minting transaction using the respective list of transactions, and verifying that the sum of the respective token amounts included in each output of the candidate transaction equals the sum of the respective token amounts included in one or more respective outputs referenced by the candidate transaction.

Description

[Technical Field]

[0001] The present disclosure relates to methods for implementing token protocols, and in particular to methods related to transferring and validating tokens as part of a token protocol. [Background technology]

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

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

[0004] Nodes (often called "miners") in a blockchain network implement a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the network's nodes to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce 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 therefore accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is enforced by the actions of competing nodes, who act on behalf of the network and are incentivized to report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity 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. Every consumable output comprises an element specifying the amount of a digital asset derivable from a preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script specifying the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transfer a digital token or 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, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script defining one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises 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 disseminated and recorded in the blockchain, one criterion for legitimacy applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a legitimate transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored separately in the blockchain by the nodes and is constantly updated. Summary of the Invention [Problem to be solved by the invention]

[0009] In the modern world, cash still plays an important role in economies in several regions and various markets around the world. Cash provides instant, peer-to-peer transactions without a centralized authority and guarantees privacy for all parties. Moreover, cash can be used for transactions even when one or more parties do not have or have access to a bank account. However, as technology advances, traditional paper-based cash is becoming increasingly outdated, necessitating the need for new forms of cash. Blockchain-based cash, also known as digital cash, which can be exchanged digitally, for example, using a smartphone, is seen as an alternative to traditional cash. Digital cash has all the properties of traditional cash and is minted and backed by a trusted centralized institution, such as a central bank. However, instead of being printed on paper, it is published 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 types of token protocols) face several challenges, one of which is how to efficiently validate tokens and how to transfer tokens so that they can be efficiently validated. [Means for solving the problem]

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for validating token transfer transactions as part of 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 respective 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 performed by a second party; obtaining a candidate token transfer transaction from a first party to a second party, the candidate token transfer transaction comprising: i) one or more respective inputs, each of which is signed by the first party and references a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transactions comprising a respective input signed by a respective delegated entity, and each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each of which locks a respective amount of digital assets, each of which comprises a respective locking script locked to a respective public key of a respective party and a respective token amount, and wherein a sum of the respective token amounts included in each output equals a sum of the respective token amounts included in the one or more referenced respective outputs; obtaining, from the first party, for each respective input referencing a respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction that connects the candidate token transfer transaction with the respective token minting transaction; and validating the candidate token transfer transaction, wherein the validating the candidate token transfer transaction comprises: verifying that a respective input of each of the candidate token transfer transactions references a respective token minting transaction or can be traced back to a respective token minting transaction using a respective list of transactions; verifying that the sum of the respective token amounts included in each output of the candidate transfer transaction is equal to the sum of the respective token amounts included in one or more respective outputs referenced by the candidate transfer transaction; Equipped with.

[0012] According to one aspect disclosed herein, there is provided a computer-implemented method for implementing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of digital assets, comprising a respective locking script locked to a respective public key of the respective party, and comprising a respective token amount, the method being performed by a first party: sending a candidate token transfer transaction to a second party, the candidate token transfer transaction comprising: i) one or more respective inputs, each of which is signed by the first party and references a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transaction comprising a respective input signed by a respective delegated entity, and each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each of which locks a respective amount of digital assets, each of which comprises 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 sum of the respective token amounts included in the one or more referenced respective outputs; and sending to the second party, for each respective input referencing the respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction linking the candidate token transfer transaction with the respective token minting transaction.

[0013] Some token protocols rely on tracing token transactions back to their issuance (or minting) transactions to validate them. In other words, a token transaction can be considered valid only if it can be traced back to its issuance transaction. An issuance (or minting) transaction may be defined as a token transaction that is signed with a particular public key or with a public key owned by a particular entity. To enable token transactions to be validated efficiently, a party wishing to transfer a token (the mover) sends a candidate token transaction to the intended recipient (the transferee) along with one or more lists of transactions, each list containing a chain of transactions leading from the candidate transaction to its respective issuance (or minting) transaction. The validating party can then verify that the token in the candidate transaction actually originated from the minting transaction, and that the token in the issuance transaction was issued by the appropriate entity.

[0014] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [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 on a blockchain. [Figure 3] FIG. 1 is a diagram of a permutation of an exemplary token issuance protocol. [Figure 4] FIG. 1 is a schematic block diagram of an exemplary system for implementing a melting and casting protocol. [Figure 5] FIG. 1 illustrates an exemplary chain of transactions from a minting transaction to a melting transaction. [Figure 6] FIG. 1 is a schematic block diagram of an exemplary system for transferring and validating token transactions. [Figure 7] FIG. 10 illustrates an example payout 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. 10 illustrates an example permutation 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. Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises 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 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 utilizing 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, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain 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 the value of a digital asset, such as a 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 to the output of a preceding transaction 152, thereby chaining transactions together.

[0019] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for permutations of transactions (note that permutations of transactions 152 are allowed to diverge). The chain of blocks 151 goes 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, not to a preceding transaction.

[0020] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. 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." As used herein, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept any other transactions that attempt to consume the same output.

[0021] For a given current transaction 152j, the (or each) input comprises a pointer that references the output of a preceding transaction 152i in the transaction sequence, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consumption or redemption does not necessarily imply a transfer of financial assets, although that is certainly one common application. More generally, consumption may be described as spending an output or allocating it to one or more outputs in another, forward transaction. In general, a preceding transaction may be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence connected by pointers, and not necessarily to the time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0022] The input of the current transaction 152j also comprises the input's authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide change). In some cases, the transaction can also have multiple inputs to collect amounts from multiple outputs of one or more preceding transactions together and redistribute them into 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 an organization, wishes to institute a new transaction 152j (either manually or through an automated process utilized by the party), the instituting party transmits the new transaction from its computer terminal 102 to a recipient. The instituting party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 instituting the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate 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 verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (or "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is chained. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. In either case, 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 forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0024] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "spent") is whether it has not already been validly redeemed by the input of another, earlier transaction 152j 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 disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is a defined order to transactions, an account balance has a single, defined state at any given time.

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

[0026] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and therefore enforce 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 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness 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 altered because 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 blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0027] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves each puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve their puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[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 an additional acceptable amount of digital assets in a new special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof-of-work indicates the node constructing the new block's willingness to follow 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-generation) 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 is published. This fee is typically called a "transaction fee" and is discussed below.

[0029] Due to the resources involved in validating and publishing transactions, 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 could 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 handle 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 at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0031] Also connected to the network 101 are computing devices 102 of each of a number of participants 103 who act as consuming users. 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 participants may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0032] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes 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 roles required of blockchain nodes. Instead, each participant 103 interacts with the blockchain network 106 and thereby utilizes the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participating in the system 100, but are not shown for convenience. Each participant 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0033] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 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 utilizing 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 of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 configured to execute on the processing device. It will be understood that any actions attributed herein to a given participant 103 may be implemented using software executing on the processing device of the respective computing device 102. The computing device 102 of each participant 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 participant 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0034] The client application 105 may initially be provided to the computing equipment 102 of any given participant 103 on one or more suitable computer-readable storage media, for example downloaded from a server, or provided on a removable storage device such as a removable SSD, 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 has at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and thereby 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, the second function is to track the various transactions 152 scattered throughout the blockchain 150 that belong to that party. and matching the amount defined in the output of

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

[0037] An instance of 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 enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other party transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 to disseminate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0038] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice 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 handles the transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable per transaction via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0039] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every 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 means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0040] Upon being admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of their respective pool of 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever solves it first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion 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, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0041] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0042] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referencing the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing the absolute account balance again. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's transaction execution record (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[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 a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on 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), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication 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] Suppose Alice 103a wishes to create transaction 152j to transfer an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0046] By the time Alice creates her new transaction Tx1, or at least by the time she submits it to the network 106, the currently preceding transaction Tx0 may already have been validated and included in a block 151 of the blockchain 150. 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 submitted to the network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “successor” as used herein in the context of transaction sequencing refer to the order of transactions in the sequencing as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equally interchangeable with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. 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. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or node behavior.

[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 defines the conditions 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 recipient of the transaction in which the locking script is included). That is, the locking script defines the unlocking conditions, which typically comprise the condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0048] A locking script (also known as scriptPubKey) is 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 known as scriptSig) is code written in a domain-specific language that provides the information needed to meet 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 example shown, UTXO0 in output 203 of Tx0 is the UTXO of the locking script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A[Checksig P A ] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlocking script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a locking script, or by a node protocol, or a combination of these.

[0050] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (where the conditions 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, '<...>' means putting data on the stack, and '[...]' is the functionality the locking script contains (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, these scripts will create a locking script containing Alice's public key P as contained in the locking script in the output of Tx0. A is used to authenticate that the unlocking script in Tx1's input contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, a separate element specifying the signed portion of the data in plaintext need not be included, as it is essentially already present).

[0051] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

[0052] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, 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 outstanding 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 is disseminated 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 an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is fraudulent, even if all other conditions are met. Therefore, blockchain node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent, but what ultimately 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 of 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" part of the amount defined in the UTXO as spent while another part is not spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or another party the change in the second output of Tx1.

[0055] In practice, Alice will usually also need to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and thus not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., do not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference 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 a unique one of the UTXOs 203 of transaction 152.

[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 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103's entire balance. It is the role of the wallet function of the client application 105 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0057] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode 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 store 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 stored 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 specific 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 portions of the outputs that the digital signature signs depend on the SIGHASH flag, which is typically a four-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0059] A locking script may be referred to as a "scriptPubKey," referring to the fact that the locking script typically includes the public key of the party to which each transaction is locked. An unlocking script may be referred to as a "scriptSig," referring to the fact that the unlocking script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define 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 applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (either at the instigation of a related party or a third party). 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 transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transactions 152 between Alice and Bob 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 101 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more networking technologies or communication 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 may collectively be referred to as the side channel 107. Thus, it should be noted that when Alice and Bob are said to exchange certain information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even over the same type of network.

[0062] 4. Tokens A token may be defined as a unit of value issued by a (trusted) organization. Tokens may be used to represent and manage real-world assets. In this specification, tokens refer to digital assets behind a blockchain, 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 validated using trusted third-party services and / or using the blockchain's native scripting language. In the latter case, smart contracts that may be used to control tokens may be considered 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 centralized authority (e.g., a government or trusted organization) or a group of pre-authorized entities that are responsible for issuing, managing, freeing, and otherwise operating them. Conversely, permissionless tokens are a category of tokens whose exchange is not 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, a new transaction output (UTXO) is created each time one or more tokens are transferred from one public key to another. The validity of the native token (e.g., Bitcoin) is verified by the blockchain network 106 after each new transaction. However, when new tokens are minted and embedded in a UTXO, they require additional verification, as they are not automatically validated by the nodes 104.

[0065] A token scheme on a blockchain 150 is a distinct set of digital assets that are issued at a specific time and follow a specific set of rules for allocation. Tokens are issued by trusted parties known as issuers. It can be assumed that all parties can identify newly minted tokens from the issuer. If a token has followed all rules since it was issued, it can be considered valid at the current time. A key challenge facing token schemes is how to know that a token is valid at the current time. It is often useful to think of token validity verification as occurring in two steps: 1. Has the token ever been valid? This is usually done when the user receives the token. 2. Is the token valid at the moment? This is typically done when the user spends the token.

[0066] From a user journey perspective, the first step is important if 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 has the token: they want to know that the token has not been double-spent.

[0067] Consider an analogy with the blockchain itself: the native blockchain token is the UTXO. In this case, point 1 corresponds to the Merkle proof of the 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, instead of embedding tokens within UTXOs, the amount held by each user is stored in a contract that keeps track of all balances and provides token transfer functionality. This approach is preferred for blockchains that allow maintaining state, such as Ethereum ERC20 tokens. However, it is rarely used in UTXO-based blockchains because the state must be maintained within UTXOs, centralizing the protocol and creating large transactions.

[0069] 4.2 Retroactive Some token protocols involve so-called "retroactivity" methods to verify whether a token is valid. Retroactivity is a technique used by token protocols that prepares a token rule set and asks users to ensure that they follow the rule set. The challenge is that the only way to verify that a token was ever valid is to trace it back to issuance. Often, such protocols suggest that wallet software can be responsible for tracking the validity of tokens. However, it is not clear what happens if someone evades the wallet software. Another challenge is that with such protocols, it is easy to burn tokens if someone creates a token transaction that does not follow the token rules.

[0070] 4.3 Dust Limit The dust limit prevents transactions of very low value from being published on the blockchain 150. The reason for the dust limit is that under standard fee policies, very low-value outputs would require the expenditure of a fee higher than the value of the output itself, making the expenditure of these transactions uneconomical (the cost of the unlocking script is higher than the UTXO value).

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

[0072] 5. Melting and Casting Protocol FIG. 4 illustrates an exemplary system 400 for implementing a melting and minting 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 delegated entities 302, a mover (or payer) 401, a movee (or payee) 402, and one or more nodes 104 of a blockchain network 106. The mover and movee may also be referred to as a first party and a second party, respectively. The mover 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 movee 402 is described above. The movee 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 explained below, the delegated entity 302 is responsible for minting (i.e., issuing, or rather reissuing) new tokens in response to meltdown requests from token users, e.g., the mover 401. The mover is a token user who intends to transfer a certain amount of tokens to a transferee 402, who is the recipient of that amount of tokens. Here, transferring a token means transferring ownership of the token 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: The first of the conditions is that it must contain at least one input signed by the mover 401. A transfer transaction may contain more than one input signed by the mover 401. Each input in a transfer transaction must reference the output of a previous transfer transaction or the output of a minting transaction. Minting transactions are described below.

[0075] The second of the conditions is that the transfer transaction must include one or more outputs, each locked to a respective public key of a token user, e.g., the transferee 402. The one or more outputs may be locked to the transferor 401. Each output includes a respective token amount that defines 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 separately. In some examples, the token amount is included in a portion of the output that is not executed during script execution (specifically, the output's 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 move transaction must equal the sum of the token amounts included in the outputs of previous move or mint transactions referenced by the inputs of the current move transaction. As an example, if the current move transaction references a single output containing 50 tokens, the total tokens included in the outputs of the current move transaction must also be 50 tokens; for example, the current move transaction may include five outputs each containing 10 tokens.

[0077] Each output of a transfer transaction locks a respective amount of an 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 transaction's output locking script, the underlying digital asset is fundamental to the transaction and required by the blockchain protocol. Using Bitcoin as an example, the underlying asset is a unit known as a satoshi. The fourth condition is that each token output of a transfer transaction (a token output is an output containing a certain token amount) must lock a sufficient amount of the underlying asset. The sufficient amount can be a predetermined amount. The sufficient amount can be a fixed amount or a minimum amount. In some examples, the sufficient amount can be a proportion (i.e., a percentage) of the amount of the underlying asset locked by the output referenced by the previous transfer transaction's input.

[0078] A transfer transaction may have to meet one or more additional conditions to be considered valid, which are discussed below.

[0079] In response to the mover 401 determining that it cannot generate a valid movement transaction due to an insufficient amount of digital assets to create more than one token transaction, the mover 401 may initiate a melt and mint protocol with the delegated entity 302. Initiating the melt and mint protocol may comprise sending a request to the delegated entity 302. The mover 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 each output of the more than one movement transaction. The mover has at least a sufficient amount of digital assets to create a melt transaction (i.e., one token transaction), but less than the amount required to create two token transactions (e.g., two movement transactions).

[0080] The mover 401 generates a dissolution transaction. The dissolution transaction comprises an input that references the output of a most recent move transaction, where the output is locked to a first public key associated with the mover 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 dissolution transaction comprises an output that is locked to a dissolution public key associated with the delegated entity 302. The output of the dissolution transaction comprises the first token amount, e.g., 40 tokens. That is, the dissolution transaction dissolves the mover's existing tokens. Here, dissolving the tokens essentially means transferring the tokens to the delegated entity 302 so that they are no longer usable by the token users. The mover 401 submits the dissolution transaction to the blockchain network 106 directly or through an intermediate party, e.g., the delegated entity 302.

[0081] The delegated entity 302 obtains the dissolving transaction. For example, the delegated entity 302 may obtain the dissolving transaction from the blockchain 150 and / or the delegated entity may receive the dissolving transaction from the mover 401.

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

[0083] The mover 401 obtains a mint transaction. For example, the mover 401 may obtain the mint transaction from the blockchain 150 and / or the mover 401 may receive the mint transaction from the delegated entity 302. Upon obtaining the mint transaction, the mover 401 may generate a subsequent transfer transaction that transfers some or all of the first token amount to the transferee 402. That is, the mover 401 may generate a token transaction comprising inputs that reference the outputs of the mint transaction and are 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 mover 401 submits the token transaction to the blockchain network 106 directly or through an intermediate party, e.g., the delegated entity 302 or the transferee 402.

[0084] Figure 5 shows an example melt and mint protocol. Working from top to bottom, the top transaction shows an example mint transaction signed with a minting signature and with two token outputs, one locked to Alice's public key and the other locked to Frank's public key. Both Alice and Frank are issued 50 tokens. The next transaction shows Alice transferring 40 tokens to Bob and 10 tokens back to herself. A few transactions later, Dave transfers 40 tokens to Frank. Frank then initiates the melt and mint protocol by generating a melt transaction, since he cannot generate a token transaction due to insufficient funds. The melt transaction is signed by Frank and locks the 40 tokens to the melt public key. The delegated entity 302 then uses the mint transaction to mint the 40 tokens and locks them to Frank's public key.

[0085] In some examples, in response to receiving a request from the mover 401, the delegated entity 302 may send a digital certificate to the mover 401, the digital certificate comprising the resolving public key. The certificate certifies that the resolving public key is controlled by the delegated entity 302. The mover 401 may use the certificate to generate a resolving transaction, for example, by extracting the resolving public key. In some examples, the mover 402 may verify that the digital certificate is a valid certificate and proceed to the resolving and minting protocol only if the certificate is valid. Validating the certificate may comprise verifying that the certificate has not been revoked. Those skilled in the art will be familiar with methods for verifying that a digital certificate is valid. Proceeding to the resolving and minting protocol may comprise generating a resolving transaction.

[0086] The delegated entity 302 may verify the mover's identity before proceeding with the melting and minting protocol. Proceeding with the melting and minting protocol may comprise generating a minting transaction. In some examples, to verify the mover's 401 identity, the mover 401 may send a digital certificate to the delegated entity, where the certificate comprises an identity public key associated with the mover 401. In some examples, the certificate may be publicly available. The certificate certifies that the identity public key is controlled by the mover 401. The mover 401 may sign the certificate with a signature generated using a private key corresponding to the temporary public key. The delegated entity 302 may verify that the identity public key is based on (i.e., connects or is derived from) the first public key and the temporary key.

[0087] In some examples, the delegated entity 302 may verify that the melting transaction generated by the mover 401 is part of a chain of token transactions tracing back to one or more minting transactions before proceeding with the melting and minting protocol.

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

[0089] 6. Token Transfer and Validation FIG. 6 shows an example system 600 for implementing a transfer (e.g., payment) and 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 protocol may be used in conjunction with or separately from the melting and minting protocols described in Section 5. For example, the delegated entity 302 may use the validation protocol to validate a melting transaction. The mover 401 may transfer tokens from a minting transaction using the transfer protocol. As described, the movee 402 may use the validation protocol to validate a transfer transaction generated by the mover 401.

[0090] When transferring a token as part of the token protocol, the mover 401 may generate a movement transaction "candidate," which, once validated by the movee 402, is a movement transaction that should be submitted to the blockchain network 106. In some instances, there may be no difference between the movement transaction candidate received by the movee 402 and the corresponding movement transaction sent to the blockchain network 106, in which case the term "candidate" is simply used as an indicator for the transaction sent by the mover 401.

[0091] A candidate transfer transaction has at least one input signed by the mover 401 and referencing the output of a previous token transaction (either a previous transfer transaction or a minting transaction). A candidate transfer transaction may have more than one input, each referencing a respective token output. A transaction is a minting transaction if it is signed with a minting signature generated by the delegated entity 302. Each referenced output contains a respective token amount. A candidate transfer transaction has at least one output locked to the public key of the transferee 402. A candidate transfer transaction may have more than one output. 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 mover 401 sends candidate move transactions to the movee 402. The mover 401 also sends one or more lists, one for each candidate move transaction input, to the movee 402. Each list contains transactions tracing back from the candidate move transaction to one or more respective minting transactions via the transactions referenced by the respective input. For example, referring to FIG. 7 and using TxAliceBob as an example candidate move transaction, one list would contain each transaction in the chain of transactions tracing back from TxAliceBob via input IN_1 to minting transactions TxMint1 and TxMint2. Another list would contain each transaction in the chain of transactions tracing back from TxAliceBob via input IN_2 to minting transactions TxMint3 and TxMint4. Note that these lists may be transmitted together as one overall list. These lists may contain references to the transactions, e.g., their respective transaction identifiers, or the lists may contain the transactions themselves.

[0093] As mentioned, each minted transaction is signed with a respective minted signature corresponding to a respective minted public key. The mover 401 may also send to the movee 402 a respective certificate attesting to each minted public key as associated with each delegated entity.

[0094] The movee 402 validates the candidate move transaction using a validation protocol. The delegated entity 302 may also use a validation protocol to validate the dissolution transaction described in the section above.

[0095] The movee 402 receives a list of candidate move transactions and transactions tracing back from the candidate move transactions to minting transactions. The movee 402 uses these lists to verify that each input of the candidate move transaction traces back to its respective minting transaction. The movee 402 also verifies that the sum of the token amounts included in the outputs of the candidate move transaction equals the sum of the token amounts included in the outputs of the transactions referenced by the candidate move transaction's inputs. The candidate move transaction must pass both verifications to be considered valid.

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

[0097] As described herein, a candidate move transaction may undergo one or more additional verifications before being considered valid. For example, the movee 402 may verify that each minted transaction is signed with a signature corresponding to a respective minted public key controlled by each delegated entity 302. The movee 402 may perform this verification using a certificate received from the mover. Additionally, the movee 402 may verify that the certificate is valid.

[0098] In some examples, the transferee may verify that the candidate transfer transaction has a sufficient transaction fee to ensure that the candidate transfer transaction is not sent to a secondary member pool of the blockchain node 104. Transactions are collected in a secondary member pool (or secondary transaction pool) if they do 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 amount of digital assets locked by each output of the transaction and the sum of the amount 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 legitimate only if each transaction in the chain of transactions tracing back to the minting transaction is also legitimate. Thus, the transferee 402 may verify that each transaction in the chain of transactions is also legitimate.

[0100] As discussed, the delegated entity 302 may validate the dissolution transaction using a validation protocol. The delegated entity 302 performs steps equivalent to those described as being performed by the movee 402, where the candidate migration transaction is instead a dissolution 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 mover 401 and the movee 402, respectively, described with respect to FIGS. 4 through 7. The third party may be a trusted third party 801.

[0102] The first party 401 may operate a device that is not capable (i.e., not configured) of connecting to (i.e., sending data to) the blockchain network 106. In that case, the first party 401 may not be able to submit transactions to the blockchain network 106. As an example, the first party may not be able to connect to the blockchain network 106 via the Internet. The first party 401 may not be able 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 area where the first party 401 is located). The transaction may be for 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 capable (i.e., configured) of connecting to (i.e., sending 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 a first transaction based on the message. In some examples, the message comprises at least a portion of a transaction. In other examples, the first message comprises a 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 transmits 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 convert the first message into a first transaction. That is, the first 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 801 and / or the second party over the first connection. In these examples, the second party 402 also cannot send data to 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 mover 401 may send a candidate movement transaction, or a message including data for generating a candidate movement transaction, to the movee 402. The candidate movement transaction is described above with reference to FIGS. 6 and 7. The mover 401 and the movee 402 may communicate over any suitable connection common to both parties, e.g., a first connection. The movee 402 then sends the movement transaction (i.e., the candidate movement transaction, which is validated by the movee 402) to a trusted third party 801 over the first connection, e.g., GPRS. Rather than sending the movement transaction itself, the movee 402 may send a message including data for generating the movement transaction. The trusted third party 801 submits the movement transaction to the blockchain network 106 over a second connection, e.g., 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 moved party 402 over the first connection. The moved party may forward the response to the mover 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 because the blockchain 150 is public, it enables transparency in token distribution. Furthermore, through its consensus mechanism, the blockchain network 106 ensures the correct execution of digital cash payments.

[0109] 8.2 Issuer A token issuing authority (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 delegated entity, as described below.

[0110] 8.3 Delegated Entities Delegated entities can be highly regulated, trusted third-party entities (e.g., commercial banks) each with associated wallets. Their role is to: Receive newly issued tokens and store them using your wallet; Communicating with users (e.g., distributing issued tokens to users), and Submitting the transaction to the blockchain network 106.

[0111] These entities establish network connections with the blockchain network 106, issuers, and user wallets. Some issuers may also be delegated entities.

[0112] 8.4 Users A user (e.g., a citizen wishing to exchange digital cash payments) has an associated user wallet. The wallet receives tokens from delegated entities and makes digital cash payments to other user wallets. The wallet may be connected to the blockchain network 106 relying on a P2P payment protocol, and the wallet also establishes connections with other user wallets and with one or more delegated entities. A user cannot be either an issuer or a delegated 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, delegated entities, and users. It is envisioned that several trusted third parties (TTPs) and certification authorities (CAs) may be embodied, for example, by central banks and government agencies.

[0114] 8.5.1 PKI Each user has a secret key, sk id and the associated public key pk id public key pk id is authenticated 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. The user identifies themselves with their national ID, or 2. The user has either confirmed their phone number and / or email address.

[0115] A second option may be to limit how many transactions and value each digital cash payment a user can perform. Authentication of this proof (i.e., the digital certificate generated in Section 8.5.2) may be added on the chain.

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

[0117] The token issuer and delegated entity PKI may have one or more master keys stored offline and securely (i.e., cold storage). These master keys are used to generate online level 1 keys (L1), which are maintained online and have a limited validity period (e.g., one month), and are used for attestation. From these keys, the token issuer and delegated entities can derive level 2 keys (L2), which are used to sign transactions. The L2 keys have an even stricter validity period (e.g., one day). Like the user identity keys, the L1 and L2 keys are certified by a CA.

[0118] The PKI structure just described can be deployed using a randomly generated L2 key and then authenticated using a signature from a valid L1 key. Here, the public key is linked to an output point, and it is possible to verify whether the public key is valid by simply checking whether the corresponding output point is in the UTXO set. In other words, the public key is valid until the associated UTXO remains in the member UTXO set, and it can be made invalid by spending the associated UTXO.

[0119] 8.5.2 Digital Certificates Each digital certificate may contain some or all of the following information: Hashes of personal information, such as phone numbers, email addresses or national IDs (for users), or registration numbers (for token issuers or delegated entities); Certification tier, which refers to what type of KYC the user has performed. The delegated entity's tier will always point to the strongest KYC process. Identity public key in case of a user, or L1 or L2 public key in case of a delegated entity, Date of certificate issuance, Certificate expiration date, A digital signature of the above items created using the CA's private key.

[0120] The validity periods of L1 and L2 keys are managed through the issuance and expiration of digital certificates.

[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 described 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 a digital certificate may be renewed before its expiration date. This does not invalidate previous certificates unless they have expired.

[0123] Upon receiving a digital certificate, the entity or user: 1. The current date is between the issue date and the expiration date, and 2. The digital signature is valid Establish its legitimacy by verifying that:

[0124] 8.6 Token Issuance and Structure Tokens can only be issued by a token issuer and are not backed by 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] Once issued, the token is embedded in a transaction and addressed to one of the delegated entities. The delegated entity may be randomly selected, or the delegated entity requests new tokens for distribution. If the user is eligible to receive the token (e.g., if the user requests a digital cash transfer), the delegated 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:<Token Specification> can be as follows:

[0129] [Table 2]

[0130] 8.7 Delegated Entity Wallets Each delegated entity has an associated wallet that keeps track of the tokens it can distribute to other users. The capabilities supported by the wallet may include one or more of the following: Keeping track of the total amount of tokens available for distribution. For each token, record the exit point location (the UTXO index and transaction ID where the token is located). Prepare a key wallet and create a private-public key pair as described above. Record the CA's public key. · Communicate with other delegated entities. Receive the token issued by the token issuer. -Distribute issued tokens to users.

[0131] The following details how a delegated entity can receive payment from a token issuer: Figure 3 shows an example protocol for issuing tokens. 1. The delegated entity 302 and the token issuer 301 exchange their digital certificates off-chain. 2. The delegated entity 302 and the token issuer 301 verify the validity of the received digital certificate. If the certificate is valid, the remaining steps are executed. Otherwise, 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 delegated 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. The issuer 301 sends a copy of the transaction off-chain to the delegated entity 302. The delegated entity 302 is now aware of the transaction contents and the amount of issued digital cash they can distribute to user wallets.

[0132] Because the token issuer 301 and the delegated entities 302 have associated digital certificates and transactions are published on-chain, the protocol for issuing tokens is secure when the majority of delegated entities 302 are behaving correctly.

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

[0134] To distribute the issued tokens to user wallets, the delegated entity 302 uses the TxIDs shown in Table 2. issue The following transaction can be created that consumes the output of

[0135] [Table 3]

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

[0137] A user can receive a token in their wallet from a delegated entity 302 if: A user receives a transfer (e.g., a Digital Cash withdrawal) from their bank (acting as a delegated entity) to their Digital Cash wallet. The user performs the melting and casting protocol described below.

[0138] Penalty kick userTo calculate , the user wallet may choose one of the following options: Penalty kick user pk as follows id and pk e 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. Or, PK user is derived by the wallet using a key derivation mechanism such as BIP32.

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

[0140] Penalty kick user can only be used once, pk id The lack of correlation makes it impossible to correlate the on-chain public key PK user identity public key pk id To achieve this, we ensure that the temporary public key pk e =PK user -pk id It is sufficient that the

[0141] 8.9 Melting and Casting Protocols This section details how users can send and receive digital cash payments using a Layer 2 protocol that requires less interaction with the delegated entity 302 than some protocols. The protocol aims to strike a balance between addressing the issue of traceability and decentralization. Any of the examples described in this section can be used with the melting and minting protocol described in Section 5 above.

[0142] Digital cash payments between users are called peer-to-peer (P2P) transactions, payments, or transfers. Unless otherwise stated, the term X token refers to one and only one UTXO containing a digital cash payment of value X.

[0143] The melt and mint protocol is a protocol that reduces the number of checks that must be performed to validate a token; that is, tokens do not need to be traced back to issuance, thereby solving the trace back issue. Since the delegated entity 302 can create a bottleneck during peak hours, its role is minimized in P2P transactions without removing the delegated entity entirely. In this approach, the delegated entity 302 must validate the token (acting as a checkpoint) between two transactions called melt and mint transactions. The two transactions are defined as follows: A dissolution transaction (representing a dissolution checkpoint) in which a token is sent from a user (e.g., a traveler 401) to a delegated entity 302; A minting transaction (representing a minting checkpoint) in which the token is returned from the delegated entity 302 and returned to the same user.

[0144] After the minting transaction, there are, on average, T chained transactions before the melting transaction.

[0145] Each user wallet may store a unit of underlying digital asset, e.g., satoshis. These satoshis are located in the value of each UTXO containing tokens. They are received from a delegated entity 302 when the user wallet requests a transfer, for example, from a bank to their digital cash wallet, or through a melt-and-mint protocol. Receiving satoshis from a delegated entity 302 acts like a top-up system for users, and the role of the satoshis is to cover the transaction fees of P2P payments without the delegated entity 302 being involved in the payment processing. The structure of a P2P payment is shown in Table 3 below.

[0146] [Table 4] TIFF2025531835000006.tif10138

[0147] The above transaction requires the mover, Alice 401, to spend Z=X+Y tokens contained in a UTXO of value s satoshis. In addition, Alice sends half of her satoshis to the movee, Bob 402, and receives the remainder of her satoshis minus the transaction fee. As a result, Bob 402 has s / 2 satoshis in his wallet, which consumes his X tokens. The choice to send s / 2 to Bob 402 is arbitrary; other choices may be made by the wallet.

[0148] Whenever the user wallet of the traveler 401 wishes to spend tokens located in a UTXO with insufficient satoshis to create at least two more transactions, the Threshold T melt and mint protocol performs the following steps: 1. The user wallet 401 requests a melting checkpoint from the delegated entity 302. 2. The delegated entity 302 sends its digital certificate to the user wallet 401. 3. The user wallet 401 verifies 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 delegated entity 302 contained in the certificate. The created transaction is a dissolving transaction. 5. A public key PK' for which user wallet 401 wishes to receive tokens. user is derived. 6. The delegated entity 302 verifies the identity of the user wallet. The user wallet 401 sends the digital certificate to the delegated entity 302. b. The delegated entity 302 verifies the digital certificate. c. User Wallet 401 pk e =PK user -pk id Sends a signature to a digital certificate created using the PK user is the public key included in the input of the dissolving transaction. d. The delegated entity 302 verifies the signature received in step 6c. e. The delegated entity 302 uses the pk id PK id =PK user -pk e Verify that the following is satisfied. 7. The delegated entity 302 verifies that all tokens are valid by tracing back to each minting transaction using the validation protocol described below. 8. The delegated entity 302 creates a minting transaction with a payment to the address provided by the user 401. The payment is made to a. The same amount of tokens sent by the user wallet 401 to the delegated entity through a dissolution transaction b. Enough associated satoshi value to cover T transactions on average, until step 1 needs to be performed again. It is included in the UTXO consisting of

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

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

[0151] In summary, melting and casting presents the following characteristics: The delegated entity 302 waits for requests for melting and minting tokens. The delegated entity 302 pays only the minting transaction fee for bearing the chain of T transactions. · The public melting key is always different from the minting public key, so when melting and minting is performed, the traceability of the payment to the public is reduced.

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

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

[0154] We will further elaborate on step 3 and use 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 delegated entity 302. The right-most transaction is a payment from Alice 401 to Bob 402 and the change returned to Alice 401. The diagram shows a payment tree that Bob 402 needs to validate to accept payment from Alice 401, with the leaves represented by minting transactions. In general, the set of transactions received by Bob 402 may form a directed acyclic graph (DAG). We will now detail how Bob 402 can validate the tokens received from Alice 401. As shown in Table 4, the transaction Bob 402 receives from Alice 401 has the following format:

[0155] [Table 5]

[0156] Assume Alice 401 unlocks Z tokens and z satoshis. To validate this transaction, Bob 402 must verify the following: 1. Z (number of unlocked tokens) = X (tokens received) + Y (change tokens returned to Alice). 2. Verify that the Token Specification has the required format. 3. z=x+y+fee (transaction fee paid to miner) - to ensure that this transaction is not added to the secondary member pool of the blockchain node 104, which may prevent the transaction from being recorded in the blockchain 150.

[0157] Additionally, Bob402 has TxID AliceBobTo do this, Bob 402 performs the same check to ensure 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 if the sum of the input tokens is the same as the sum of the output tokens. 2. Check whether sufficient transaction fees have been paid. 3. Check that the token specification is followed.

[0159] Essentially, Bob 402 performs a DAG traversal algorithm (eg, depth-first search (DFS) and breadth-first search (BFS)) to verify 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 the delegated entity 302. To verify that the above transaction is a minting transaction, Bob 402 must verify the following: 1. Penalty kick mint is located in the corresponding digital certificate 2. The delegated entity's digital certificate is valid. The certificate may happen to be expired. In this case, the user wallet 402 can either accept the payment at its own risk or require the delegated entity 302 to perform validation and verify the payment's validity using on-chain data.

[0162] Bob may also send the following to the next payee when making a digital cash payment so that the payee can validate the payment: 1. Bob sends a transaction payment to the payee. 2. For each input, Bob submits the complete payment DAG of transactions (or trees). 3. Bob sends all digital certificates of delegated entities involved in each minting transaction that is part of Alice's payment DAG. 4. Bob can then delete each transmitted digital certificate corresponding to the delegated entity.

[0163] Finally, all the above steps can also be performed by the delegated entity 302 when receiving tokens from the user wallet 401. This is done through a dissolution transaction as described above. The validation protocol is the same.

[0164] The token validation process can be quite heavy in terms of communication (step 1) and validation (step 3). This is because the number of transactions grows exponentially with the number of outputs. Therefore, if there are too many transactions to send to the payee (e.g., more than 10), the payer can first ask for an early execution of melting and minting, and then send the payment to the payee. This reduces the communication to only two transactions: the minting 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 computational power to validate ECDSA signatures and perform SHA256 hashes. However, depending on location, token payments may be made online or offline, and the verification that the payee must perform depends on connectivity to the blockchain network 106. Devices may be differentiated by their level of connectivity. Level 1 - Internet connection Level 2 - Mobile coverage (e.g., GPRS) Level 3 - Low frequency (e.g., 300MHz) radio coverage Level 4 - Offline

[0166] Users 401, 402 have connectivity level 3 if they possess 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 that the implementation cost is low because the radio infrastructure already exists and it has a wider reach 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, convert them into transactions, and forward them to the blockchain 150. These trusted third parties 801 could be mobile phone or wireless companies or the companies that built the network infrastructure behind them. The trusted third parties 801 do not necessarily have to be one of the delegated entities 302, although that is also an option.

[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 connection level, different confirmation or communication protocols need to be established between the payer 401, the payee 402, and the blockchain network 106. The payer 401 can have any connection level as long as it can communicate with the payee 402. Each payment protocol is detailed for each connection level of the payee 402, assuming that melting and re-minting may not be performed. Any of the examples described in this section may be used 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 to Payee 402 a. Transactions involving token payments b. A list of transactions that link payments to minting transactions Send. 2. The payer 401 sends the payee 402 the digital certificate of the delegated entity 302 that created the minting transaction to which the payer's transaction is chained. 3. The payee 402 verifies the validity of the transaction and whether the token rules have been correctly implemented by tracing the token payment back to the minting transaction, which is identified using the delegated entity's digital certificate. 4. The payee 402 submits the transaction to the blockchain.

[0171] 8.11.2 Level 2 and 3 Protocols 1. The payer 401 and payee 402 perform steps 1 to 3 of the Level 1 protocol. 2. The payee 402 submits the transaction via SMS or wireless to a trusted third party 801. 3. A trusted third party 801 submits a transaction to the blockchain 150 and receives a response from the blockchain network 106. 4. The trusted third party 801 sends a response to the payee 402 via SMS or wireless. 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. The payer 401 and payee 402 perform steps 1 to 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. Payee 402 performs the verification detailed in Section 8.13. 4. If all checks are performed successfully, the payee 402 accepts the payment. In the case of double spend, once the payee 402 has a better connection (level 3 or higher), the protocol in Section 6.2 is executed.

[0173] Even though the payee 402 performs validation in offline payments, the payee 402 still relies on some 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 Integration of Melting and Casting If the payee 402 is always online (level 1 connection), the payee 402 may choose to perform melting and minting before every token payment. By invoking melting and minting, there is no traceable link between the transactions from the public's perspective, and the delegated entity 302 has no knowledge of the token payment being made until melting and minting is invoked by the payee 402.

[0175] On the other hand, level 2, 3, and 4 connections always rely on melting and minting, which involves a threshold of T transactions. When a user runs out of available fees or reaches threshold T, a reminting must occur. For levels 2 and 3, users can request a reminting. However, for level 4, users must increase their connection level to at least 3. This can be achieved as follows: Users find geographic areas with wireless or mobile coverage, or One of the delegated entities may have a mobile station that can be called by the user or that periodically passes through the user's territory. The mobile station has at least a Level 3 connection, and the user connects to it for recasting.

[0176] 8.13 Offline Payment Validation To enable offline payments between users, we need to ensure that the legitimacy of the transaction can be verified and that users can be held accountable if they are fraudulent. Referring to the example transaction chain of Figure 5, assume that Alice 401 wants to pay Bob 402 and that Bob 402 is offline. Bob 402 receives the following from Alice 401 (e.g., via Bluetooth): Transaction TxID1 from Alice401, Minting transaction TxID0, Merkle proof of inclusion of transaction TxID0 in the block, and Block header with TxID0 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 role of CA, this does not incur significant storage costs. The verification protocol is divided into a payment verification part and an identity verification part.

[0178] 8.13.1 Payment Validation 1. Bob402 uses TxID0's Merkle proof to compute the Merkle root. 2. If the Merkle root is not the same as the Merkle root in the block header, Charlie103c refuses to pay. 3. Otherwise, Bob 402 checks whether the difficulty target in the block header where the transaction is stored exceeds a predetermined threshold. If not, it stops the protocol because Alice 401 may have sent an invalid Merkle proof and header. 4. Bob402 receives the signature and public key of TxID1 from Alice. pk=pk id +pk e Check whether to spend Alice's UTXO for 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 verifies the validity of the token. If it is invalid, the payment is rejected.

[0179] 8.13.2 Identity Verification 6. Alice401, pk e and pk e sends Bob 402 his digital certificate, which is signed using the private key associated with 7. Furthermore, Alice 401 has all the digital certificates and ephemeral keys pk of the users in the chain of transactions from the minting transaction to the current transaction. eto Bob402. 8. Bob 402 verifies the validity of each digital certificate. a. PK to Digital Certificate e Whether the signature created using is valid. b. pk-pk e is the identifying public key in a digital certificate. c. Whether the digital certificate is valid.

[0180] If Bob 402 wants to send a payment to an offline user who requests identity verification, Bob 402 must provide his pk e and sends its own digital certificate along with all the digital certificates and keys it 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 It may seem obvious that it must be true. This is not the case. If Alice 401 receives a payment to a P2PKH using the public key pk' associated with the private key sk', then Alice can still prove her identity to Bob 402. This is because Alice 401 has a temporary private key sk' e =sk'-sk id and the associated public key pk' e =pk'-pk id Then, Alice 401 defines pk' e Perform step 5 using the private key sk' e A signature can be created using:

[0182] 8.13.4 Security If Alice 401 publishes different versions of TxID1 on the blockchain, then Alice 401 has signed two different transactions that consume her UTXO at TxID0. If Alice 401 provides her digital certificate to Bob 402, then Alice 401 is identifiable by trusted third party 801, and Alice 401 is legally liable for double-spending and for deceiving Bob 402.

[0183] Anyone sending a payment to Bob402 must be Alice401, i.e., Charlie103c cannot impersonate Alice401 without knowledge of Alice's private key. The reason for this is as follows: if TxID1 consumes Alice's UTXO at TxID0, Charlie103c has knowledge of the private key sk. Bob402 has knowledge of pk e to verify the signature on the digital certificate (Step 7a), Challie103c will have Alice's private key sk e As a result, Charlie103c has knowledge of the private key sk id Therefore, Charlie103c must be Alice401.

[0184] 8.13.5 Proof of Work vs. Proof of Stake Charlie103c can be confident that the transaction is valid and that including TxID0 in the block is correct, based on the Merkle proof and the block header. With Proof of Work, new blocks require a certain amount of time to be produced, allowing users to verify the validity of the chain even if it is received from an untrusted source. A malicious user cannot create a fake chain with the same proof of work embedded in it without expending an exorbitant amount of computing power and money. With Proof of Stake, the inclusion of a transaction in the blockchain is based on machine voting, which cannot be easily verified offline, so the same level of security cannot be guaranteed.

[0185] 8.13.6 Anonymity pk=pk id +pk e The transaction is anonymous because only the payee (Bob) 402 is published on the chain. However, the payee (Bob) 402 always has offline information (e.g., pk e +Digital certificates) can be used to prove the identity of the payer 401. Thus, the verification protocol mitigates the risks of offline transactions.

[0186] 8.14 Offline Payment Settlement In this section, we show how all payees 402 who received offline payments and were double-spent can be refunded. To do this, we introduce two additional trusted third parties 801, which we call the enforcer entity 901 and the settlement entity 902. The settlement entity 902 is responsible for responding to the double-spend notification and correctly paying any users who double-spent. The enforcer entity 901 is responsible for recovering any damages caused by the double-spending users. To illustrate this process and clarify the concept, we use the example given in FIG. 9, where Alice 103a, Frank 103f, Merchant 1 903a, Merchant 2 903b, and Merchant 3 903c, and where the enforcer entity 903 and the settlement entity 902 have at least a level 3 connection.

[0187] We first look at the case where all users have a digital certificate for the first KYC layer, and then discuss 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 pay Bob 103b and Frank 103f. 2. All offline participants exchange payments offline and are unaware that their payments depend on Alice's payments.

[0188] 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. Dave103d makes a payment to Merchant1 903a, which is online. This 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 and the option to create a transaction to pay the tokens to Bob 103b, Charlie 103c, Dave 103d, and Merchant 1 903a.

[0189] If Alice103a does not create a transaction, a. Merchant 1 903a sends the double spend proof along with the digital certificates of Alice 103a, Bob 103b, Charlie 103c, and Dave 103d to the payment 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 a new transaction to pay the damages to Bob 103b, Charlie 103c, and Dave 103d. The transaction created to pay Charlie 103c is given in Table 6. d. The settlement entity 902 transmits them to the blockchain network 106. Bob 103b, Charlie 103c, and Dave 103d are notified of these payments when they come online. 6. Mallory103m makes a payment to merchant 2 903b, which is online. The payment follows the Level 1 payment protocol. 7. Merchant 2 903b detects the double spend when it attempts to settle the transaction received from Mallory 103m. 8. Alice 103a receives notification that she has double-spent and the option to create a transaction to pay the tokens to Bob 103b, Erin 103e, Mallory 103m, and Merchant 1 903a.

[0190] If Alice103a does not create a transaction, Merchant 2 903b sends the double spend proof along with the digital certificates of Alice 103a, Bob 103b, Erin 103e, and Mallory 103m to the payment entity 902. 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 pay Erin 103e and Mallory 103m. The transaction created to pay Erin 103e is given in Table 7. d. The settlement entity 902 submits the transaction to the blockchain network 106. Bob 103b, Erin 103e, and Mallory 103m are notified of these payments when they come online. 9. For any transactions that Alice 103a refuses to create, the executor entity 901 contacts Alice 103a. Alice 103a must pay the delegated entity 302 the cost of all fees for transactions that the settlement entity 902 must create, as well as the initial payment made to Bob 103b.

[0191] [Table 7]

[0192] [Table 8]

[0193] Note that if Bob 103b double-spends when paying Erin 103e and Charlie 103c, Bob 103b also receives a notification to create an additional transaction. If Bob 103b remains offline, the executor entity 901 and settlement entity 902 must intervene as per the protocol above.

[0194] To reduce the reliance on user digital certificates with a first KYC layer, one of the following alternative protocols can be used to improve user privacy:

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

[0196] 8.14.2 Alternative form 2 All protocol steps are followed, except that digital certificates have a variable KYC hierarchy, and Alice 103a may not be held responsible for the double spend. As a result, no enforcer entity is required. In this case, the only proof the settlement entity receives is the double spend and the transaction created offline. Therefore, the settlement entity may choose to bear all damages to the offline user up to a certain token value. This alternative may be costly for the settlement entity if the user creates a sidechain claiming that the double spend occurred in order to receive additional payments.

[0197] 8.14.3 Alternative form 3 This alternative combines Alternative 1 with the above protocol to create a composite strategy. 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 if anyone in the chain of payments (from Alice to you) has a digital certificate for the first KYC layer. 2. If so, Dave will accept payment. 3. If not (e.g. Bob doesn't have it), Dave can accept the payment at his own risk. a. Dave will accept any payment from any duplex consumed by a user with a first KYC tier digital certificate. b. Without the double-spent first KYC layer digital certificate, Dave has no way of identifying the user to the settlement entity and the enforcer entity. In this case, the settlement entity has the option, but is not required, to absorb Dave's losses.

[0198] 8.15 Transaction Fees A statistical model can be used to estimate how many underlying assets (e.g., satoshis) are needed to feed the chain for T transactions and execute the melting and minting protocol. One approach is developed below, referring to the chain of transactions in Section 5.1.

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

[0200] Furthermore, we associate a value V with each node N, which represents the amount of fees it is willing to incur for subsequent transactions. For example, the root node will incur its input fee and fees for all subsequent transactions, and will also incur each UTXO value up to the dust limit l d Must be kept above TxID melt The UTXO value is the dust limit d The value associated with the root node is assumed to be equal to the mintage V mint More formally, V mint teeth

[0201]

number

[0202] is defined as fee in and fee out is the fee required to create each P2PKH input and output for every transaction.

[0203] We define the branching coefficient of a tree as the average amount of branches each node has in the tree. Then, the mintage for T=5 is

[0204]

number

[0205] and r in is the branching coefficient of the tree formed from TxID0, ..., TxID5, and r out is TxID1, …, TxID melt is the branching coefficient of the tree formed from out r in Regarding

[0206]

number

[0207] It can be calculated as follows.

[0208] Any r in For r out ≦2, and overall out = 2. Then,

[0209]

number

[0210] is.

[0211] fee in , fee out , and l d is a constant, so V mint To get an estimate for the branching coefficient r in An estimate of the value r is required. Using the following melting and casting protocol, in is determined heuristically. 1. Initial branching factor r in-0 Start with (for example, 3). 2. Forehead

[0212]

number

[0213] Use to mint coins. 3. Transactions TxID0, TxID1, ..., TxID5, TxID melt Execute.

[0214] V mint If is too low, perform step 4. Otherwise, perform step 5. 4.r in-0 Use +1 as the branching factor to perform early casting and step 2. 5. Branching factor r of the chain of transactions TxID0, …, TxID5 in Calculate. 6. Moving Average Branching Factor

[0215]

number

[0216] Calculate. 7. Branching factor r for the next minting transaction in-1 Perform step 2 using

[0217] For example, the first six transactions are in Assume that the network has a branching factor of 3 (branching factor in Figure 10). With a transaction fee rate of 0.5 SAT / byte, the fee in =74SAT, fee out =17SAT,l d =135SAT. Then, the mintage amount is V mint =74·1093+17·254+17280=102480SAT.

[0218] 7. Further Observations Other variations or uses of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments.

[0219] 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 understood that the Bitcoin blockchain is one specific 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 properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0220] 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, publishing, disseminating, and storing blocks 151 of 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 functions of disseminating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0221] 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, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or disseminate those blocks 151 to other nodes.

[0222] 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, publishing, disseminating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with respect to blockchain node 104.

[0223] Some embodiments have been described with respect to blockchain networks 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 appropriate consensus mechanism, such as 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 produce the next block 151. This selected node is often called a validator. Blockchain nodes can lock their tokens for a certain amount of time to gain the possibility of becoming a validator. Generally, the node that locks the largest stake for the longest period of time has the highest chance of becoming the next validator.

[0224] It will be understood that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided in accordance with any one or more of the following statements:

[0225] Statement 1. A computer-implemented method for validating token transfer transactions as part of a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of digital assets, comprising a respective locking script locked to a respective public key of the respective party, and comprising a respective token amount, wherein the method is performed by a second party; obtaining a candidate token transfer transaction from a first party, the candidate token transfer transaction comprising: i) one or more respective inputs, each of which is signed by the first party and references a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transactions comprising a respective input signed by a respective delegated entity, each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each of which locks a respective amount of digital assets, each of which comprises 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 included in each output equals the sum of the respective token amounts included in the one or more referenced respective outputs; obtaining, from the first party, for each respective input referencing a respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction that connects the candidate token transfer transaction with the respective token minting transaction; and validating the candidate token transfer transaction, wherein the validating the candidate token transfer transaction comprises: verifying that a respective input of each of the candidate token transfer transactions references a respective token minting transaction or can be traced back to a respective token minting transaction using a respective list of transactions; verifying that the sum of the respective token amounts included in each output of the candidate transfer transaction is equal to the sum of the respective token amounts included in one or more respective outputs referenced by the candidate transfer transaction; A method comprising:

[0226] Statement 2. 10. The method of claim 1, comprising, if determining that the candidate token transfer transaction is legitimate, causing the candidate token transaction to be submitted to one or more nodes of the blockchain network.

[0227] Statement 3. The validation of the proposed token transfer transaction comprises: For each respective token minting transaction that is either referenced by a respective entry of the candidate token transfer transaction or included in a respective list of transactions, obtaining a digital certificate for each delegated entity, the delegated entity's digital certificate comprising a respective minting public key for each delegated entity that is 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 included in a digital certificate of each delegated entity.

[0228] Statement 4. The method of statement 3, wherein the validating the candidate token transfer transaction comprises verifying that the digital certificate of each respective delegated entity is a valid certificate.

[0229] Statement 5. The validation of the proposed token transfer transaction comprises: The method of any preceding statement, comprising verifying that the sum of the respective amounts of digital assets locked by the one or more respective outputs of the candidate transfer transaction is equal to the sum of the respective amounts of digital assets locked by the one or more respective outputs referenced by the one or more respective inputs of the candidate token transfer transaction and a transaction fee to be collected by the blockchain node to cause the candidate token transfer transaction to be recorded on the blockchain.

[0230] Statement 6. The method of any preceding statement, wherein said validating the candidate token transfer transaction comprises validating each transaction tracing back to each token minting transaction that connects the candidate token transfer transaction to the respective token minting transaction.

[0231] Statement 7. The method of Statement 2 or any statement dependent thereon, wherein the step of causing the candidate token transaction to be submitted to one or more nodes of the blockchain network comprises the step of transmitting the candidate token movement transaction to a third party via a first connection, and the third party is configured to submit the candidate token transaction to one or more nodes of the blockchain network via a second connection, wherein the first connection and the second connection are distinct.

[0232] Statement 8. The method of statement 7, wherein the first connection comprises a wireless connection.

[0233] Statement 9. The method of statement 8, wherein the wireless connection comprises a cellular connection, e.g., GPRS.

[0234] Statement 10. The method of statement 8, wherein the wireless connection comprises a Bluetooth connection or a near field communication (NFC) connection.

[0235] Statement 11. The method of any of statements 7 through 10, wherein the second connection comprises an Internet connection.

[0236] Statement 12. A computer-implemented method of implementing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of digital assets, comprising a respective locking script locked to a respective public key of the respective party, and comprising a respective token amount, the method being performed by a first party; sending a candidate token transfer transaction to a second party, the candidate token transfer transaction comprising: i) one or more respective inputs, each of which is signed by the first party and references a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transaction comprising a respective input signed by a respective delegated entity, and each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each of which locks a respective amount of digital assets, each of which comprises 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 sum of the respective token amounts included in the one or more referenced respective outputs; and sending to the second party, for each respective input referencing the respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction linking the candidate token transfer transaction with the respective token minting transaction.

[0237] Statement 13. The method of statement 12, wherein said transmitting a respective list of transactions comprises transmitting each transaction in the respective list.

[0238] Statement 14. 14. The method of statement 12 or statement 13, comprising, for each respective token minting transaction that is either referenced by a respective input of the candidate token transfer transaction or included in a respective list of transactions, sending to the second party a digital certificate of the respective delegated entity, wherein the delegated entity's digital certificate comprises a respective minting public key of the respective delegated entity used to sign the respective input of the respective token minting transaction.

[0239] Statement 15. a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 14.

[0240] Statement 16. 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 to 14.

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

[0242] According to another aspect disclosed herein, a system may be provided that includes computing devices of a first party and a second party. [Explanation of symbols]

[0243] 100 systems 101 Internet, packet-switched networks 102 Computer terminals, equipment, computer equipment 102a Computer equipment and devices 102b Computer equipment and devices 103 Users and related parties 103a User, first participant, Alice 103b User or Entity, User or Agent, Second Party, Bob 103c Charlie 103d Dave 103e Erin 103f Frank 103m Mallory 104 Blockchain nodes, Bitcoin nodes, nodes 105 Client Applications, Software 106 Peer-to-peer (P2P) network, decentralized network or blockchain network, network, Bitcoin network 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151, 151n blocks 152, 152i, 152j transactions 153 Genesis Block 154 Sets, Pools, and Transactions 155 Block Pointer 201 Header 202 Input, input field 203 Outputs, Output Fields, Transaction Outputs, UTXO 301 Side Channel, Token Issuer, Issuer 302 Delegated Entity 400 System 401 Movers, First Party, Alice, User Wallet, Payer, User 402 Transferee, Second Party, Bob, Payee, User 600 System 800 System 801 Trusted Third Parties 901 Enforcer Entity 902 Settlement Entities 903a Vendor 1 903b Vendor 2 903c Vendor 3

Claims

1. 1. A computer-implemented method for validating token transfer transactions as part of a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of digital assets, comprising a respective locking script locked to a respective public key of the respective party, and comprising a respective token amount, wherein the method is performed by a second party; obtaining a candidate token transfer transaction from a first party, the candidate token transfer transaction comprising: i) one or more respective inputs, each respective input signed by the first party and referencing a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transactions comprising a respective input signed by a respective delegated entity, each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each respective output locking the digital asset for a respective amount, each respective output comprising a respective locking script locked to a respective public key of a respective party and a respective token amount, wherein a sum of the respective token amounts included in the respective outputs equals a sum of the respective token amounts included in the one or more referenced respective outputs; obtaining from the first party, for each respective input referencing a respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction that connects the candidate token transfer transaction to the respective token minting transaction; validating the candidate token transfer transaction, wherein the validating the candidate token transfer transaction comprises: verifying that a respective entry of each of the candidate token transfer transactions references a respective token minting transaction or can be traced back to a respective token minting transaction using the respective list of transactions; verifying that the sum of the respective token amounts included in the respective outputs of the candidate mobile transaction is equal to the sum of the respective token amounts included in the one or more respective outputs referenced by the candidate mobile transaction; A method comprising:

2. 10. The method of claim 1, further comprising: if determining that the candidate token transfer transaction is legitimate, causing the candidate token transaction to be submitted to one or more nodes of a blockchain network.

3. the validity of the candidate token transfer transaction is verified by: For each respective token minting transaction that is either referenced by a respective entry of the candidate token transfer transaction or included in the respective list of transactions, obtaining a digital certificate of each delegated entity, the delegated entity's digital certificate comprising the respective minting public key of the each delegated entity used to sign the respective input of the respective token minting transaction; and verifying that each of the signatures used to sign the respective inputs of the respective token minting transactions corresponds to a respective minting public key included in a digital certificate of a respective delegated entity.

4. 4. The method of claim 3, wherein the validating the candidate token transfer transaction comprises verifying that a digital certificate of each respective delegated entity is a valid certificate.

5. the validity of the candidate token transfer transaction is verified by:

5. The method of claim 1, comprising verifying that a sum of the respective amounts of the digital assets locked by the one or more respective outputs of the candidate transfer transaction is equal to a sum of a respective amount of the digital assets locked by one or more respective outputs referenced by the one or more respective inputs of the candidate token transfer transaction and a transaction fee to be collected by a blockchain node to cause the candidate token transfer transaction to be recorded on the blockchain.

6. 6. The method of claim 1, wherein the validating the candidate token transfer transaction comprises validating each transaction tracing back to each token minting transaction that connects the candidate token transfer transaction to the respective token minting transaction.

7. 10. The method of claim 2 or any claim dependent thereon, wherein the step of causing the candidate token transaction to be submitted to one or more nodes of a blockchain network comprises the step of transmitting the candidate token transfer transaction to a third party via a first connection, the third party being configured to submit the candidate token transaction to the one or more nodes of the blockchain network via a second connection, the first connection and the second connection being different.

8. The method of claim 7 , wherein the first connection comprises a wireless connection.

9. The method of claim 8 , wherein the wireless connection comprises a cellular connection.

10. The method of claim 8 , wherein the wireless connection comprises a Bluetooth connection or a near field communication (NFC) connection.

11. 11. The method of claim 7, wherein the second connection comprises an internet connection.

12. 1. A computer-implemented method for implementing a token protocol using a blockchain, wherein each token transfer transaction requires an input signed by a respective party and one or more respective outputs, each respective output locking a respective amount of digital assets, comprising a respective locking script locked to a respective public key of each party, and comprising a respective token amount, the method being performed by a first party; sending a candidate token transfer transaction to a second party, the candidate token transfer transaction comprising: i) one or more respective inputs, each of which is signed by the first party and references a respective output of a respective token transfer transaction or a respective token minting transaction, the respective token minting transactions comprising a respective input signed by a respective delegated entity, each referenced respective output comprising a respective token amount; and ii) one or more respective outputs, each of which locks the digital asset for a respective amount, each of which comprises 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 sum of the respective token amounts included in the one or more referenced respective outputs; and sending to the second party, for each respective input referencing a respective token transfer transaction, a respective list of transactions tracing back to the respective token minting transaction linking the candidate token transfer transaction with the respective token minting transaction.

13. 13. The method of claim 12, wherein the transmitting the respective lists of transactions comprises transmitting each transaction in the respective lists.

14. 14. The method of claim 12 or 13, comprising, for each respective token minting transaction that is either referenced by a respective input of the candidate token transfer transaction or included in the respective list of transactions, sending to the second party a digital certificate of a respective delegated entity, wherein the delegated entity's digital certificate comprises a respective minting public key of the respective delegated entity used to sign the respective input of the respective token minting transaction.

15. a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 14.

16. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 14 when executed on one or more processors.

Images