Method for implementing digital coin system using block chain

Abstract

To address vulnerabilities of a digital coin system.SOLUTION: Provided is a method to be executed by a computer for implementing a system for issuing digital coins using a block chain. Each digital coin is issued by an issuer and represents an amount of assets redeemable by a redeeming party in exchange for the digital coin. The issuer maintains a record of coin serial numbers, each coin serial number representing a respective digital coin. The method is executed by the issuer and comprises the steps of: obtaining a spending transaction comprising a first coin serial number out of a set of coin serial numbers; determining whether the first coin serial number is present in a database; and in response to one or more conditions being met, transferring the amount of assets represented by the first coin serial number to the redeeming party. A first condition of the one or more conditions is that the first coin serial number is not present in the database.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a method for implementing a digital coin system for issuing digital coins using a blockchain. [Background technology]

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

[0003] Transactions in a blockchain are used to carry digital assets, i.e., a number of digital tokens. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storing additional user data in the output of a transaction. Recent blockchains have increased the maximum amount of data that can be stored in a single transaction, allowing for the incorporation of more complex data. For example, this can be used to store electronic documents or even audio or video data on the blockchain.

[0004] Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions across the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store a unique copy of mined blocks in the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes in the network for propagation. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Transactions that are not valid are not propagated or mined into a block. Assuming the transaction's validity is confirmed and thereby accepted into the blockchain, the transaction (including any user data) therefore remains stored as an immutable public record at each of the nodes in the P2P network.

[0005] Miners who successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital assets. Proof-of-work incentivizes miners not to cheat the system by including double-spend transactions in their blocks, because mining a block requires a large amount of computational resources and blocks containing double-spend attempts are unlikely to be accepted by other nodes.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element, sometimes called a UTXO (“Unspent Transaction Output”), that specifies the amount of a digital asset. The output may further comprise a locking script that specifies the conditions for redeeming the output. Each input comprises a pointer 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, called a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output that specifies the amount of a digital asset and it comprises a locking script that defines one or more conditions for unlocking that output. The second, target transaction comprises at least one input that comprises a pointer to the output of the first transaction and comprises 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 P2P 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 deems the target transaction invalid according to any of these conditions will neither disseminate the transaction nor include it in its mining into a block to be recorded in the blockchain. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] "Blind signatures for untraceable payments", Advances in cryptology, pp. 199-203, 1983. [Non-patent document 2] Y. Dodis and A. Yampolskiy, "A verifiable random function with short proofs and keys," International Workshop on Public Key Cryptography, 2005. [Non-patent document 3] J. Camenisch, S. Hohenberger, and A. Lysyanskaya, "Compact e-cash," Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2005. Summary of the Invention [Problem to be solved by the invention]

[0009] Electronic cash (ecash) was first invented in 1983 (D. Chaum, "Blind signatures for untraceable payments", Advances in cryptology, pp. 199-203, 1983), and since then there have been many further implementations, none of which have been able to replicate the fiat currency system. Note that ecash, in its traditional form, does not utilize blockchain. [Means for solving the problem]

[0010] One of the biggest problems with ecash systems (and digital coin systems in general) is that they are vulnerable to "double spend", meaning that it is very easy to duplicate the same ecash (or digital coin) and spend it again. This has prevented any system to date from gaining widespread adoption.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for implementing a system for issuing digital coins using blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin represents an amount of an asset redeemable by a redeemer in exchange for the digital coin, the issuer maintains a record of coin serial numbers, each coin serial number representing a respective digital coin, the method being performed by the issuer and comprising: obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising a first coin serial number from a set of coin serial numbers; determining whether the first coin serial number exists in a database of spent coin serial numbers; and transferring the amount of the asset represented by the first coin serial number to the redeemer in response to one or more conditions being satisfied, wherein a first condition of the one or more conditions is that the first coin serial number does not exist in the database.

[0012] The issuer maintains a list of coin serial numbers associated with spent digital coins. The issuer may receive spend transactions directly from redeemers, from the blockchain, or from another source. If the first coin serial number exists in the database, the corresponding digital coin has been previously spent, and the consumer or redeemer is attempting to double-spend the coin. The issuer rejects the digital coin. On the other hand, if the first coin serial number does not exist in the database, the associated digital coin has not been previously spent, and the issuer may accept the coin, which may also be contingent on some other criteria being met.

[0013] According to another aspect disclosed herein, there is provided a computer-implemented method for implementing a system for issuing digital coins using blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin representing an amount of an asset redeemable by a redeemer in exchange for the digital coin, the method being executed by the consumer and comprising: obtaining a withdrawal transaction, the withdrawal transaction having one or more outputs, each output comprising a hash of a respective one of a set of coin serial numbers, each coin serial number representing a respective digital coin; and transmitting the withdrawal transaction to the redeemer, a third party, and / or the blockchain network to be recorded on the blockchain.

[0014] Including a hash of the coin serial number in the output of a withdrawal transaction means that the serial coin number itself must be revealed in any transaction attempting to unlock the output, thereby forcing the coin serial number to be revealed by the consumer. The revealed coin serial number can be used to identify previously spent digital coins and thus prevent double-spending of digital coins.

[0015] The withdrawal transaction also serves as a record that a consumer has been issued a collection of digital coins, each with a unique serial number. Because the withdrawal transaction may be issued by the issuer to the consumer, it may enable the issuer to trace the origin of the spent coins back to the consumer. Alternatively, the consumer may generate the withdrawal transaction.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued to a consumer by an issuer, and each digital coin represents an amount of an asset redeemable by a redeemer in exchange for the digital coin, the method being executed by the redeemer and comprising the steps of: obtaining a first coin serial number from the consumer; determining whether the first coin serial number exists on the blockchain; and, in response to one or more conditions being satisfied, obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising the first coin serial number; and transmitting the spend transaction to one or more of the consumer, the issuer, a third party, and / or the blockchain network to be recorded on the blockchain, wherein a first condition of the one or more conditions is that the first coin serial number does not exist on the blockchain.

[0017] The redeemer checks whether the first coin serial number exists on the blockchain. As mentioned above, if the first coin serial number exists on the blockchain, it means that the consumer has previously spent the associated digital coin. If the first coin serial number does not exist on the blockchain, the redeemer can be sure that the associated digital coin has not been spent.

[0018] The present invention provides a system for implementing a digital coin system (e.g., an ecash system) on a blockchain. Advantageously, the security of the digital coin system is enhanced by utilizing the properties of the blockchain. Specifically, two fundamental properties of the blockchain improve the double-spend security of the proposed system compared to previous systems. The first property utilized is that transaction outputs have a binary state: spent or unspent. If an output represents a coin, the coin is only accepted in the system's spend and deposit protocol (described below) if the corresponding output has not been spent. This property is used to prevent double-spends. The second property utilized is the fact that the blockchain is a distributed, immutable database. The blockchain can be used to store coin serial numbers that have been spent and blacklisted, which anyone can access if necessary.

[0019] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0020] [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 schematic block diagram of another system for implementing a blockchain. [Figure 4A] FIG. 2 is a schematic block diagram of a client application. [Figure 4B] FIG. 1 is a schematic block diagram of some node software for processing transactions. [Figure 5]1 is a schematic block diagram of an exemplary system for implementing an electronic cash protocol. [Figure 6] FIG. 1 is a schematic block diagram of an exemplary system for implementing a digital coin system, in accordance with an embodiment of the present invention. [Figure 7a] FIG. 2 is a schematic diagram illustrating an exemplary withdrawal transaction and corresponding data. [Figure 7b] FIG. 2 is a schematic diagram illustrating an exemplary withdrawal transaction and corresponding data. [Figure 8a] FIG. 2 is a diagram illustrating an example consumption transaction and corresponding data. [Figure 8b] FIG. 2 is a diagram illustrating an example consumption transaction and corresponding data. [Figure 9a] FIG. 2 is a schematic diagram illustrating an exemplary deposit transaction and corresponding data. [Figure 9b] FIG. 2 is a schematic diagram illustrating an exemplary deposit transaction and corresponding data. [Figure 10a] FIG. 10 is a schematic diagram illustrating another exemplary withdrawal transaction and corresponding data. [Figure 10b] FIG. 10 is a schematic diagram illustrating another exemplary withdrawal transaction and corresponding data. [Figure 11a] FIG. 10 is a schematic diagram illustrating another exemplary consumption transaction and corresponding data. [Figure 11b] FIG. 10 is a schematic diagram illustrating another exemplary consumption transaction and corresponding data. [Figure 12a] FIG. 2 is a schematic diagram illustrating another exemplary deposit transaction and corresponding data. [Figure 12b] FIG. 2 is a schematic diagram illustrating another exemplary deposit transaction and corresponding data. [Figure 13a] FIG. 2 illustrates a schematic diagram of an exemplary withdrawal transaction. [Figure 13b] FIG. 2 is a diagram illustrating an example consumption transaction. [Figure 13c]FIG. 2 is a schematic diagram illustrating an exemplary deposit transaction. [Figure 14a] FIG. 10 is a schematic diagram of a first example of data for insertion into a withdrawal transaction. [Figure 14b] FIG. 2 shows a schematic diagram of a first example of data for insertion into a consume transaction. [Figure 14c] FIG. 2 is a diagram illustrating a first example of data for insertion into a deposit transaction. [Figure 15a] FIG. 10 is a schematic diagram of a second example of data for insertion into a withdrawal transaction. [Figure 15b] FIG. 10 is a diagram illustrating a second example of data for insertion into a consume transaction. [Figure 15c] FIG. 10 is a schematic diagram illustrating a second example of data for insertion into a deposit transaction. [Figure 16a] FIG. 10 is a schematic diagram of a third example of data for insertion into a withdrawal transaction. [Figure 16b] FIG. 10 is a diagram illustrating a third example of data for insertion into a consume transaction. [Figure 16c] FIG. 10 is a schematic diagram illustrating a third example of data for insertion into a deposit transaction. [Figure 17a] FIG. 10 is a schematic diagram of a fourth example of data for insertion into a withdrawal transaction. [Figure 17b] FIG. 10 is a diagram illustrating a fourth example of data for insertion into a consume transaction. [Figure 17c] FIG. 10 is a schematic diagram illustrating a fourth example of data for insertion into a deposit transaction. [Figure 18a] FIG. 10 is a schematic diagram of a fifth example of data for insertion into a withdrawal transaction. [Figure 18b] FIG. 10 is a diagram illustrating a fifth example of data for insertion into a consume transaction. [Figure 18c] FIG. 10 is a schematic diagram illustrating a fifth example of data for insertion into a deposit transaction. [Figure 19a] FIG. 10 is a schematic diagram of a sixth example of data for insertion into a withdrawal transaction. [Figure 19b] FIG. 10 is a diagram illustrating a sixth example of data for insertion into a consume transaction. [Figure 19c] FIG. 10 is a schematic diagram illustrating a sixth example of data for insertion into a deposit transaction. [Figure 20a] FIG. 10 is a schematic diagram of a seventh example of data for insertion into a withdrawal transaction. [Figure 20b] FIG. 10 is a diagram schematically illustrating a seventh example of data for insertion into a consume transaction. [Figure 20c] FIG. 10 is a schematic diagram illustrating a seventh example of data for insertion into a deposit transaction. DETAILED DESCRIPTION OF THE INVENTION

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

[0022] The blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain 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 typically 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 an amount representing the amount of digital assets belonging to the user 103 to whom the output is cryptographically locked (requiring that user's signature to be unlocked and thereby redeemed or spent). Each input points to the output of a previous transaction 152, thereby linking multiple transactions together.

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

[0024] For a given current transaction 152j, its (or each) input comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "spent" in the current transaction 152j. In general, a preceding transaction can be any transaction in the pool 154 or any block 151. A preceding transaction 152i need not necessarily exist when the current transaction 152j is created or even transmitted to the network 106, but a preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to a predecessor in the logical order linked by a pointer, not necessarily to the time of creation or transmission in the chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an ancestor transaction or a preceding transaction.

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

[0026] The above is sometimes called an "output-based" transaction protocol, and sometimes called an unspent transaction protocol (UTXO) type protocol (where the outputs are called UTXOs). A user's total balance is not defined by any single number stored on the blockchain; instead, the user needs a special "wallet" application 105 to reconcile the value of all of the user's UTXOs scattered across many different transactions 152 on the blockchain 151.

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

[0028] In either type of transaction protocol, when a user 103 wants to define a new transaction 152j, the user sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is usually a server or a data center, but could in principle be another user terminal). These nodes 104 verify whether the transaction is valid according to a node protocol applied at each of the nodes 104. The details of the node protocols correspond to the type of transaction protocol used in the blockchain 150 in question, which together form the overall transaction model. The node protocol typically requires the 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 the output-based case, this may comprise verifying that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction consumes; this condition typically comprises at least verifying that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, this condition may be defined at least in part by custom script included in the input and / or output. Alternatively, it may be determined solely by the node protocol, or a combination thereof. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F according to the same node protocol and applying the same tests, and therefore 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 nodes 104.

[0029] In the output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it has not yet been validly redeemed by the input of another forward transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that the transaction attempts to consume or redeem has not yet been consumed / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double spending, such as when a consumer attempts to consume the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining an account balance. Again, because transactions have a defined order, an account balance has a single defined state at any one time.

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

[0031] The first miner node 104M attempting to solve the puzzle will announce it to the network 106, providing the solution as a proof that can later be easily verified by other 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 pool of transactions 154 from which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150, based on verification of the winner's announced solution at each such node, at least some of which function as storage nodes 104S. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 in the chain. Proof-of-work helps reduce the risk of double spends because it takes a large amount of effort to create a new block 151, and mining nodes 104M are incentivized not to allow double spends to be included in their blocks because any block containing double spends may be rejected by other nodes 104. Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

[0032] Note that different miners 104M competing to solve the puzzle at any given time may do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue competing to create blocks from the newly defined prominent pool 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two miners 104M solve the puzzle within a very short time of each other, thereby prevailing inconsistent views of the blockchain. In other words, the fork with the longest tines becomes the final blockchain 150.

[0033] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new quantity of digital assets out of thin air (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a quantity of digital assets. This special type of transaction is sometimes called a "producing" transaction; it automatically forms part of a new block 151n. This reward motivates miners 104M to participate in the proof-of-work competition. To further reward the winning miner 104M for creating the block 151n in which the transaction was included, regular (non-producing) transactions 152 often also specify an additional transaction fee in one of their outputs.

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

[0035] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its role and handle transactions 152 according to the node protocol. It will be understood that any actions attributed to a 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. Additionally, the term "blockchain" as used herein is a generic term that refers generally to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

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

[0037] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. 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 on the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing unit. It will be understood that any actions attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

[0039] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to enable each user party 103 to create, sign, and send transactions 152 to be disseminated across the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that the party currently owns. In an output-based system, this second function comprises matching the amount defined in the output to the various transactions 152 scattered across the blockchain 150 that belong to the party in question.

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

[0041] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or to actually investigate other parties' transactions in the blockchain 150, since, in embodiments, the blockchain 150 is an official authority that lends credibility to transactions in part by making them publicly visible). The wallet functionality on each computing device 102 is configured to organize and transmit transactions 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of the transactions 152 according to the node protocol and, in the case of a forwarding node 104F, forward the transactions 152 for dissemination throughout the network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol accompanies a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow for different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although the same node protocol may handle different subtypes of transactions differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0042] As mentioned, the blockchain 150 comprises a chain of blocks 151, each of which comprises a set of one or more transactions 152 created by the proof-of-work process as previously discussed. Each block 151 also comprises a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. The blockchain 150 also comprises a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the creation transaction) comprises a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 stretches back to the 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.

[0043] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F that is closest to or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, that node handles the transaction according to its node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets some conditions for being “valid,” examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be an inherent feature of the node protocol or may be defined by a combination of the script and the node protocol.

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

[0045] Once miner nodes 104M are entered into pool 154 in the copy of blockchain 150 maintained in one or more storage nodes 104, they begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152. (Other miners 104M may still be trying to solve the puzzle based on their old view of pool 154, but whoever gets there first defines where the next new block 151 ends and where the new pool 154 begins, and eventually someone solves the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once the proof-of-work is done for pool 154 that contains new transaction 152j, the transaction immutably becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152 has a pointer to an earlier transaction, the order of transactions is also immutably recorded.

[0046] Because different nodes 104 may initially receive different instances of a given transaction, they may have conflicting views about which instance is "legitimate" before an instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only legitimate instance. If a node 104 accepts one instance as legitimate and discovers that a second instance is stored in blockchain 150, it must accept it and discard (i.e., treat as not legitimate) the un-mined instance that it originally accepted.

[0047] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to limit all possible embodiments.

[0048] In the 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 of input 202 for 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 the UTXO 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 miner 104M.

[0049] For example, suppose Alice 103a wishes to create transaction 152j to transfer a target amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. In FIG. 2, the preceding transaction 152i is labeled "Tx0." Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151, nor that Tx1 is the immediate next transaction in the pool 154. Tx1 may refer to any preceding (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0050] The predecessor transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence (e.g., which transaction points to which other transaction), as defined by transaction pointers specified in the 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 node 104. Nevertheless, subsequent transactions (descendant transactions or "children") that point to a preceding transaction (ancestor transaction or "parent") are not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. An orphan node may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or minor behavior.

[0051] 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 the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition that typically comprises 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.

[0052] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A 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 output of a transaction. An unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the input 202 of a transaction.

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

[0054] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script satisfies the conditions defined in the locking script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" means putting data on the stack, and "[...]" is a function contained in the unlocking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a generic stack. Either way, when executed together, the scripts will verify that the locking script in the input of Tx1 contains Alice's signature signing the expected portion of the data, using Alice's public key P as contained in the locking script in the output of Tx0. A To perform this authentication, the expected portion of the data itself (the "message") must also be included in Tx0. In an embodiment, the signed data comprises the entirety of Tx0 (so a separate element specifying the signed portion of the data in plaintext need not be included, since that signed portion is already present).

[0055] The details of authentication via public-private key cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then, given Alice's public key and the plaintext message (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature onto the plaintext version of the message, 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 the transaction.

[0056] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If the node 104 is a mining node 104M, this means that the node 104 adds it to the pool of transactions 154 awaiting proof of work. If the node 104 is a forwarding node 104F, the node 104 forwards transaction Tx1 to one or more other nodes 104 in the network 106, so that transaction Tx1 is disseminated throughout the network. Once Tx1's validity is confirmed and included in the blockchain 150, this defines the UTXO0 from Tx0 as being consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. Tx1 is not valid if it attempts to consume an output that has already been consumed by another transaction 152, even if all other conditions are met. Therefore, node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (already formed a legal input into another legal transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transactions 152. In practice, a given node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what determines whether a UTXO is spent is whether node 104 has already formed a legal input into another legal transaction in blockchain 150.

[0057] 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 reason for it to be invalid in most transaction models. Therefore, such a transaction will not be propagated or mined into a block 151.

[0058] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. A UTXO cannot "leave behind" a portion of the amount defined in the UTXO with another portion spent. However, the amount from a UTXO can be divided among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 in Tx0 can be divided among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself or pay another party change in the second output of Tx1.

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

[0060] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere on 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 that defines a given party's 103 total balance stored anywhere on the blockchain 150. 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. It can do this by querying a copy of the blockchain 150 stored on a storage node 104S, for example, one of the storage nodes 104S closest to or best connected to each party's computer device 102.

[0061] Note that script code is often expressed diagrammatically (i.e., not in actual language). For example, A ]=OP_DUP OP_HASH160 <H(P A )>OP_EQUALVERIFY To mean OP_CHECKSIG, use [Checksig P A]. "OP_..." refers to a specific opcode in the Script language. OP_CHECKSIG (also called "Checking") is a Script opcode that accepts two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). Upon execution, any occurrences of the signature ("sig") are removed from the script, but additional requirements, such as a hash puzzle, remain for the transaction to be verified on the "sig" input. As another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that stores metadata within the transaction, thereby allowing the metadata to be immutably recorded on the blockchain 150. For example, the metadata may comprise a document that is desired to be stored on the blockchain.

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

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

[0064] Optional Side Channel FIG. 3 illustrates a further system 100 for implementing a blockchain 150. Except for the addition of additional communication capabilities, the system 100 is substantially the same as that described in connection with FIG. 1. The client applications on each of Alice's and Bob's computing devices 102a, 102b each include additional communication capabilities, namely, enabling Alice 103a to establish a separate side channel 301 with Bob 103b (at the urging of either party or a third party). The side channel 301 allows for the exchange of data separate from the P2P network. Such communication is sometimes referred to as “off-chain.” For example, it may be used to exchange a transaction 152 between Alice and Bob without the transaction being published on the P2P network 106 or entering the chain 150 until one of them chooses to broadcast the transaction 152 to the network 106. Additionally or alternatively, the side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0065] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 301, as referred to elsewhere herein, may comprise any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separate from the P2P overlay 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 301. Thus, it should be noted that when Alice and Bob are said to exchange certain information, data, etc. over the side channel 301, 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.

[0066] Client Software 4A shows an exemplary implementation of a client application 105 for implementing embodiments of the scheme disclosed herein. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the transaction-related functionality behind the client 105, e.g., to organize transactions 152, receive and / or send transactions and / or other data via side channels 301, and / or send transactions for dissemination through the P2P network 106, as will be discussed in more detail shortly in accordance with the scheme discussed above.

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

[0068] Note: While various functions herein are sometimes described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. When reference is made elsewhere herein to a single or given application 105, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

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

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

[0071] For example, the UI elements may comprise one or more user-selectable elements 411, which may be various on-screen buttons, various options in a menu, etc. User input means are adapted to allow a user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching an on-screen UI element or speaking the name of a desired option (note that the term “manual” as used herein is intended only to contrast with automatic and is not necessarily limited to using hands). The options allow a user (Alice) to generate transactions and send them to another user (Bob) and to generate signatures for the transactions according to the described embodiment.

[0072] Alternatively or additionally, the UI element may comprise one or more data entry fields 412 through which a user can enter data to be included in the generated transaction and / or a message to be signed. These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0073] Alternatively or additionally, the UI element may comprise one or more information elements 413 for outputting information to the user, which may for example be rendered on a screen or audibly.

[0074] It will be understood that the specific means of rendering the various UI elements, selecting options, and inputting data are not required. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 400 shown in FIG. 4B is only a schematic mockup and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0075] Preparation / Terminology Coin serial number A coin serial number is defined as a unique identifier for an issued digital coin (similar to the serial number on a banknote, for example). A coin serial number is represented by an integer calculated by the user using a pseudorandom function such that the probability of generating two equivalent serial numbers is minimized.

[0076] Blinded Coins A coin is blinded if its serial number is impractical to calculate by someone who does not know the inputs into the calculation that blinds the coin.

[0077] Unblinding the Coin A blinded coin can be unblinded by applying the inverse of the blinding function to the coin's blinded serial number.

[0078] Blind Signature A blind signature is one in which the signer does not know the message they are signing, i.e., they sign a "blinded message", so that the blind signature remains valid for the corresponding unblinded message.

[0079] Double consumption value This value can only identify user Alice if she double-spends the coin. That is, if Alice is acting legitimately, there is no computationally feasible way to identify her. On the other hand, if she double-spends a single coin, a double-spend formula can be used to identify her. Effectively, this means that if she double-spends, it is possible to compute her identity from the information revealed in each spend of the coin. The revealed information could be her bank account number, public key, or other value corresponding to her identity. The following example is given for context: In one exemplary system, in the event of a double-spend, the double-spender's bank account number u is revealed. The recipient of the coin (e.g., a merchant) obtains some preimage of the hash function, which is used to calculate the coin's serial number. The preimage given to the bank is

[0080]

number

[0081] where a is some constant chosen by Alice at the time of withdrawal, and u is the bit length l u is Alice's account number, J is her initial balance in her account, and i is a counter of the number of coins she has spent.

[0082]

number

[0083] Note that || is the XOR operation and || is concatenation. When Alice double spends, the bank has knowledge of both of these values, called the "double spend formula" or "double spend value," and these two terms are used interchangeably. So, once the bank has these values, they can remove the a in the second formula to find Alice's account number. This is done by applying the first value to the second value using the inverse operation of XOR, which is also a simple XOR,

[0084]

number

[0085] From this, the bank will take the first l of the results u By reading the bits, the bank knows Alice's account number and therefore her identity. Note that if she does not double-spend, the bank cannot derive her identity because it only knows one of the values above.

[0086] safe prime number A safe prime is a prime number p such that p' can also be written as p=2p'+1, with p' also being a prime number.

[0087] RSA modulus The RSA modulus is defined as n=p1·p2, where p1 and p2 are prime numbers.

[0088] Special RSA Modulus An RSA modulus n=p1·p2 is called "special" if p1=2p'1+1 and p2=2p'2+1 are safe primes.

[0089] Quadratic remainder group

[0090]

number

[0091] Assuming that, b 2 an element such that ≡a mod n

[0092]

number

[0093] If a exists, then a is called a quadratic residue modulo n. The set of these quadratic residues is

[0094]

number

[0095] If n is the RSA modulus, then b 2 It is computationally hard to calculate b given ≡a mod n. Note that if n is the RSA modulus, then the probability that a randomly chosen element is a quadratic residue is exactly 1 / 4.

[0096] Origin Given a group G of degree n, an element g∈G of the group is a generator if its repeated application using group operations yields the group G itself. This means that G= <g>where g is a generator. Groups that can be generated in this way are called "cyclic".

[0097] In what follows we introduce two groups that are cyclic and are relevant throughout the following sections.

[0098] The first group is denoted by G and is generated by elements g of prime order q. The Decisional Diffie-Hellman problem is considered hard, because g u This means that it is difficult to calculate u given . This group is used in deriving public-private key pairs in some of the example schemes, and is also used in the Dodis-Yampolskiy (DY) pseudorandom function described below. The DY function can be used to calculate coin serial numbers and double-spend formulas.

[0099] The second group consists of elements

[0100]

number

[0101] and has prime order q',

[0102]

number

[0103] The elements are quadratic residues modulo n, where n=p1p2 is the special RSA modulus.

[0104]

number

[0105] The common elements of

[0106]

number

[0107] This group can be used to commit secrets using Pedersen Commitment and is sometimes used in signature schemes used by banks.

[0108] Pedersen commitment

[0109]

number

[0110] ,

[0111]

number

[0112] and

[0113]

number

[0114] is a quadratic remainder modulo n, and of degree q'

[0115]

number

[0116] Assuming that the generator is positive integers x1,...,x m The Pedersen commitment for ∈[0,n) is

[0117]

number

[0118] where r is a randomly generated integer. i Note that is restricted to be less than the order of the group.

[0119] Camenisch-Lysyanskaya (CL) signature We can assume that a user wants to have l messages signed by a third party without sharing the explicit values of the messages. The list of messages is (x1,...,x l )∈(0,min(n,n')), where min(n,n') is the smaller of n and n', and n and n' are the groups

[0120]

number

[0121] and

[0122]

number

[0123] The signer of the message uses the public key (n, a1,..., a l , b, c),

[0124]

number

[0125] is the length of the message block to be signed,

[0126]

number

[0127] teeth

[0128]

number

[0129] where n is a special RSA modulus and the signer's private key is p1, which implies that only the signer knows the factorization of n=p1·p2. In addition,

[0130]

number

[0131] ,

[0132]

number

[0133] and

[0134]

number

[0135] and n' can be assumed to be some integer.

[0136] The committed values (x1,...,x l To obtain the CL signature for

[0137] 1. The user agrees to Pedersen commitments

[0138]

number

[0139] and

[0140]

number

[0141] Calculate

[0142]

number

[0143] and r' is a randomly generated integer.

[0144] 2. The user selects the values (x1,...,x l ) know,

[0145]

number

[0146] and A both have the same values x1,...,x l and finally, to prove to the signatory that they are within the correct range.

[0147] 3. The signer generates a random integer

[0148]

number

[0149] and choose a prime number q,

[0150]

number

[0151] Calculate.

[0152] 4. The signer then

[0153]

number

[0154] ,q) is sent to the user.

[0155] 5.

[0156]

number

[0157] Then, the message (x1,...,x l ) is (V,r,q).

[0158] An important feature of this signature is that only the signer knows the factorization, and therefore only the signer can efficiently compute the qth root of the element modulo n=p1p2.

[0159] DY pseudorandom function A pseudorandom function is a function whose output is deterministic but appears random. In Y. Dodis and A. Yampolskiy, "A verifiable random function with short proofs and keys," International Workshop on Public Key Cryptography, 2005, Dodis and Yampolskiy defined a pseudorandom function that can be utilized in various example systems described below. Given a generator g∈G of prime order p and seed s, Dodis and Yampolskiy define a pseudorandom function as

[0160]

number

[0161] This function will be called the DY pseudorandom function.

[0162] Zero-knowledge proofs of knowledge The general idea is that the prover provides the verifier with enough information to prove that they know a value, without explicitly revealing that value. There are various pre-defined ways to do this, depending on what you want to prove. Note that most often the verifier needs to provide input in the form of a challenge; otherwise, the verifier could simply pass the same proof to another party, pretending to know the hidden value. There are cases of non-bidirectional proof of knowledge, where the challenge is simply agreed upon in advance or has a standard format, for example, a hash of the verifier's identity, and a time and date stamp.

[0163] The following example provides a proof that an integer is within a range. This can be used to prove that a wallet's counter is still within the value of a withdrawn amount. The goal of this proof is to prove that Alice knows a counter value J, with each bit value as either 0 or 1, and that she can prove what the counter value is, without sharing its value.

[0164] 1-of-2 Proof of Secret Knowledge Suppose Alice wants to prove that she knows a 1-of-2 value. Let A∈Γ be the value x i Let us denote the set of index i for which we know a witness to Γ, and Γ is the set of possible sets that can be used to reconstruct the secret. In the following example, i=1,2.

[0165]

number

[0166] is the complement of A

[0167]

number

[0168] For example, Alice receives the input x i Run simulator S with

[0169]

number

[0170] ,c i ,

[0171]

number

[0172] ) These conversations are three rounds in the zero-knowledge proof of knowledge protocol, and c i is the issue submitted by Bob,

[0173]

number

[0174] is Alice's response. Then, for each i∈A, Alice receives the input x i Suppose you have evidence for

[0175]

number

[0176] Alice determines the value for i=1,2.

[0177]

number

[0178] to Bob.

[0179] 1. Bob randomly chooses an l-bit string str and sends it to Alice.

[0180] 2. Assignment c from Step 1 i The set of shares corresponding to

[0181]

number

[0182] Think about it.

[0183]

number

[0184] is Γ * is ineligible in

[0185]

number

[0186] corresponding to c i This means that Bob cannot reconstruct Alice's secret given the value of str. Therefore, Alice can refine these shares into a universal set of shares consistent with the string str without the risk that Bob will be able to compute the secret. Alice can then use the share(c i ) is equal to the share generated in the finishing process. i This is done by copying the bits of the share and padding with random bits if necessary. In step 1, S creates a

[0187]

number

[0188] and c i Final message to

[0189]

number

[0190] Finally, Alice generates the message c for i=1,2. i ,

[0191]

number

[0192] Send the set to Bob.

[0193] 3. Bob will be responsible for all conversations (

[0194]

number

[0195] ,c i ,

[0196]

number

[0197] ) leads to acceptance by the verifier in the corresponding zero-knowledge proof protocol as described in step 1, and the share(c i ) is consistent with the string s. He accepts only if these checks are met.

[0198] This proof of knowledge is used in the following proof.

[0199] If the committed integer J is in the range [0,2 l -1]

[0200] Let p be a large prime number, q|p-1, and g,h∈Z * p is the element of order q such that the discrete logarithm of h in base g is unknown.

[0201] 1. Alice uses the Pedersen Commitment scheme edCom(J;r)=h r g J Commit the integer J using

[0202] 2. She is J=J02 0 +J12 1 +…+J l-1 2 l-1 Then, Alice rewrites J as a binary representation such that Pedcom(J i ;r i ) to find these J i Calculate the Pedersen Commitment for ,i=0,...,l-1,

[0203]

number

[0204] is.

[0205] 3. She is PedCom(x i ;r i ) is either 0 or 1, we use PedCom(J i ;r i ) or the discrete logarithm of PedCom(J i ;r i ) / g by proving that she knows either the discrete logarithm of g or the discrete logarithm of g. This is done by proving knowledge of the discrete logarithm as explained below, and by proving knowledge of one of the two secrets as explained above.

[0206] 4. Finally, Bob i PedCom(J i ;r i ) = PedCom(J;r).

[0207] If these confirmations are verified, the proof holds.

[0208] Turn a secret proof of knowledge into a signature of knowledge on message m

[0209] We begin by assuming that Alice wants to turn a proof of secret knowledge into a signature of knowledge so that Bob can verify it. In what follows, f is a pseudorandom function that turns a string of any length into the range [0,n), where n is the RSA modulus. To sign a message m, Alice performs the following steps:

[0210] 1. Alice generates random numbers r1,...r τ ∈[0,n),

[0211]

number

[0212] Calculate.

[0213] 2. Alice calculates f(m,x1,...,x τ ), take the first kτ bits, and ij where 1≦i≦τ and 1≦j≦k. This is the value e ij Create a matrix of .

[0214] 3. Alice assigns v for j=1,...,k. j =f(ID A ,j) and calculate ID A is Alice's identity.

[0215] 4. She's next

[0216]

number

[0217] Calculate.

[0218] 5. Next, she writes, for i=1,...,τ

[0219]

number

[0220] Calculate.

[0221] 6. Finally, she has ID A , m, e ij and y i to Bob.

[0222] Bob verifies the signature in the following way:

[0223] 1. Bob assigns v for j=1,...,k j =f(ID A ,j) is calculated.

[0224] 2. Bob, for i=1,...,τ

[0225]

number

[0226] Calculate.

[0227] 3. Bob calculates f(m,z1,...z τ ) are the first kτ bits of e ij Verify that:

[0228] If this holds, the signature is correct.

[0229] Zero-knowledge proof of knowledge of discrete logarithms

[0230] g u To prove knowledge of u in G while keeping u secret, the following protocol can be followed: Let g, h∈G be publicly known elements of G. Let Alice know that g u If she wants to prove to Bob that she knows the correct u to compute , she does the following:

[0231] 1. Alice

[0232]

number

[0233] where r1, r2, and r3 are randomly generated secret integers, and send V and U to Bob.

[0234] 2. Bob chooses a challenge e, say e=hash(x), where x is some randomly chosen message, and sends this challenge e to Alice.

[0235] 3. Alice then l=r2+eu, m=r3+er1 and return these to Bob.

[0236] 4. Bob then g l h m =UV e Verify that:

[0237] When Bob finds that this equation holds, he knows that Alice knows the value of u.

[0238] Electronic Cash System Electronic cash (ecash) was first introduced by Chaum in 1983. It was a very simple system in which users could withdraw blinded coins from an issuer and spend unblinded coins at a merchant, which could then deposit the coins back to the issuer independently of the withdrawal. Since then, many ecash systems have been proposed to improve some aspect of this system, whether it be prevention of double-spending, coin divisibility, batch spending, coin storage efficiency, lost coin recovery, or other improvements that lead to offline ecash. In all ecash systems, the issuer provides a database service that stores previously spent coins to monitor for double-spending. Chaum's ecash is an online cash system, which means that the issuer of a coin must be online at the time of spending the coin. This is because, in order to accept the coin, the coin recipient must contact the issuer to check the issuer's database to see if the coin has yet to be spent. Offline ecash systems have some way to later derive the identity of the double-spender, allowing the coin to be deposited at a convenient time. In the following, the issuer of the coin will be referred to as the bank, but note that in general this can be any trusted third party.

[0239] All ecash systems involve the same basic protocol: setup, withdrawal, spending, and deposit. In the example below, Alice withdraws some ecash (digital coins) from her bank and wants to spend it at a merchant, who then deposits them back into her bank. This is shown in Figure 5.

[0240] set up In all ecash systems, there is an initial setup where Alice and the merchants in this scheme register their identities. This can involve either opening an account with a bank or setting up a public-private key pair and sharing the public key. Similarly, in all ecash systems, the bank must create a unique public-private key pair and publish the public key.

[0241] drawer In this step, Alice requests a wallet from the bank containing coins of a certain value. Alice initiates wallet issuance by providing the bank with the blinded coin serial numbers, or a wallet seed from which she derives the serial numbers. The bank then signs these blinded values so that Alice can prove to the merchant that she obtained the wallet correctly. The protocol for obtaining signatures for a wallet may involve Alice sending the blinded coin serial numbers to the bank, which then signs them and returns the signatures to Alice. Each ecash specifies which signature scheme to use. Alice then stores this signature as part of her wallet. The wallet format depends on the specific ecash system, but in general, it is a collection of values corresponding to the coin's serial number, the bank's signature on the coin, and, in the case of offline caching, some additional information that allows for tracking of double-spenders. At this point, only Alice has knowledge of the coins' serial numbers, so only she can spend them.

[0242] consumption To spend a coin, Alice provides the merchant with the coin's serial number, the signature by the bank, and, if the protocol includes it, the double-spend formula. Alice must prove to the merchant that the serial number, signature, and double-spend formula (if present) all have the correct format. In simpler protocols, this can be done by directly verifying that the bank's signature is correct, but in more complex cases, it involves a zero-knowledge proof of knowledge that the bank signed some hidden value. The verification process is described in more detail below for each protocol. If the coin verifies, the merchant accepts it.

[0243] Deposit With online ecash, the merchant immediately contacts the bank to deposit the coin. The bank then checks its database of spent coins to see if it has already been spent. If not, the bank accepts the coin and the merchant receives its value. If it has already been spent, the merchant rejects the payment. With offline ecash, the merchant can deposit the coin with the bank whenever needed, such as at the end of a business day. The bank then stores the serial number and any double-spend information. If the coin is double-spended, this additional double-spend information can be used to identify the culprit. Some protocols also allow for the remaining unspent coins to be calculated after a double-spend so they can be blacklisted.

[0244] Digital Coin System 6 illustrates an exemplary system 600 for implementing a digital cash system for issuing digital coins. The system 600 includes an issuer 601 (e.g., a bank or other trusted third party) responsible for issuing digital coins to consumers 602 (e.g., end user Alice 103a, or businesses, services, universities, charities, etc.). The system also includes a redeemer 603 (e.g., a merchant) that receives digital coins from consumers 602 and can deposit the digital coins with the issuer 601 and receive digital assets represented by the digital coins in return. For example, consumers 602 may provide digital coins to the redeemer 603 in exchange for services provided by the redeemer, and the redeemer can then redeem the digital coins at the issuer for traditional money (i.e., fiat currency) in the amount represented by the digital coins. The system 600 further includes a blockchain network 106. Each of the issuer 601, consumer 602, and redeemer 603 is configured to interact directly or indirectly with the blockchain 150, for example, to send transactions to the blockchain 150, to retrieve transactions from the blockchain 150, etc.

[0245] It should be noted that each of the issuer 601, consumer 602, and redeemer 603 may perform some or all of the functions attributed to Alice 103a and Bob 103b in relation to FIGS.

[0246] As shown in FIG. 6, an issuer 601 issues a withdrawal transaction Tx via, for example, a side channel 301. withdraw The withdrawal transaction Tx may be configured to send the withdrawal transaction Tx to the consumer 602. withdraw may also be transmitted to the blockchain network 106. The consumer 602 may send a consume transaction Tx via, for example, a side channel 301. spend to the redeemer 603. spend may also be transmitted to the blockchain network 106. The redeemer 603 may also transmit the deposit transaction Tx via, for example, a side channel 301. deposit to the issuer 601. deposit may also be sent to the blockchain network 106. Note that this is just one illustrative example of a transaction flow between the parties; other flows are possible and are discussed below.

[0247] For simplicity, embodiments of the present invention will be described in relation to a bank (issuer 601), a customer called Alice (consumer 602), and a merchant (redeemer 603). However, it will be understood that these are merely convenient designations for the parties involved and are not intended to be limiting.

[0248] set up Bank 601 and Alice 602 are configured to interact as part of a setup protocol. Alice 602 registers an identifier with Bank 601. The identifier may be a bank account number, a passport number, a driver's license, a name and address, etc. In some examples, the identifier may be a public key, for example, of a public-private key pair. Alice 602 may register her identifier as part of a know-your-customer (KYC) process. Alice 602, Bank 601, and Merchant 603 each have a public key, for example, an elliptic curve public key, suitable for use as part of the blockchain protocol. That is, the public key may be associated with a signature for use in signing blockchain transactions. Each public key may also form the basis of a respective address for use on the blockchain 150. In the following example, Alice 602 registers public key P A and the corresponding private key sk A and the bank 602 has a public key P B and the corresponding private key sk B The trader 603 has a public key P M and the corresponding private key sk M The public keys of each party may be known to each other. Alternatively, in some examples, Alice's public key P A may not be known to other parties, at least initially. Furthermore, unless the context requires otherwise, a reference to a party's public key may be interpreted as any public key for which that party possesses a private key. In other words, Alice 602 may use one public key to sign transactions and another public key as the basis for blockchain addresses. For example, Alice 602 may use two different public keys as part of the protocol, one of which is the known public key P A and one of them is its known public key, say P A ' is derived from.

[0249] Merchant 603 may go through a similar process to Alice 602 to register merchant 603's identifier.

[0250] drawer To withdraw one or more digital coins from the bank (i.e., for Bank 601 to issue digital coins to Alice 602), Alice 602 and Bank 601 must initiate a coinseed signing protocol. The coinseed s is a value (i.e., a number) known only to Alice 602. That is, Alice 602 generates the coinseed s and does not share it with Bank 601 or the merchant 603. The coinseed s may be generated by a pseudorandom number generator. Alice 602 sends the coinseed s to Bank 601 in the form of a blinded message so that Bank 601 cannot identify the coinseed. Bank 601 signs the blinded coinseed to generate a blind signature σ B (i.e., the signature on the blinded coin seed) to Alice 602. The bank 601 then returns the private key sk B The blinded coin seed may be signed using the same signature key as the original, or alternatively with a different signing key.

[0251] In some examples, the coin seed s may be based on input from Bank 601. That is, Bank 601 provides input r' to Alice 602. A coin seed is then generated based on the input s' from Alice and the input r' from the bank, e.g., s=s'+r'.

[0252] Alice 602 uses the coin seed to generate one or more coin serial numbers. Each coin serial number represents a single digital coin. Each digital coin represents a predetermined amount of digital assets, which may be set by bank 601. For example, each digital coin may represent £100 (this may be specified in the OP_RETURN output, or alternatively, it may be a predetermined agreement or protocol that all coins always represent £100). Alice 602 and bank 601 may agree that Alice can generate a certain set number of coin serial numbers. Bank 601 can then debit Alice's bank account based on an amount equal to the set number of coin serial numbers.

[0253] Alice 602 generates a first of multiple coin serial numbers (and in some examples, the only coin serial number) based on the coin seed. The first coin serial number may be generated by applying a pseudorandom function, such as a DY pseudorandom function, to the coin seed. Thus, the first coin serial number is tied to the coin seed but appears to be a random value.

[0254] A withdrawal transaction is then generated, which is a blockchain transaction that serves as evidence of the withdrawal of the digital coin, i.e., the digital coin corresponding to the first serial number. The party that generates the withdrawal transaction depends on whether the digital coin system is a traceable coin system or an untraceable coin system.

[0255] For traceable coin systems, withdrawal transactions are signed by the bank. B That is, the withdrawal transaction is signed by the bank 601. An exemplary traceable withdrawal transaction is shown in Figure 7a. The bank's signature Sig B is entered into the input of the withdrawal transaction (in this example, the bank's corresponding public key P B (along with)

[0256] The withdraw transaction also comprises a first output comprising a hash of the first coin serial number. Note that other alternative one-way functions may be used in place of the hash function. The first output comprises an output script that, when executed with the spend transaction input, is configured to require that a later transaction input include a preimage of the hash function (i.e., the first coin serial number itself) to unlock the first output. Optionally, as shown in the example of Figure 7a, the output script may also include Alice's public key P A and / or the bank's 601 public key P B For example, the first output may be a multi-signature output, i.e., to unlock the first output, the consuming input is Alice's public key P A The signature Sig corresponding to A and / or the bank's public key P B The signature Sig corresponding to B A second output may be included that returns the change to the bank 601.

[0257] In the example of Figure 7a, the withdrawal transaction comprises first data representing a first digital coin. The first data may be included in a spendable output or in a non-spendable output (e.g., an OP_RETURN output). An example of the first data is shown in Figure 7b. The first data may comprise one, some, or all of a prefix denoting the digital asset represented by the digital coin (e.g., currency), a coin protocol flag, a coin action flag (e.g., withdraw), and a balance of the digital coin.

[0258] In an untraceable coin system, withdrawal transactions are signed by Alice's signature, Sig A That is, the withdrawal transaction is signed by Alice 602. An exemplary untraceable withdrawal transaction is shown in Figure 10a. Alice's signature Sig A is used as the input for the withdrawal transaction (in this example, Alice's corresponding public key P A The untraceable withdrawal transaction comprises the same first output as described above with respect to the traceable withdrawal transaction. As described above, the untraceable withdrawal transaction may also comprise first data representing the first digital coin. An example of the first data is shown in Figure 10b.

[0259] If the bank signs the withdrawal transaction, Alice 602 sends a hash of the first coin serial number to Bank 601 to be included in the first output. Alternatively, Alice 602 may generate a transaction template that includes at least the first output, and Bank 601 may then add one or more of the inputs and outputs, if necessary. Bank 601 may then submit the withdrawal transaction to the blockchain network. Bank 601 may also send a copy of the withdrawal transaction to Alice 602.

[0260] If Alice 602 signs the withdrawal transaction, Alice 602 does not need to send the withdrawal transaction to Bank 601. Alice 602 simply submits the withdrawal transaction to the blockchain network.

[0261] Optionally, the withdrawal transaction may comprise more than one output comprising a hash of the coin serial number. For example, Alice 602 may generate a second coin serial number to represent a second digital coin. The first coin serial number may be a seed for the second serial number (i.e., the second coin serial number may be generated by applying a pseudorandom function to the first coin serial number), or the second coin serial number may be generated by directly applying a pseudorandom function to the coin seed. In these examples, the withdrawal transaction comprises a series of outputs similar to the first output except for different hash values. Each output may be associated with a respective data output, i.e., an output having data similar to the first data.

[0262] consumption To spend the first digital coin in a transaction (e.g., trade) with the merchant 603, Alice 602 provides the merchant 603 with the first coin serial number. The merchant 603 checks whether the first coin serial number is included in the transaction on the blockchain. Note that only a hash of the first coin serial number is included in the withdrawal transaction, not the first coin serial number itself. If the first coin serial number is included on the blockchain, the merchant 603 rejects the first digital coin and terminates the transaction. As discussed below, the first coin serial number may be included on the blockchain as part of Alice 602's spending of the first digital coin or as part of blacklisting the first digital coin by the bank 601. If the first coin serial number is not included on the blockchain, the merchant 603 may decide to accept the digital coin and proceed with the transaction.

[0263] The merchant 603 obtains the spend transaction in response to one or more conditions being satisfied. The one or more conditions include a condition that the first coin serial number does not exist on the blockchain. The spend transaction comprises the first coin serial number and serves as evidence that the merchant 603 accepted the digital coin represented by the first coin serial number. The merchant 603, in combination with, for example, Alice 602, may fully or partially generate the spend transaction. That is, one, some, or all of the inputs and / or outputs of the spend transaction may be generated by the merchant 603. Similarly, one, some, or all of the spend transaction inputs and / or outputs may be generated by Alice 602.

[0264] Figure 8a shows an example of a traceable spend transaction. A traceable spend transaction comprises a first coin serial number, thereby revealing the first coin serial number when the spend transaction is submitted to the blockchain network. In this example, the first coin serial number is included in the first input of the spend transaction. The first input of the spend transaction may reference the first output of the withdraw transaction, thus creating a chain of transactions. If required by the first output of the withdraw transaction, the first input may include Alice's signature, Sig A and / or the public key P A The consumption transaction may include a merchant signature, Sig M and / or the public key P M The second output may comprise the merchant's public key P M The transaction output may refer to a transaction output that is locked in the

[0265] If Alice 602 later wishes to spend another of her digital coins, the spend transaction may have a first output similar to the first output of the withdraw transaction, except that the hash value is a hash value of a different one of her coin serial numbers. The first output of the spend transaction may be locked to the respective public keys of Alice and / or the bank.

[0266] The spend transaction may comprise a second output that is locked to the public keys of each of Alice 602, the bank 601, and / or the merchant 603. A multi-signature output may be used to lock the output to a minimum of n public keys from the total set of public keys.

[0267] A spend transaction may comprise a third output comprising second data, e.g., a spendable or non-spendable output. Figure 8b shows an example of second data. In this example, the second data may include some or all of the items included in the first data of the withdrawal transaction discussed above. The second data may include the spent coin serial number (i.e., the first coin serial number) and Alice's remaining balance of digital coins. The second data may include additional items discussed below.

[0268] Figure 11a shows an example of an untraceable spend transaction. Like a traceable spend transaction, the untraceable spend transaction comprises a first coin serial number. In this example, the first coin serial number is included in the first input of the spend transaction. The first input of the spend transaction may reference the first output of the withdraw transaction, thus creating a chain of transactions. If required by the first output of the withdraw transaction, the first input may include Alice's signature, Sig A and / or the public key P A The consumption transaction may include a merchant signature, Sig M and / or the public key P M The second output may comprise the merchant's public key P M The transaction output may refer to a transaction output that is locked in the

[0269] The untraceable spend transaction may comprise a first output comprising a hash of second data representing the spent digital coins. This output may be signed by Alice, which serves as evidence that Alice 602 attested to spending the digital coins. The second data itself may be included in a different output of the transaction (the third output in FIG. 11a). The first output may be configured to require that a later transaction input include the second data itself. The second output of the spend transaction may be locked to the respective public keys of Alice 602, the bank 601, and / or the merchant 603.

[0270] The second data may be included in the consumable or non-consumable output. Figure 11b shows an example of the second data. As in the example of Figure 8b, the second data may include some or all of the items included in the first data of the withdrawal transaction discussed above. The second data may include the consumed coin serial number (i.e., the first coin serial number).

[0271] The merchant 603 receives the input (i.e., her signature Sig A Upon adding the inputs (including the inputs) and the output of the transaction, a spend transaction (traceable or untraceable) may be signed. The merchant 603 may then submit the spend transaction to the blockchain network or send it to Alice 602 for Alice 602 to submit it to the blockchain network. As another example, the merchant 603 may submit the spend transaction to a third party, which may be a service provider such as a wallet provider.

[0272] Optionally, Alice 602 may provide the withdrawal transaction to merchant 603, or the merchant may retrieve the withdrawal transaction from the blockchain, for example using a transaction identifier TxID provided by Alice 602. Merchant 603 may verify that the first input of the spend transaction unlocks, or at least references, the first output of the withdrawal transaction.

[0273] Deposit Once one or more conditions imposed by the merchant 603 are met and the merchant decides to accept the digital coins, e.g., as payment for goods or services, the merchant contacts the bank 601 to deposit the digital coins and redeem assets in the amount represented by the digital coins.

[0274] The merchant 603 transmits the first coin serial number to the bank 601. The merchant 603 may transmit the first coin serial number directly to the bank 601. Additionally or alternatively, the merchant 603 may provide the bank 601 with a spend transaction that includes the first coin serial number, or at least a transaction identifier TxID of the spend transaction. Alternatively, the bank 601 may provide the bank 601 with a public key P B When alerted about a transaction locked in the blockchain, they can retrieve the spend transaction directly from the blockchain.

[0275] Bank 601 checks whether the first coin serial number exists in a record of spent coin serial numbers maintained by bank 601. The coin serial number may be maintained in blockchain 150, i.e., recording the serial number on-chain with the transaction or in a separate database. If stored in a database, blockchain 150 may be scanned for the serial number, for example, when a coin flag appears on-chain. The database may also be stored in blockchain 150. If the first coin serial number exists in the database, the merchant 603's deposit of the digital coin is rejected because the digital coin represented by the first coin serial number has already been spent. If the first coin serial number does not exist in the database, bank 601 may accept the digital coin and transfer assets in the amount represented by the digital coin to merchant 603. One or more additional conditions may have to be met for bank 601 to transfer assets in the amount to merchant 603.

[0276] The merchant 603 obtains the deposit transaction. The merchant 603 may generate the deposit transaction entirely or in coordination with the bank 601. The deposit transaction comprises an input that references the output of the consume transaction, e.g., the second output. The deposit transaction includes the merchant's signature, Sig M and / or bank signature Sig B Merchant 603 may generate a deposit transaction and place it on the blockchain network, or merchant 603 may generate a deposit transaction and send it to bank 601 so that the bank can place it on the blockchain network or even to a third party such as a wallet provider. Alternatively, bank 601 may generate a deposit transaction and then place it on the blockchain or merchant 603.

[0277] Figure 9a shows an example of a traceable deposit transaction. In this example, the first input of the deposit transaction is signed by both the bank 601 and the merchant 603. That is, the first input is the bank's signature, Sig B and the merchant's signature (Sig) M The first input references the output of the spend transaction. In this example, the first input references the second output of the spend transaction, i.e., the multi-signature output.

[0278] The deposit transaction may comprise third data. An example of the third data is shown in FIG. 9b. The third data may comprise one or more data fields in common with the first and / or second data. The third data may comprise an indication of the value of the deposited coins. If Alice 602 is found to have attempted to double-spend digital coins and a deposit transaction is generated by bank 601, the third data may comprise the serial numbers of any remaining unspent digital coins issued to Alice 602.

[0279] FIG. 12a illustrates an example of an untraceable deposit transaction. Similar to the exemplary deposit transaction illustrated in FIG. 9a, the first input of the deposit transaction is signed by both the bank 601 and the merchant 603. The first input references an output of a spend transaction, e.g., the first output of the untraceable spend transaction. In this example, the first output of the untraceable spend transaction included a hash puzzle of the second data. In other words, the first output of the untraceable spend transaction included a script configured to require that the input of a subsequent transaction attempting to unlock the first output include a preimage of the format of the second data. Thus, the first output of the deposit transaction in this example includes the second data in raw format.

[0280] A deposit transaction may have one or more outputs. As shown in Figure 12a, a deposit transaction includes the public key P M The deposit transaction may comprise a first output locked to the deposit amount. The deposit transaction may comprise a second output comprising third data. Figure 12b shows an example of the third data.

[0281] Other optional conditions In some embodiments, one of the conditions that must be met for Bank 601 to accept the digital coin is that the spend transaction comprises an input that references and unlocks the output of a withdraw transaction, e.g., a withdraw transaction signed by Bank 601. Similarly, one of the conditions that must be met for Merchant 603 to accept the digital coin is that Alice 602 provides a withdraw transaction, or a reference to a withdraw transaction, that is signed by Bank 601.

[0282] In additional or alternative embodiments, one of the conditions that must be met for Bank 601 to accept the digital coin is that the spend transaction comprises inputs that are signed by Alice 602 and / or Bank 601. In some instances, both signatures must be present.

[0283] In some embodiments, Alice 602 may send the coin seed proof to the merchant 603. The coin seed proof includes a blind signature σ of the coin seed's bank. B In some examples, the coinseed proof may simply be the blind signature itself. In other examples, the coinseed proof may be a zero-knowledge proof. Zero-knowledge proofs are discussed above. Based on the coinseed proof, the merchant 603 can prove that Alice 602 has knowledge of the bank's signature σ on the coinseed. B One of the conditions for merchant 603 to accept the digital coin is that Alice 602 must have knowledge of signature σ B It may be that the coin seed proof proves that the person has knowledge of

[0284] In some embodiments, when merchant 603 seeks to deposit digital coins, she may send a coin seed proof to bank 601. Like merchant 603, bank 601 may determine based on the coin seed proof that Alice 602, and therefore merchant 603, possesses the bank's signature on the coin seed, σ B One of the conditions for bank 601 to accept the digital coin is that Alice 602 must have knowledge of signature σ B It may be that the coin seed proof proves that the person has knowledge of the

[0285] In some embodiments, Alice 602 may generate one or more double consumption seeds. Each double consumption seed may be used to generate a double consumption value. The double consumption values are described above. Alice 602 may send a blinded version of the one or more double consumption seeds to Bank 601, which may generate a blinded signature σ of the one or more double consumption seeds. B returns the signature σ of one or more double-spending seeds. B is the same signature σ of the coin seed B That is, the bank 601 may sign the coin seed and the double spend seed as a whole.

[0286] When spending digital coins at a merchant 603, Alice 602 may generate one or more respective dual spend values using a respective dual spend seed. Alice 602 transmits the dual spend values to the merchant 603, e.g., as part of a spending transaction. Each dual spend value is based on the dual spend seed, Alice's identifier (e.g., her bank account number, public key, passport number, etc.), and one of several data items selected by the merchant 603 and transmitted to Alice 602. The data item changes with each interaction between Alice 602 and the merchant 603. For example, the data item may be based on the time and / or date of the interaction, an invoice for goods or services purchased by Alice 602, or any other variable. Each dual spend value generated by Alice 602 reveals a different component of Alice's identifier, due to the different data items. If Alice 602 attempts to double-spend the same coin, enough information about her identity is revealed to allow her to be identified by the bank 601.

[0287] When the merchant 603 deposits the digital coin, the merchant 603 transmits the double spend value to the bank 601. If the bank 601 discovers that the first coin serial number is present in the record of spent coin serial numbers (i.e., in the blockchain 150), the bank 601 may use the double spend value together with a previously received double spend value, i.e., the double spend value received when the first digital coin was originally deposited, to reveal Alice's identity. If Alice 602 has any remaining unspent digital coins, the bank 601 may blacklist those coins. Examples of blacklisting coins are discussed below.

[0288] Alice 602 may send the double-spend seed proof to the merchant 603. The double-spend seed proof is a blind signature σ of the double-spend seed by Alice 602's bank. B In some instances, the double-spend seed proof is simply a blind signature σ B In another example, the double-spend seed proof can be a zero-knowledge proof. Zero-knowledge proofs are discussed above. Based on the double-spend seed proof, the merchant 603 can verify that Alice 602 has the bank's signature σ on the double-spend seed. B One of the conditions for merchant 603 to accept the digital coin is that Alice 602 must have knowledge of signature σ B In some embodiments, when merchant 603 seeks to deposit digital coins, bank 601 may transmit the double-spend seed proof to bank 601. Based on the double-spend seed proof, bank 601, like merchant 603, may determine that Alice 602, and therefore merchant 603, has knowledge of the bank's signature on the double-spend seed, σ B One of the conditions for bank 601 to accept the digital coin is that Alice 602 must have knowledge of signature σ B It may be that the double consumption seed proof proves that the user has knowledge of the

[0289] In some embodiments, Alice 602 generates a hash R of the merchant's identifier (e.g., public key P M ) and a data item chosen by the merchant 603. As discussed above, the data item may be based on an interaction between Alice 602 and the merchant 603, e.g., the date and / or time of the interaction. Alice 602 may send a hash R of the merchant's identifier to the merchant 603, e.g., as part of a spend transaction. One of the conditions for the merchant 603 to accept the digital coin may be that the merchant 603 agrees on the hash R of the merchant's identifier. When depositing the digital coin with bank 601, the merchant 603 may send the hash R of the merchant's identifier to bank 601. Bank 601 may maintain a record (either on-chain or off-chain) of received merchant identifier hashes (i.e., the hashes of each of the merchant's identifiers). One of the conditions for bank 601 to accept the digital coin may be that the most recently received merchant identifier hash does not appear in a record (e.g., on blockchain 150). If the merchant identifier hash appears in the database, it means that the merchant is attempting to double-spend the digital coin.

[0290] Example Transaction Figures 13a through 13c show exemplary generic withdrawal, spend, and deposit transactions, respectively, that may be used in any digital cash protocol. These exemplary transactions may be used for any protocol; the only part of the transaction that varies is the OP_RETURN data.

[0291] Figure 13a shows the generic withdrawal transaction. Alice 602 generates a signature σ on the coin's serial number. B from the bank 601. A withdrawal transaction is created to acknowledge that this transaction has taken place. The input for this transaction is from the bank 601 in a traceable protocol, or from Alice 602 in an untraceable protocol. The data is specified for each digital coin system.

[0292] Figure 13b shows a comprehensive spend transaction: Alice 602 receives a coin with the correct format and a signature σ for the coin from bank 601. B and proves to the merchant 603 that she has the coin. To signal that her spend has been accepted by the merchant 603, a spend transaction is created, where the input comes from the withdraw transaction. This transaction includes the coin's serial number and additional information that can identify her if she double-spends. If there is another coin to be spent if traceable, there is an additional output with the same format as the output of the withdraw transaction so that Alice 602 can spend the next coin. The data in OP_RETURN shall be specified for each digital coin system.

[0293] Figure 13c shows a generic deposit transaction. The merchant 603 provides proof to the bank 601 that the merchant has legitimately accepted the coin. A deposit transaction is created that consumes the output of the spend transaction and signals that the deposit has been accepted. This transaction is the same for both traceable and untraceable protocols. The data in OP_RETURN shall be specified for each digital coin system.

[0294] Exemplary Protocol Traceable Digital Coins The following describes an exemplary traceable protocol that utilizes blockchain to prevent double-spending. In the traceable protocol, digital coins are traceable due to the fact that each spend transaction is linked to a withdrawal transaction that is signed by Bank 601. This link results in it being easier to prove that coins were actually issued by Bank 601.

[0295] Alice 602 withdraws her wallet from Bank 601 and wishes to spend some of her digital coins at Merchant 603, who then deposits the coins into Bank 601. Bank 601 then receives a public / private key pair (pk B ,sk B ) in this protocol. Bank 601 can sign (i+3) messages simultaneously. Then, the bank's public key is (n, a1,..., a i+3 , b, c), and the private key is p1 such that n=p1p2 is a special RSA modulus. The following example protocol uses i=1, but it is easy to modify the protocol for larger i. This extensibility allows additional secrets to be committed and then revealed in the case of double-spend. In addition, Alice 602 and merchant 603 each have some

[0296]

number

[0297] (pk u ,sk u )=(g u ,u), where q is prime and g∈G as before. Eventually, every user also has a unique elliptic curve (EC) public / private key pair of the form (pk=sk·G,sk) so that they can receive and spend Bitcoin. Alice's key pair is (P A ,sk A ) and the bank's key pair is denoted as (P B ,sk B ) and finally, the merchant's key pair is given by (P M ,sk M )

[0298] Alice contacts bank 601 to check the value

[0299]

number

[0300] t) to the bank, which then signs this commitment and generates a signature σ B Returns the total value of the coin.

[0301]

number

[0302] will be debited from her account.

[0303]

number

[0304] To withdraw coins, the following steps are taken: In this protocol, Alice 602 knows the value of the coin's internal counter J by the zero-knowledge proof property.

[0305]

number

[0306] Only wallets containing coins can be withdrawn, j Note that is the length in bits of the counter.

[0307] Alice602 uses the zero-knowledge proof explained at the beginning to u Alice 602 identifies herself to the bank 601 by providing knowledge of s', t, t' ...

[0308]

number

[0309] Select Pedersen Commitment

[0310]

number

[0311] to Bank 601. Bank 601 chooses a random integer r' to contribute to the wallet and sends this to Alice 602. Both the bank and Alice independently

[0312]

number

[0313] Calculate.

[0314] This step is essentially creating a wallet secret and having Bank 601 contribute randomness to this step. Alice 602 and Bank 601 run the CL signature protocol to obtain the bank's signature on the value in Pedersen Commitment A, and generate signature σ B yields (u,s,t)=(V,r,e), where

[0315]

number

[0316] The method for computing this signature is given above in the preliminary section, where (x1, x2, x3) is (u, s, t).

[0317] Alice602 has a wallet W=(u,s,t,σ B (u,s,t),J) is saved and J is initialized to 0. j 602, the wallet seed and wallet counter are bit counters. Note that since the signature by bank 601 is only on the wallet seeds s and t, the serial number and double spend formula do not necessarily need to be stored in the wallet, but can instead be derived when needed using the wallet seed and wallet counter. Bank 601 then

[0318]

number

[0319] Withdraw coins.

[0320] The wallet is W=(u,s,t,σ B (u,s,t),J) where u is Alice's private key, s is the coin serial number seed, ·t is a double-consumption seed, σ B (u,s,t) is the signature of the bank on these values, ·J is the wallet counter.

[0321] Additionally, the wallet may contain additional variables that are used to reveal further secrets if Alice 602 double-spends. The additional variables are (z1,...,z l ), where l is the number of additional secrets we wish to reveal. Note that l∈[0,n-3) and the group of CL signature schemes is modulo n and ranges up to n-3, since there are already three values to sign in the Camenish, Hohenberger, and Lysyanskaya (CHL) protocol described in J. Camenisch, S. Hohenberger, and A. Lysyanskaya, "Compact e-cash," Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2005 (see below for further details). Bank 601 signs these new variables with the secrets of other wallets, so the wallets W=(u,s,t,(z1,...,z l ),σ B (u,s,t,(z1,...,z l )),J) becomes.

[0322] These additional wallet secrets are computed using l double-spend formulas Z1, ..., Z in exactly the same way that t is used to compute T in CHL. l can be used to calculate

[0323] Wallet seeds in CHL are s=s'+r' where Alice602 randomly chooses s' and the bank gives r'. s' is derived from another random variable in the following way: s':=hash(g s'' ) where s'' is this new random variable, which is interpreted as Alice's contribution to the wallet seed. Thus, the wallet seed s is now: s=hash(g s'' )+r' where Alice randomly chooses s'' and bank 601 randomly chooses r'. The purpose of redefining seed s in this way is to create a new double-spend formula

[0324]

number

[0325] is immediately derivable from T, which provides the same characteristics as T in the original implementation (see below for a description of the CHL protocol), so that when Alice 602 double spends, her seed is derivable by bank 601. This is done in the following way: when Alice 602 double spends, bank 601 knows two different values of Z and R, labeled Z1, R1, Z2, R2. Then the bank

[0326]

number

[0327] Calculate the complete seed s=hash(g s'' )+r' where r' is the bank's unique contribution, which the bank stored along with Alice's information at the time of withdrawal. Then, the formula for the coin serial number is

[0328]

number

[0329] Using all the rest

[0330]

number

[0331] For , the remaining serial numbers can be calculated. Bank 601 can then blacklist all these unspent coins in her wallet by publishing the unspent serial numbers. This process ensures that the secret is ■ This can be repeated for any number of additional secrets, as long as they are in the form: where this double spend value Z is included in the exchange of coins. At this point, bank 601 W=(u,s,t,z1,σ B (u,s,t,z1),J) to Alice 602, the bank 601 broadcasts the transaction as given in Figure 7a.

[0332] The first output is Alice P A or Bank P B and a hash of the first coin's serial number. All later coin outputs also have this format. This means that to unlock any of these outputs, the coin's serial number must be known, which at this point only Alice 602 knows. If Alice 602 double-spends, only Bank 601 can calculate the coin's serial number before it appears on-chain. The bank can then spend any coin output in this format, which will blacklist the coin. This additional requirement in the locking script means that Bank 601 cannot maliciously blacklist a coin. Note that because the serial numbers are on-chain, it is more secure for Alice 602 to spend the serial numbers in a random order. One way to do this, without having to remember all spent serial numbers, is to randomly choose a∈J,

[0333]

number

[0334] the greatest common denominator

[0335]

number

[0336] Then, to consume the i-th coin,

[0337]

number

[0338] In this process, because the counter does not cycle until all coins have been spent, she does not need to keep track of the serial numbers of the coins she has already spent, but only the total number spent and the initial values a and b. The second output in the transaction is simply the change to bank 601.

[0339] Finally, the data provided in the OP_RETURN output is given in Figure 7b, where the first field specifies which fiat currency the coin represents, the coin protocol flag specifies which digital cash protocol the coin is issued using, the coin action flag specifies which action this transaction corresponds to, which in this example is a withdrawal, and the coin value is the number of coins withdrawn. In this example, 64 coins are issued. After this, there is the option to add any additional information if needed.

[0340] Multiple coins can be issued at once. As one option, the wallet balance can be given in the OP_RETURN data. Then, whoever accepts coins from Alice 602 can verify that the balance and previous spend values match. This also ensures that the counter is in the correct range. In this case, spending multiple coins at once is easy because they can be easily listed in OP_RETURN. As another option, the withdrawal transaction can have multiple P2PKH outputs. Each output then represents a single coin, and one output is consumed each time a coin is spent. The wallet balance is easily calculated by the number of unspent outputs in the transaction, and blacklisting coins is easy in this protocol because they are blacklisted by consuming the corresponding unspent transaction output (UTXO). The disadvantage of this case is that if the number of issued coins is large, the number of UTXOs will be large, which imposes a burden on miners to keep this data stored. Each case has advantages and disadvantages. The preferred case depends on the situation. The first option is used in this exemplary traceable protocol.

[0341] In this example protocol, Alice 602 sends a request to a merchant 603 to spend coins. - Coin serial number, The double consumption formula, calculated using R and obtained by Alice from the supplier, A zero-knowledge proof that all these formulas are correctly formed, Signature σ B that the zero-knowledge proof of knowledge of is the bank's signature on the value (u, s, t, z1), Proof that counter J is in the correct range, and Withdrawal transactions and any further spending transactions is given to the vendor 603.

[0342] Suppose Alice 602 withdraws X coins. Because the serial numbers of these coins all have the same seed "s," there may also be a counter in the coin that goes from 1 to X to create different serial numbers; including this counter in the serial number essentially means that each coin has a different serial number. Alice 602 may be required to prove that a given serial number was derived from the seed and counter. The range may be arbitrary, for example, from 1, ..., X. However, there is nothing to stop her from creating a coin serial number derived from X+1, X+2, ... and saying that this is a coin withdrawn from bank 602 and here is the proof that the seed was signed. So, to prevent this, Alice includes a proof that the counter value is between 1, ..., X.

[0343] More specifically, to spend coins, Alice 602 and the merchant 603 perform the following steps: Alice 602 calculates R=H(pk M ||info), where info is some variable chosen by the merchant 603 and H is some collision-resistant hash function. info should be something that changes with each transaction to ensure that the corresponding double-spend formula is different, such as the time and date of the spend, the invoice for the spend, or a transaction counter. Alice 602 calculates the coin serial number and the double-spend formula,

[0344]

number

[0345] where

[0346]

number

[0347] is the DY pseudorandom function given in the preparation section. Since the double spend value depends on the merchant ID and its input info, these cannot be calculated before this.

[0348] Alice602 is (u, s, t, z1, σ B , J), which is turned into a single signature Φ on the message as follows: This signature proves that J is in the correct range, that S, T, and Z are well formed, and that the signature σ B is correctly formed. This is done in the following way: Let A = PedCom(J). A is in the range

[0349]

number

[0350] Let B = PedCom(u), C = PedCom(s), D = PedCom(t), E = PedCom(z1) prove knowledge of the CL signatures on u, s, t, and z1 without revealing them. Prove that the serial number S and the double-spend formula T are well-formed. Then the signature is a message

[0351]

number

[0352] It becomes the opposite of.

[0353] Ultimately, the coins Alice602 is spending are: (S,R,T,Z,Φ) It has the following format.

[0354] If signature Φ verifies, the merchant accepts (S,R,T,Z,Φ). Note that Φ serves as proof to the bank that merchant 603 acted correctly. Finally, Alice 602 updates her counter to J=J+1.

[0355]

number

[0356] When , the wallet is empty.

[0357] Given the merchant 603 the chain of withdrawal transactions and all coin spends leading from this transaction, this proves to the merchant 603 that the coin was issued by bank 601. Alice 602 then needs to prove that the serial number and double spend formula are correctly calculated from the seed s, t, z1, and counter J, that bank 601 signed the value (u, s, t, z1), and that the counter is in the correct range. This is done by sending the message

[0358]

number

[0359] This is summarized using a zero-knowledge proof of knowledge of the above signature Φ.

[0360] Using this information, merchant 603 must first verify that the coin has not already been spent or blacklisted. Merchant 603 does this by verifying that the coin has not already appeared in the OP_RETURN data field in the transaction. If the merchant finds that it has already appeared, the merchant rejects the coin. Otherwise, the merchant verifies that the serial number and double-spend zero-knowledge proof are correctly formed and that J is in the correct range. Additionally, merchant 603 can verify that the number of coins spent matches the wallet balance. If the coin passes these checks, merchant 603 accepts the coin. Once merchant 603 accepts the coin, Alice 602 and merchant 603 create the spend transaction shown in Figure 8a.

[0361] Alice 602 creates a transaction by signing the output of the withdraw transaction as her input. She then creates three outputs. The first output corresponds to the next coin Alice 602 wants to spend, so this spend protocol can be repeated. The second output is used to deposit the coin into Bank 601. The third output contains data about the coin being spent. Because she needs to sign three outputs, she uses the flags SIGHASH_ALL|SIGHASH_ANYONECANPAY. Because Alice 602 uses this particular flag, the merchant 603 can only add its own inputs, not outputs, after Alice 602 signs it. The input from the merchant 603 is needed so that the merchant has a record of accepting the coins as payment from Alice 602. Alternatively, because asking the merchant 603 to sign the transaction first also requires the exchange of some transaction data, it is more beneficial to have Alice 602 sign the transaction first and send it along with a zero-knowledge proof of knowledge. The merchant 603 then signs the transaction with their input and broadcasts it to the blockchain network.

[0362] Note that two of the three signatures must be present to unlock the second output. If the deposit is accepted, this is merchant 603 and bank 601. The other combinations of signers are simply for security in case one of the parties acts maliciously. In this protocol, bank 601 will only sign the following deposit transaction with its public key P B and the merchant's public key P M Note that the bank will only accept the digital coin if it includes this output signed with . The final output contains data in the format of Figure 8b. This transaction is confirmation that merchant 603 received the coin. Since R depends on the merchant ID, no one other than merchant 603 can deposit the coin. Since the coin serial number is now on-chain, no other merchant should accept a coin with the same serial number. If Alice 602 presents merchant 603 with a serial number that is already on-chain, this merchant can publish the coin information S, R, T, and Z, even if it does not accept it. This means that bank 601 can calculate any remaining unspent coins in her wallet and blacklist them. There is an option to reward merchants who turn in double-spends.

[0363] In this protocol, because the serial number is on-chain, merchant 603 can wait to contact bank 601 to deposit the coin; if a double spend occurs, it can already be identified at this point. During the deposit, bank 601 must perform the same checks as merchant 603, additionally verifying that the preimage of R is indeed the merchant's ID (and any other information). Bank 601 also verifies that all previous transactions have the correct format and rejects any deposits that do not. This ensures that all users comply with the protocol. Once the serial number is presented and found to be non-double-spend, merchant 603 and bank 601 sign the deposit transaction, as shown in Figure 9a, which serves as confirmation that the coin has been deposited. Merchant 603 can create a transaction template, sign the input, and send it along with other information about the coin. Bank 601 then appends its signature to the input and broadcasts the transaction to the blockchain. This transaction signals that bank 601 has accepted the coin deposited by merchant 603. The data has the format of Figure 9b.

[0364] To deposit a coin, the merchant 603 gives the coin (S,R,T,Z,Φ) to the bank 601. If Φ is verified and R has not been previously deposited (i.e., (S,R) is not already in the list of spent coins), the bank adds (S,R,T,Z,Φ) to the list and credits the merchant's account. If the bank 601 finds that the coin serial number S is already in its database, it checks whether R is also the same. There are then two possible situations:

[0365] If R is the same, bank 601 assumes that merchant 603 has already deposited the coins and is therefore at fault. In this case, it is possible that only merchant 603 is at fault, or that both Alice 602 and merchant 603 are at fault. Since merchant 603 has no reason to collude with Alice 602, it is safe for bank 601 to assume this. In this situation, only merchant 603 loses, as Alice 602 should not be identified and punished. This case is solved using blockchain by exploiting the binary nature of transaction outputs: they are either unspent or spent. Therefore, simply, neither case of double spending is possible using blockchain.

[0366] If R is different, then it must have been at least Alice 602 (and possibly Merchant 603) who acted fraudulently, and Bank 601 can calculate the identities of both. To calculate Alice's identity, the following calculation is performed: Let the previous database entries be denoted as R1, T1, and the current values as R2, T2. Then Bank 601:

[0367]

number

[0368] can be used to calculate Alice's public key.

[0369] can be used to derive all coin serial numbers and therefore blacklist unspent coins s'' There are equivalent calculations corresponding to Z1 and Z2 that yield:

[0370] Finally, if vendor 603 is also to blame, the info is different for both versions of the double-spent coin, and pk M are equivalent. info and pk M Since both Alice 602 and Merchant 603 are stored with each deposit, Bank 601 can immediately detect this and the bank can punish both Alice 602 and Merchant 603. Thus, there is no incentive for either party to collude.

[0371] If a coin is indeed double-spent, the coin serial number appears twice on the blockchain, and Bank 601 accepts only the coin that first appeared. Bank 601 then uses the formula from both occurrences to calculate the identity of the double-spendr using the double-spend values T1, T2 and merchant IDs R1, R2. Additionally, a seed can be calculated from Z1, Z2 and R1, R2 in a similar manner. These calculations are shown above. Bank 601 then calculates Alice's identity g u and the coin seed s can be computed. Bank 601 can then derive the serial number corresponding to Alice 602, publish these on-chain, and blacklist the coin. Naturally, this protocol allows the bank the option of rewarding merchant 603 for delivering Alice 602 to bank 601 by including a payment to merchant 603 in the above transaction.

[0372] Recall that bank 601 knows that if the double-spend coins have the same serial number and merchant ID, merchant 603 is to blame. If all the transactions described above are immediately followed by a deposit, merchant 603 would never be able to deposit a coin twice in this protocol, since the first deposit would consume the UTXO needed for the second deposit.

[0373] Untraceable Digital Coin (CHL) This exemplary protocol eliminates the traceability of the coins and increases the burden on merchants 603 and banks 601 to verify that the coins were legitimately issued. This burden involves the same checks performed in the traceable protocol described above, but with the added feature that double-spending is impossible, and any attempt at double-spending can be immediately detected.

[0374] Similar to the traceable protocol, Alice 602 wants to withdraw some digital coins from Bank 601 and spend them at Merchant 603, and Merchant 603 deposits them back to Bank 601. The setup is the same as the previous setup: Bank 601 has a public / private key pair (pk B ,sk B ) Then the bank's public key is (n, a1,..., a4, b, c) and its private key is p1, where n = p1p2 is a special RSA modulus. In addition, Alice 602 and the merchant 603 each have, as before, some

[0375]

number

[0376] (pk u ,sk u )=(g u ,u). Every user also has a unique EC public / private key pair of the form (pk=sk·G,sk) so that they can receive and spend Bitcoin. Alice's key pair is (P A ,sk A ) and the bank's key pair is denoted as (P B ,sk B ) and finally, the merchant's key pair is given by (P M ,sk M )

[0377] In this protocol, Alice602: W=(u,s,t,z1,σ B (u,s,t,z1),J) where u is Alice's private key, s is the coin serial number seed, t, z1 are the double spend formula seeds, and σ B is a signature by Bank 601 on a secret, and J is the wallet counter. Alice 602 broadcasts the transaction to confirm the withdrawal. In an untraceable protocol, each coin in her wallet must have a corresponding withdrawal transaction, and these are not tied together. Alice 602 later creates a withdrawal transaction for each wallet withdrawal from Bank 601. If she does it simultaneously, Bank 601 will likely be able to know which withdrawal the transaction corresponds to. In practice, the ease of identifying Alice 602 depends on the number of users of the ecash system. If there is only one (or a few) users, the user is easily identifiable by Bank 601 whenever she makes a withdrawal transaction on-chain.

[0378] Alice 602 creates her own withdraw transaction representing each coin. Note that the fact that Alice 602, not Bank 601, creates the withdraw transaction is an important difference between traceable and untraceable protocols. This transaction has the form given in Figure 10a. This transaction represents a single coin. As before, the locking script contains the coin's hash, so Bank 601 can only spend the output if it knows the coin's serial number, which only occurs when Alice 602 double-spends.

[0379] The OP_RETURN data is shown in Figure 10b. In this protocol, coins have a set value, so no balance is required because each UTXO represents one unit of value. Alice 602 can create this transaction whenever she wants, as long as it is before the spend protocol begins. As mentioned, it is more secure for Alice 602 to create this transaction at a random time after the withdrawal and at a different time than transactions corresponding to other coins in the wallet, as this would compromise privacy. Bank 601 will not accept the deposited coins unless the corresponding withdrawal transaction has this format. This prevents Alice 602 from acting maliciously, such as creating outputs that Bank 601 cannot spend.

[0380] To spend the coin, Alice 602 provides the merchant with the coin's serial number, the double spend formula, the wallet secret along with a zero-knowledge proof that these are correctly formed, a zero-knowledge proof of knowledge of the bank's 601 signature on the wallet secret, a zero-knowledge proof that the counter is in the correct range, and the withdrawal transaction.

[0381] All Proof is a Message

[0382]

number

[0383] There is an additional commitment E, which corresponds to an additional secret z1, sent as a signature on knowledge Φ above, and which is E=PedCom(z1) It is defined as follows.

[0384] First, merchant 603 must verify that the serial number has not already appeared on the blockchain. This verification leverages the blockchain's immutable history. If the coin serial number is not found in this search, merchant 603 can be confident that it could never have appeared on the blockchain and therefore it has never been spent. If the blockchain search turns out to be clean, Alice 602 must next prove to merchant 603 that the serial number and double-spend formula are all correctly formed. Finally, Alice 602 must prove that the counter is in the correct range.

[0385] Once the merchant 603 accepts the coins, they create a spend transaction as shown in Figure 11a. In this transaction, Alice 602 adds her input and signs only the first output using SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Hash of the OP_RETURN data<h2=SHA-256(data2)> is included in the output, so Alice 602 indirectly signs it and it cannot be changed. She then sends this to merchant 603, who adds her input and change to himself and signs the whole transaction. This input is included to represent the signature from the merchant that they accepted the coin.

[0386] The first output is the output used in a deposit transaction, signed by merchant 603 and bank 601. Other combinations of signatures are included in case a party acts maliciously. This first output is equivalent to the second output in a traceable spending transaction. In this case, the second output is simply the change to merchant 603, and the final output is the data shown in Figure 11b.

[0387] This transaction is a record by the merchant 603 that it has received the coins without sharing all the information needed to deposit them, because, as before, no one except the merchant knows the preimage of R. Additionally, the signature on the proof of knowledge is kept secret. The only information shared here is that needed to identify the double-spender, and the rest of the knowledge is hidden until the coins are deposited. Note that if the merchant 603 discovers that Alice 602 is attempting to double-spend, the bank 601 can incentivize the merchant 603 to hand over the coin details so that Alice 602 can be identified.

[0388] Now, Merchant 603 contacts Bank 601 to deposit coins whenever convenient for the merchant. Bank 601 will only accept the coin that first appears in the second transaction if all previous transactions have the correct format. Merchant 603 provides Bank 601 with the transaction, the preimage of R, and the signature Φ. Bank 601 then verifies that serial numbers S and R are being presented to the bank for the first time and that the serial numbers are not blacklisted by searching the blockchain for the data. They should only appear once in transactions presented to the bank. If this is true, Bank 601 verifies the same proof as Merchant 603, and additionally, the withdrawal and spend transactions are correctly formed. Once all these confirmations are made, the deposit transaction in Figure 12a is published to the blockchain.

[0389] This transaction signals that merchant 603 has deposited a coin and that bank 601 has accepted it. The input is from the spend transaction, signed by both merchant 603 and bank 601, signaling that they were both involved in this interaction. The first output is simply the change to the bank (if there is any), and the second output contains the data shown in Figure 12b. There is space to publish the double-spent serial number. If the deposit turns out to be a deposit of a double-spent coin, bank 601 can check whether Alice 602 or merchant 603 is to blame. If it is a coin with the same serial number and merchant ID R, merchant 603 is considered to be to blame and bank 601 rejects the coin. If the merchant IDs are different, it is Alice 602 who is to blame. Bank 601 then uses the double-spend formula to find Alice's key g u and her seed s', and from this we can calculate all the serial numbers, consume all the UTXOs that Alice602 created, and publish the additional serial numbers on-chain.

[0390] The biggest advantage of this system over the first one is that the coins are completely untraceable: Bank 601 knows that it issued the coins to Alice 602, and it knows that Merchant 603 deposited the coins, but it does not know the path the coins took from withdrawal to spending, unless that was the result of double spending.

[0391] Both traceable and untraceable protocols prevent someone from double-spending at the point of sale, because the merchant checks for previously spent coins at this point, not at the time of deposit. This is true for any digital coin system implemented in this way. Additionally, because all transaction data is published on the blockchain, digital coins are now easily auditable. Anyone involved in the protocol can prove their involvement to an auditor.

[0392] These protocols improve upon previous ecash systems by using two properties of the blockchain. The first property they use is the fact that because the blockchain is a distributed, immutable database, the list of coins to be spent is publicly available to anyone. This makes it easier for those accepting coins to check whether they have already been spent. Additionally, these protocols utilize the binary state of an output transaction: it is either spent or unspent. Once the state of an output changes from unspent to spent, it cannot be spent again, so double spending is simply not possible.

[0393] The steps of withdrawing, spending, and depositing coins can be connected, making them "traceable" in a sense. Anyone can see digital coins being withdrawn, spent, and deposited, but the identity of the user is hidden from everyone except those with knowledge of the identity corresponding to the public key used in each transaction (a feature of blockchains in general). The key difference is that in a traceable protocol, Bank 601 knows exactly who withdrew the coins, while in an untraceable protocol, Bank 601 does not know the identity of the withdrawer at the time of deposit.

[0394] The following describes some example ecash protocols that may be implemented using the general transactions of Figures 13a through 13c by specifying the contents of the OP_RETURN data.

[0395] Chaum ecash protocol Figures 14a through 14c show example OP_RETURN data for a withdraw, spend, and deposit transaction, respectively, according to this protocol. Chaum's is an online ecash system, which means that banks must be online to accept any coins at the time they are spent. Moving this protocol on-chain takes the ecash protocol offline.

[0396] Alice wants to get coins from the bank, which she spends at a merchant. The bank chooses two RSA primes p and q, computes n=p·q, and keeps its factorization secret. Then, the mth root of an integer mod n is computationally impractical to compute without knowledge of the prime factorization. This concept serves as a bank signature on the coin. The coin is (s,f(s) 1 / 3 mod n) where f is some one-way function, such as a hash function, that is publicly known, and s is a random seed for the coin. Then, f(s) 1 / 3 mod n is the coin serial number. The bank's calculation of the cube root is the bank's signature on the coin. The cube root is an arbitrary choice; it can be the calculation of the mth root of f(s) mod n for any m≧2, as long as the choice of m is constant for all ecash withdrawn. To issue a coin, the following steps are taken:

[0397] Alice chooses a random coin seed s and a blinding value r, and creates a "blinded" coin serial number B=r 3 Send f(s) mod n to the bank. The bank then receives the cube root of B, B, which only the bank can calculate. 1 / 3 =r f(s) 1 / 3 Returns mod n and deducts £1 from Alice's account. This calculation of the cube root represents a signature to the bank, since only the bank knows the factorization of n and therefore only the bank can calculate the cube root modulo n. Note that there is always exactly one cube root modulo n=pq. On the other hand, the bank does not know the value of r, so it only knows the value of the coin serial number f(s) 1 / 3 mod n. However, the bank knows that it has calculated this value, because no one else can. Alice C=r -1 ·B 1 / 3 =f(s) 1 / 3 mod n As shown above, we can calculate this result by multiplying it by the reciprocal of our blinding value r -1 By multiplying with , she unblinds the coin serial number, so now she has a coin consisting of the seed and the coin serial number (s, f(s) 1 / 3 mod n). Alice then stores this, ready to consume when she needs it.

[0398] At this point, the bank 1 / 3 It is important to note that since the bank does not know the exact value of mod n, when it is deposited in the future, it cannot associate it with this interaction. However, the bank can see that it is the cube root modulo n, and since only the bank has the ability to calculate this, the bank knows that it "signed" it. In this example, it is only possible to withdraw a single coin. To withdraw more than one coin, this protocol would be repeated for different s and r.

[0399] To pay £1 to the merchant, Alice gives exactly this coin to the merchant. The merchant verifies that the coin is in the correct format by computing the cube of the coin's serial number and additionally computing the value of the public function f from a given value of s.

[0400]

number

[0401] C'=f(s) mod n Compare these two values; if they are the same, the coin is correctly formed.

[0402] Before utilizing the blockchain, the merchant contacts the bank to verify that the coin has not yet been spent before accepting it. The bank may then additionally verify that the coin has the correct format by calculating the same result as the merchant. Once the coin is verified, the bank adds the coin serial number to its database.

[0403] The big advantage of using a blockchain to record Chaumian ecash is that it takes the protocol offline. Merchants can check this decentralized database themselves and reject coins that have already been spent, rather than contacting their banks to immediately check the database. This is true for any online protocol. Coins can be moved offline from the blockchain.

[0404] Additionally, the binary nature of UTXOs means that double-spending or attempts to deposit a coin twice simply cannot occur in a traceable protocol. This is because there is only one spendable UTXO for a withdrawal transaction representing a coin, since a bank never signs the same coin more than once. And similarly, a deposit can only occur once, since the UTXO for the corresponding withdrawal transaction can only be spent once. In an untraceable protocol, this depends on both the nature of this UTXO and the nature of the distributed database. Merchants and banks must now ensure that no other withdrawal transactions corresponding to the same coin have been created. This is enough to improve Chaumian ecash.

[0405] Untraceable ecash 15a through 15c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0406] The Chaum ecash system described above can be extended to allow cash to be spent offline without using the blockchain. This is done by embedding the identity of the withdrawer into the coin, and it can be calculated whether the withdrawer double-spends their identity. It is also possible to withdraw more value at once (and different values at different times). This means that we can wait for the merchant to deposit the coins, and if it is a double-spend, we can calculate the identity of the double-spender. Additionally, in this protocol, Alice can only spend 2 j She can spend coins up to a withdrawn value of -1 and then get change from any unspent value. However, she cannot spend the change at another merchant.

[0407] In this system, the bank publishes two RSA integers n, n' such that n = p q and n' = p' q', where p, q, p', q' are prime and the factorization remains secret. In this implementation, Alice's bank account number is denoted as u and her coin counter is denoted as j. As we will see, if she double-spends, her bank account number becomes derivable. Two collision-resistant functions f, g of argument 2 are publicly known. That is, there are two functions with two arguments.

[0408] Alice has value 2 j If Alice wants to withdraw -1 coins, she sends t pairs of expressions to the bank, which we call "major" and "minor" candidates. The major candidates contribute to the coin's serialization and double-spend prevention, and the minor candidates are used to obtain change from the transaction. In addition, we eventually know the relationship between the number of pairs t and how many coins Alice wants to withdraw. For each major candidate, Alice creates a t-coin with length l for i=1,...,t. i , b i , c i , d i , e i , r i Randomly select Major Candidate M i teeth, M i =f(x i ,y i ) where x i =g(a i ||b i ,c i ) and

[0409]

number

[0410] and

[0411]

number

[0412] is the xor symbol, and || means concatenation. Each minor candidate m i is m i =g(b i ,e i ) is given by

[0413] Alice generates a random value r i We blind the candidates using

[0414]

number

[0415] where k is the number of major candidates in the coin. The first j candidates are 2 j Note that the remaining kj major candidates in the coin represent binary digits up to -1, preventing double-spends. This means that the larger kj, the higher the chance of catching a double-spender. The blinded minor candidates are

[0416]

number

[0417] is.

[0418] Alice sends the blinded candidates to the bank. The bank randomly selects half of the pairs and unequivocally verifies that they have the proper form. This leaves t / 2 pairs whose values the bank does not know. They can be considered correct because the bank randomly verifies half of the t pairs presented. In this example, Alice chooses the value 2 j Although Alice has withdrawn one coin, -1, it is possible that she has submitted more candidates that can now be split into multiple coins. This is done by the bank, which simply splits the remaining major candidates into sets of size k. Thus, the size of t depends on the number of coins Alice wishes to withdraw. The bank chooses the degree of the remaining candidates and extracts the following roots:

[0419]

number

[0420] where 1≦i≦k

[0421] [Number]

[0422] However, 1 ≤ i ≤ j

[0423] The bank returns the product of the blinded major candidates

[0424] [Number]

[0425] and returns the minor candidates individually. The bank then records that a coin with a total value of 2 j -1 has been issued. Alice then

[0426] [Number]

[0427] and for the minor candidates

[0428] [Number]

[0429] extracts. Alice now has coins that can be consumed up to a value of 2 j -1 and gets any change for the unconsumed value.

[0430] To make a purchase, Alice first labels the first j of M i as denominations 1, 2,..., ½ j-1 . Then, for each 0 < i ≤ j, Alice reveals one of the two to the merchant. If the i-th denomination is a term in the total purchase amount, Alice reveals the preimage of y i [[ID=6l]]and x i to the merchant. If the i-th denomination is not in the total purchase amount, Alice reveals x i and y i The last kj terms are used to prevent double spending in the following way: the merchant will only reveal a random binary string z j+1 ,...,z k Select j <l≦kとして、z l If =1, Alice will i and x i The original image of the product will be revealed to the dealer. <l≦kとして、z l If =0, Alice will i and y i When Alice double-consumes, the probability that the merchant chooses a different string is high, and the collision bit z l This is why it is possible to compute Alice's account number from either kj or kj, and the larger kj, the more secure the prevention of double-spend. Alice gives the merchant all relevant preimages of her coins.

[0431] The bank verifies that the coins have not been previously spent by checking the blockchain and / or the bank's off-chain database of spent coins (the database may be stored on-chain). If not, the bank then adds S and the preimage given to the merchant to its database. For Alice to get her change, she must send E for the refund. i and preimage b i and e i to the bank. The bank will i Compares the coins with previously spent ones and identifies Alice as a dual spender if they have been presented before.

[0432] It is possible that Alice spends coins at a merchant and gets a refund before the merchant contacts her bank. If the bank stores her identifying information along with the change transaction, it can identify her and charge her bank account. However, if she withdraws the value again as cash, there is no way to prevent this from being spent as long as she acts legitimately. This attack can be prevented by using a blockchain, as explained below.

[0433] It is possible to modify this scheme so that all coins withdrawn by Alice are invalidated when a double-spend is detected. This is done by linking initial candidates in a matrix, where each initial candidate has an index corresponding to their position in the matrix. Banks can then blacklist coins by publishing the blacklist on-chain, and merchants can check any presented coins against this blacklist.

[0434] Moving this ecash system on-chain prevents double-spending at the point of spend, rather than at the point of deposit. This attempt to double-spend can also be reported to the bank, which, in the case of a traceable protocol, can track Alice down by the signature on the change transaction. Ultimately, any double-spender has an identity that can be derived from the information presented on-chain, providing another deterrent to users attempting to double-spend.

[0435] Endorsed ecash 16a through 16c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0436] This ecash can be exchanged as an unendorsed ecash, allowing Alice to prove she owns the coin without revealing the entire coin.

[0437] This protocol has the same setup and withdrawal as the CHL protocol. For Alice to spend ecash at a merchant, they perform the following steps: Before giving the coin serial number S and the double-spend formula T to the merchant, Alice first chooses a random endorsement (x1, x2, x3). She computes the unendorsed coin (S', T', Φ', R, y), where

[0438]

number

[0439] ,

[0440]

number

[0441] , and y = PedCom(x1,x2,x3). Φ' is the number of unendorsed coins (J,u,s,t,σ B ,x1,x2,x3) is valid. S', T' are simply intermediate values that she endorses, so the actual coins represented by S, T are the values that are ultimately given to the bank. These values S, T were explained above. The unendorsed coins are blinded coins that can later be given to the merchant. Similar to CHL, the merchant can verify Φ' and confirm that the unendorsed coins are valid. When Alice and the merchant are willing to continue the exchange, the merchant is given an endorsement (x1,x2,x3). Using this, the merchant can easily (S,T,Φ',R,(x1,x2,x3),y) is expressed as follows:

[0442]

number

[0443] which then results in the same formula as described previously. The only difference between this endorsed ecash and the CHL protocol is that signature Φ ≠ Φ', but Φ' is still sufficient proof that the coin was correctly issued by the bank.

[0444] Alice can create as many unendorsed coins as she wants, and still be identified only if she double-spends. This process allows Alice to show that she has coins without sharing them, which means she can prove to merchants that she actually owns them.

[0445] Additionally, even if the sale does not complete, Alice can still spend her unendorsed coins elsewhere without being identified. In CHL, if Alice gives her coins to a merchant and the exchange does not complete for some reason, she cannot spend her coins elsewhere without potentially being identified. If two different merchants have the same serial number with different double-spend formulas, they can use their double-spend formula to calculate her identity.

[0446] In this protocol, merchants deposit coins (S,T,Φ',R,(x1,x2,x3),y), and banks receive the same conditions as CHL coins, plus (u,s,t,σ B ,J,x1,x2,x3) can be verified. The bank can identify the double spender in the same way as before by storing (S,T,R) for every presented coin on the blockchain.

[0447] Like other ecash protocols, this prevents double-spending at the point of spend, not at the point of deposit, because merchants can check this decentralized database for previously spent coins. Additionally, traceable ecash prevents double-spending by making it impossible to double-spend a UTXO. Untraceable ecash relies on this and the fact that anyone can check for previously spent coins. This protocol, like other protocols, also allows anyone to calculate the identity of a double-spender, which is another deterrent to double-spending attempts.

[0448] Practical and compact ecash 17a through 17c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0449] The protocol allows for spending multiple coins at once, either spending an entire wallet at once, known as a "compact" spend, or spending multiple coins at once, known as a "batch" spend.

[0450] This is similar to the original CHL protocol, but the bank now needs to sign four messages with its signature (instead of three), and it additionally signs an integer that represents its signature on a counter. The bank must then create a public / private key pair (pk) that allows it to sign four messages with one signature using the CHL signature scheme. B ,sk B ), which means that the public key has the form (n, a1,..., a4, b, c) and the private key is p1 such that n = p1 p2 is a special RSA modulus. In addition, Alice and the merchant each have some

[0451]

number

[0452] (pk u ,sk u )=(g u ,u), where m is a prime number and g∈G. Finally, the bank signs an integer σ B (1), σ B (2),..., σ B (k) is published, where k=2 l and this is the number of coins to be withdrawn. B (1), σ2:=σ B (2),...,σ k :=σ B (k=2 1 ) is called

[0453] Withdrawals are very similar to CHL withdrawals. The only difference is that the bank signs an additional variable called y along with another seed. l To withdraw coins, Alice must take the following steps: In this protocol, Alice can withdraw 2 coins by the zero-knowledge property of knowledge of the value of the coin's internal counter J. l You can only withdraw wallets containing coins.

[0454] Alice can prove sk using the zero-knowledge proof definition in the preliminary section. u Alice identifies herself to the bank by proving knowledge of s, t, and s. Then, Alice and the bank generate a wallet secret in the following way: Alice generates random values s, t, and s.

[0455]

number

[0456] Select Pedersen Commitment

[0457]

number

[0458] to the bank. The bank chooses a random integer r' to contribute to the wallet and sends it to Alice. Both the bank and Alice independently

[0459]

number

[0460] Calculate.

[0461] This step is essentially creating a wallet secret and having the bank contribute randomness to this step. Alice and the bank then run the CL signature protocol to obtain the bank's signature on the value in Pedersen Commitment A, and the signature σ B (u,s,t,y)=(V,r,e) Here

[0462]

number

[0463] The method for computing this signature is given in the preparatory section, where (x1, x2, x3, x4) is (u, s, t, y). Alice has a wallet W = (u, s, t, y, σ B (u,s,t,y),J), where J is an l-bit counter initialized to 0. Note that since the signature by the bank is only on the wallet seeds s, t, and y, the serial number and double spend formula do not necessarily need to be stored in the wallet, but can instead be derived when needed using the wallet seed and wallet counter. The bank then sends the 2 l Withdraw coins.

[0464] At this point, the protocol splits into two parts depending on whether one wants to spend the entire wallet at once, or whether one wants to spend n of the coins in the wallet. If Alice spends n coins, she can still spend the remaining coins as a single CHL coin, or as another batch of size n'.

[0465] In compact spend, to spend the entire wallet, Alice and the merchant perform the following steps: Alice sends =PedCom(s,t,u,y), where s, t, and u are the same as in CHL, and y is another random number used to prevent double compact spends. Alice then sends T c =g u g R / (y+1) , and the signature σ from the bank for (s,t,u,y) B Finally, Alice reveals s and t to the merchant. If the signature proof is valid and s and t are correct, the merchant accepts the coin.

[0466] In batch consumption, to consume n coins, the following steps are taken: Alice makes a commitment C = PedCom(s,t,u,y,J) for i = 0,...,n-1 and S i =g 1 / (s+J+i+1) , T i =g u g R / (t+J+i+1) Send.

[0467] She also (σ B ,s,t,u,y,σ J ,j,σ J+n-1 ) and send a zero-knowledge proof of knowledge of the signature for σ J and σ J+n-1 is a signature on the initial and final values of the coin's counter. A zero-knowledge proof of knowledge of a signature Φ is a signature σ on (s,t,u,y). B , signature σ for J J , signature σ for J+n-1 J+n-1 , for all S for i=0,...,n-1 i and T i , and a signature that provides knowledge that C is a commitment to the values (s, t, u, y, J). If the zero-knowledge proof of knowledge Φ holds, the merchant accepts the coin.

[0468] In this protocol, the merchant gives the bank all the information about the coins, and a signature for the zero-knowledge proof of knowledge. If the merchant is depositing a batch spend, the bank must calculate all the serial numbers and double spend formulas and store them as if they were spent individually. The bank then calculates the number of coins (S i ,T i ,R) and S i and T i is for all individual coins deposited, and in the case of compact consumption, T c Then, the formula for calculating the identity of a dual consumer is: If Alice performs two compact consumes,

[0469]

number

[0470] If Alice has double batch consumption, g u =(T R' / T' R ) 1 / (R'-R) If Alice double-spends a single coin in a compact spend, the bank can calculate Alice's identity in the same way as CHL.

[0471] As expected, the OP_RETURN data is nearly identical to the CHL ecash. Note that for compact spends, there is a slight modification to the protocol: the merchant, rather than the bank, must calculate all serial numbers. This is then published on-chain in the spend transaction. If the merchant waits for the bank to calculate all serial numbers, Alice may double-spend a single coin that was spent as a compact spend.

[0472] Like other protocols, this protocol prevents double-spending at the point of spend, not at the point of deposit. As with previous protocols, this is because merchants now have access to a database (blockchain) of spent coins. Merchants can check this database and reject coins that have already been spent. Additionally, the identity of a double-spender is now computable by anyone with access to on-chain information. This acts as a deterrent to anyone who would risk ruining their reputation.

[0473] Brands ecash (BRA) 18a through 18c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0474] This offline ecash is computationally simpler compared to CHL ecash in terms of zero-knowledge proofs of knowledge, but with the consequence that only one coin can be withdrawn at a time.

[0475] p, q correspond to the binary length l p , l q are large prime numbers with g, g1,

[0476]

number

[0477] Let p, q, g, g1, g2 be publicly known system parameters such that has order q, and

[0478]

number

[0479] is the bank's private key and the public key is h=g x mod p.

[0480]

number

[0481] Let be Alice's private key, and her public key is

[0482]

number

[0483] The bank uses z=(Ig2) x mod p and send it to Alice. Alternatively, the bank

[0484]

number

[0485] and

[0486]

number

[0487] can be published as part of the public key so that users can calculate it themselves.

[0488] Alice wants to withdraw some coins from the bank. The bank will ask her for a random number that the bank keeps secret.

[0489]

number

[0490] Generate a=g w and b = (Ig2) w Alice sends the blind coin to the bank and gets a Schnorr signature from the bank in the following way: Alice:

[0491]

number

[0492] , and x1,

[0493]

number

[0494] Alice randomly generates three numbers: S=(Ig2) s ,

[0495]

number

[0496] , and z'=z S where S is the coin's serial number, B is used in the zero-knowledge proof of the coin's seed, and z' forms part of the Schnorr signature. Alice then calculates two more random numbers μ,v∈Z q Generate a'=a μ g v and b'=b sμ S v These two values also form part of the Schnorr signature. Finally, Alice computes the challenge c' = H(S, B, z', a', b'), where H is l H is some collision-resistant hash function that produces an output of 128 bits. Alice then generates the blinded challenge c=c'μ -1 mod q to the bank. Alice gives c' to the merchant who returns c' to the bank, but note that the bank cannot determine which c and c' are related, and therefore cannot connect the deposit with Alice's withdrawal. The bank replies with r=cx+w mod q, debiting Alice's account. Alice then receives g r =h c a and (Ig2) r =z c As long as it is b, Alice accepts it. Alice then calculates r' = rμ + v mod q, which is the last part of the signature. Finally, the signed coin is (S, B, σ(S, B) = (z', a', b', r')).

[0497] When Alice wants to spend a coin at a merchant, they perform the following steps: To spend a coin (S, B, σ(S, B)), Alice first sends it to the merchant. The merchant checks whether S ≠ 1 and then issues a challenge R = H0(S, B, ID M , date / time) and send it to Alice. H0 is another collision-resistant hash function, and ID M is the merchant's identity, and the date / time indicates when the transaction will take place. Alice calculates r1 = R(us) + x1 mod q and r2 = Rs + x2 mod q and sends the response to the merchant. Finally, the merchant

[0498]

number

[0499] and verifies that the signature sig(S,B) is valid, i.e., g r' =h c' a' mod p A r' =(z') c' b' mod p c'=H(S,B,z',a',b') If this is true, the merchant accepts the coin.

[0500] The merchant sends the bank a payment transcript consisting of S, B, σ(S,B), (r1,r2), and the date and time of the transaction. If S=1, the bank rejects the deposit. Otherwise, the bank follows the transcript and verifies the same information using the identity of the merchant who sent the transcript. If this verifies, the bank checks whether S has not already been stored. If not, the bank stores (S, date / time,r1,r2,R) and credits the merchant account. If S has appeared before, the bank determines the identity of the double spender in the following way: If the date / time data is the same, the bank knows the merchant is a double spender and immediately rejects the coins. If the times are different, the bank knows the user is a double spender. Using (r1,r2,R) and (r1',r2',R'), the bank can calculate the private key u using (r1-r1') / (r2-r2'). The bank then:

[0501]

number

[0502] By computing

[0503] Again, moving this protocol on-chain moves the detection of double-spends to the point of spend. This means that double-spends never occur because they are immediately detected. Along with this, the identity of the would-be double-spender becomes derivable by anyone with access to the blockchain. Like other protocols, this discourages users from double-spending in order to protect their reputations.

[0504] Recoverable ecash (LTW) 19a through 19c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0505] This protocol is an extension to the Brands protocol that adds a recovery center to the protocol so that Alice can recover her lost coins. This extension can in fact be applied to any protocol where coins are not divisible or transferable, which is the case for all protocols described here.

[0506] This protocol has the same parameters as Brands: p, q correspond to the binary length l p , l q are large prime numbers with g, g1,

[0507]

number

[0508] Let p, q, g, g1, g2 be publicly known system parameters such that has order q, and

[0509]

number

[0510] is the bank's private key and the public key is h=g x mod p.

[0511]

number

[0512] Let be Alice's private key, and her public key is

[0513]

number

[0514] The bank uses z=(Ig2) x mod p and send it to Alice. Alternatively, the bank

[0515]

number

[0516] and

[0517]

number

[0518] We can publish,as part of the public key, so users can calculate it themselves.,In this protocol, there is another entity called the Recovery,Center (RC).,We assume that Alice communicates with the RC through an anonymous,channel.

[0519] To withdraw n coins, Alice performs the following steps: First, run a protocol similar to that in Brands' ecash to generate (S i ,B i ,σ(S i ,B i )), where n is the number of coins. RC is H n (x1)=H n (x2)=…=H n (x n )=y, where x1,...x are n numbers. n Prepare H n is defined as an n-collision cryptographic hash function, which is l H' This means that RC can find n inputs that give the same output of this hash function. On the other hand, if the adversary only knows y, it is difficult for the adversary to find the preimage. Alice can get the coin (S i ,B i ,σ(S i ,B i )) to the RC and send the serial number S i RC checks the signature for each i. If it is valid, RC

[0520]

number

[0521] Calculate the RC x i ,

[0522]

number

[0523] Alice replies with x i ,

[0524]

number

[0525] Attaches to the coin. The RC is a separate signature, S b =σ RC Calculate (y,n) and S b , y to Alice, who stores it securely for recovery purposes.

[0526] To spend coins at a merchant, Alice does the following: Alice and the merchant run the payment protocol in the same way as Brands. The merchant then:

[0527]

number

[0528] But (S i ,B i ,σ(S i ,B i ),x i ) is a valid signature. i ) and checks if y is on the blacklist, which is a list of all coins that have been reported to a bank as lost. If all these checks pass, the merchant accepts the coin.

[0529] To deposit coins into a bank, the following steps are completed: The merchant and bank perform the deposit as in Brands. In addition, the bank receives x i Check if the hash value of is in the blacklist. If not, the coin is accepted.

[0530] To recover her lost coins, Alice must perform the following steps: She reveals her identity to the bank and b ,y) to the bank. The bank b is a valid signature for (y,n). The bank checks its database to find all coins with H' equal to y. The maximum number of coins should be n. Some coins have already been spent. The bank calculates the difference between the total amount of coins and the amount spent and returns the difference as a value. This y is then added to a publicly available blacklist to prevent double spending. If any customer tries to spend the refunded coins, the merchant will not accept the transaction. This is very similar to Brands. The difference is that there is an additional space to broadcast restored coins.

[0531] The protocol already has the concept of a database that merchants can check for blacklisted coins, so in addition to being able to detect double-spends earlier on-chain in a similar way to other ecashes, moving the protocol on-chain will naturally incorporate these spent coins into the same list as other blacklisted coins.

[0532] Bounded Accumulator ecash (ACC) 20a through 20c show exemplary OP_RETURN data for a withdrawal transaction, a spend transaction, and a deposit transaction, respectively, according to this protocol.

[0533] This protocol makes coin storage more efficient and involves bounded accumulators. An accumulator is the concept of storing any number of values in the same size storage, where there is evidence if a value is added to the accumulator and no evidence if a value is not added to the accumulator. The concept of a bounded accumulator simply adds an upper bound on the number k of values that can be added to the accumulator.

[0534] Suppose g,h∈G are generators of G with degree p. All elements of G have length l G First, the bank acquires a public / private key pair (x, g x ), and set up a bounded accumulator with upper bound k. Each user has a u ) public / private key pair.

[0535] To withdraw k coins, Alice performs the following steps: To withdraw, Alice generates k random numbers s i These random numbers are used to generate the serial numbers of the coins. i form an accumulated value v, and k pieces of evidence w i Then the bank gets σ B = sig(v, commit(u)). Then the wallet signs a token of the form (σ B ,s i ,w i ,u).

[0536] To spend coins, Alice performs the following steps: The merchant's identity is ID M Alice chooses an unused random number in her wallet and

[0537]

number

[0538] Calculate.

[0539] Alice generates the following non-interactive zero-knowledge proof of knowledge π1: verify(σ B ,v,commit(u))=1 ·s i As evidence, i Use v in ·S, T, Y are formed correctly

[0540] Alice computes a signature of knowledge π2 on a representation of Y using T as a commitment, which is

[0541]

number

[0542] z so that r =r1-cr2, z u =s i -cu, where c is the problem used in the signature of knowledge. In both signatures π1 and π2, the message to be signed is (ID M ||info), where info is some information that changes with each transaction, such as the transaction number, time, and date.

[0543] To deposit coins, the merchant provides the bank with a transaction transcript of the spend protocol. The bank verifies the transcript in exactly the same way as the merchant. Additionally, the bank uses ID verification to prevent double spending. M is the identification information of the vendor, and (ID M ||info) has not been spent before, preventing malicious actors from intercepting legitimate transactions and spending coins. If these are verified, the bank can verify that (S, c, z u ) in the case of double spending, S exists in the database. The bank then stores u=(z u -z u ') / (c'-c) can be used to calculate u. The output is of the form g u The identity of the dual consumer of u If they are the same, the bank can assume that the merchant is acting in bad faith by attempting the double deposit, and the bank will reject the deposit.

[0544] This protocol can be extended to include keeping track of all coins of the dual spender in the following way: During the withdrawal, Alice obtains a signature for (v, commit(u, tr)), where tr is a random number. Alice verifiably encrypts tr under her private key u, and the bank stores this encrypted value. During the spend protocol, Alice additionally keeps track of all coins of the dual spender, R = H(ID M ||info) tr Calculate H and H is a hash function that yields an integer number of bits. The signature π is then verify(σ B ,v,commit(u,tr))=1 ·s i As evidence, i Use v in ·S, T, Y, R are formed correctly is amended to include

[0545] If Alice double-spends, the bank can compute u and then decrypt tr. The bank can then blacklist tr, allowing anyone to see if the user has spent them and deny any further spending. At the point of sale, the merchant simply adds tag=H(ID M ||info) tr However, you only need to check whether the tr on each blacklist is the same as the one presented to the dealer.

[0546] Like other protocols, double-spend detection occurs at the point of spend, which prevents double-spending altogether. Apart from this, moving this protocol on-chain allows anyone to identify double-spendrs, which acts as a deterrent to users double-spending.

[0547] conclusion 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 according to any one or more of the following statements:

[0548] Statement 1. A computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin represents an amount of an asset redeemable by a redeemer in exchange for the digital coin, the issuer maintains a record of coin serial numbers, each coin serial number representing a respective digital coin, the method being executed by the issuer and comprising the steps of: obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising a first coin serial number from a collection of coin serial numbers; determining whether the first coin serial number exists in a database of spent coin serial numbers; and transferring the amount of the asset represented by the first coin serial number to the redeemer in response to one or more conditions being satisfied, wherein a first condition of the one or more conditions is that the first coin serial number does not exist in the database.

[0549] Spend transactions are used to carry tokens (coins, e.g., sometimes called bitcoins) of an underlying blockchain (the "first system"), but the digital coins are part of a different system (the "electronic cash system"). That is, spend transactions, withdrawal transactions, and deposit transactions necessarily transfer ownership of an amount of tokens (e.g., bitcoins) of the underlying blockchain and are also used to transfer ownership of digital coins of the electronic cash system. In other words, coin serial numbers identify digital coins in the electronic cash system, not digital coins (e.g., bitcoins) in the underlying blockchain system. Conventionally, the amount of blockchain tokens (e.g., bitcoins) is not associated with an individual identifier, and each digital coin of the present invention is not individually identified by its respective coin serial number. Specifically, coin serial numbers do not identify the amount of underlying blockchain tokens (e.g., bitcoins).

[0550] Statement 2. The method of statement 1, wherein a record of coin serial numbers is maintained on a blockchain.

[0551] Statement 3. The method of statement 1 or statement 2, wherein the consume transaction comprises an output locked to the issuing public key of the issuer, and wherein said obtaining the send transaction comprises obtaining the consume transaction from the consumer and / or from a blockchain.

[0552] Statement 4. The method of Statement 1 or Statement 2, wherein the blockchain comprises a withdrawal transaction, the withdrawal transaction comprises one or more outputs, each output comprising an indicia of a respective coin serial number of the set of coin serial numbers.

[0553] Statement 5. The method of statement 4, wherein the indicia is a hash of each coin serial number in the set of coin serial numbers.

[0554] Statement 6. The method of Statement 4 or Statement 5, wherein the issuer is associated with an issuing private key-public key pair, and the method comprises generating a withdrawal transaction, the withdrawal transaction comprising an input comprising a signature generated based on the issuing private key; and transmitting the withdrawal transaction to the consumer, a third party, and / or the blockchain network for recording on the blockchain.

[0555] For example, the third party may be a service provider, such as a wallet provider.

[0556] Statement 7. The method of any of statements 4 to 6, wherein a second condition of the one or more conditions is that the consume transaction comprises an input to unlock the output of the withdraw transaction.

[0557] Statement 8. The method of statement 7, wherein the output of the withdrawal transaction, when executed with the input of a later transaction, is configured to require that the input of the later transaction require the first coin serial number.

[0558] Statement 9. The method of any of statements 6 through 8, wherein the consumer is associated with a spending private key-public key pair and is configured to require that the output of a withdrawal transaction, when executed with the input of a later transaction, require that the input of the later transaction require a signature generated based on the spending private key.

[0559] Statement 10. The method of statement 3 or any statement dependent thereon, wherein a third condition of the one or more conditions is that the withdrawal transaction comprises an input comprising a signature generated based on the issuing private key.

[0560] Statement 11. The method of any preceding statement, wherein the redeemer is associated with a redemption private key-public key pair, and a fourth condition of the one or more conditions is that the spend transaction comprises a further input, the further input comprising a signature generated based on the redemption private key.

[0561] Statement 12. The method of any preceding statement, comprising obtaining a deposit transaction, the deposit transaction comprising an input that references the output of the consume transaction and comprises one or more of a signature generated based on the issuing private key, a signature generated based on the consuming private key, and / or a signature based on the redeeming private key; and, in response to one or more conditions being satisfied, transmitting the deposit transaction to a redeemer, a third party, and / or a blockchain network to be recorded on the blockchain.

[0562] Statement 13. The method of any preceding statement, comprising the steps of obtaining a blinded version of a coin seed generated at least in part by a consumer, the coin seed for generating a set of coin serial numbers, each coin serial number representing a respective digital coin; generating a blinded signature of the coin seed; and transmitting the blinded signature of the coin seed to the consumer.

[0563] In some examples, the blind signature may be a blind signature of the coin serial number, which by extension is still on the seed.

[0564] Statement 14. The method of statement 13, wherein the coin seed is generated at least in part by the issuer.

[0565] Statement 15. The method of any of statements 12 to 14, comprising the steps of obtaining a candidate coin seed proof and / or a candidate coin seed signature proof, where the candidate coin seed proof represents knowledge of the candidate coin seed and the candidate coin seed signature proof represents knowledge of a candidate signature of the coin seed; determining whether a candidate signature represented by the candidate seed proof is a blinded signature of the coin seed, where a fifth condition of the one or more conditions is that the candidate signature represented by the candidate seed proof is a blinded signature of the coin seed; and / or determining whether a candidate coin seed represented by the candidate coin seed proof is a coin seed, where a sixth condition of the one or more conditions is that the candidate coin seed is a coin seed.

[0566] The candidate coin seed proof and the coin seed signature proof may be zero-knowledge proofs. In some examples, the candidate seed proof comprises a generated signature of the coin seed.

[0567] Statement 16. The method of any preceding statement, wherein the redeemer is associated with a known identifier, and the method comprises the steps of obtaining a candidate identifier proof, the candidate identifier proof representing the redeemer's knowledge of the candidate identifier, and determining whether the candidate identifier represented by the candidate identifier proof is a known identifier of the redeemer, wherein a seventh condition of the one or more conditions is that the candidate identifier represented by the candidate identifier proof is a known identifier of the redeemer.

[0568] Statement 17. The method of any preceding statement, wherein a first coin serial number is associated with a respective counter value, and the method comprises the steps of obtaining a counter proof candidate, the counter proof candidate representing knowledge of the counter candidate for the first coin serial number, and determining whether the counter value candidate represented by the counter proof candidate is within a predetermined range, wherein an eighth condition of the one or more conditions is that the counter value candidate represented by the counter proof candidate is within the predetermined range.

[0569] Statement 18. The method of any preceding statement, comprising the steps of obtaining a blinded version of at least one dual consumption seed generated by a consumer, the at least one dual consumption seed for generating at least one dual consumption value, each dual consumption value based on the dual consumption seed, the consumer's identifier, and a respective data item selected by a redeemer, each dual consumption value revealing a different component of the consumer's identifier for each different data item; generating a blinded signature of the at least one dual consumption seed; and transmitting the blinded signature of the at least one dual consumption seed to the consumer.

[0570] In some examples, the same signature signs the coin seed and at least one double-spend seed.

[0571] Statement 19. The method of statement 18, comprising the steps of obtaining a double spend value and, in response to determining that the first coin serial number is present in a database of spent coin serial numbers, revealing an identifier of the consumer using the obtained double spend value and a previously obtained double spend value.

[0572] Statement 20. The method of statements 4 and 19, wherein the withdrawal transaction comprises a plurality of outputs, each output comprising a hash of a respective one of a set of coin serial numbers, each output locked to an issuing public key, and wherein the method comprises consuming each output locked to the issuing public key in response to determining that the first coin serial number is present in a database of consumed coin serial numbers.

[0573] Statement 21. The method of statements 6 and 19, wherein the spending transaction comprises an output comprising a hash of each coin serial number of the set of coin serial numbers, and wherein the method comprises, in response to determining that the first coin serial number is present in the database of spent coin serial numbers, consuming the output comprising the hash of each coin serial number of the set of coin serial numbers and / or publishing each coin serial number of the set of coin serial numbers.

[0574] For example, the coin that was double-spent may not yet be on-chain, i.e., it may be in some hash. This occurs when the hash of all coin serial numbers is not yet on-chain, since the spend transaction includes the hash of the next coin. Therefore, the bank may broadcast the serial number to prevent the next coin from being spent.

[0575] Statement 22. The method of any preceding statement, wherein the issuer maintains a record of identifier hashes, and the method comprises obtaining the identifier hash, the identifier hash being a hash of at least the redeemer's identifier and a data item selected by the redeemer, and a ninth condition of the one or more conditions is that the obtained hash does not exist in the database of identifier hashes.

[0576] Statement 23. The method of statement 22, wherein a record of the identifier hashes is maintained on a blockchain.

[0577] Statement 24. A computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin representing an amount of an asset redeemable by a redeemer in exchange for the digital coin, the method being executed by the consumer, the method comprising: obtaining a withdrawal transaction, the withdrawal transaction having one or more outputs, each output comprising a hash of a respective coin serial number of a set of coin serial numbers, each coin serial number representing a respective digital coin; and transmitting the withdrawal transaction to the redeemer, a third party, and / or the blockchain network for recording on the blockchain.

[0578] Statement 25. The method of statement 24, wherein the consumer is associated with a spending private key-public key pair, and wherein said obtaining a withdrawal transaction comprises generating a withdrawal transaction, the withdrawal transaction comprising an input comprising a signature generated based on the spending private key.

[0579] Statement 26. The method of statement 24, wherein the issuer is associated with an issuing private key-public key pair, the withdrawal transaction is generated by the issuer, the withdrawal transaction comprises an input comprising a signature generated based on the issuing private key, and said obtaining the withdrawal transaction comprises obtaining the withdrawal transaction from the issuer or from a blockchain.

[0580] Statement 27. The method of any of statements 24 to 26, wherein a first output of the one or more outputs of the withdrawal transaction comprises a hash of a first coin serial number of a set of coin serial numbers, and the method comprises generating the first coin serial number based on a coin seed.

[0581] Statement 28. The method of statement 27, wherein the coin seed is generated at least in part by the issuer.

[0582] Statement 29. The method of statement 24 or statement 28, comprising the steps of sending a blinded version of the coin seed to the issuer and receiving a blinded signature of the coin seed from the issuer.

[0583] Statement 30. The method of statement 29, comprising transmitting a coin seed proof to a redeemer, the coin seed proof representing knowledge of a blind signature over the coin seed.

[0584] Statement 31. The method of any of statements 24 to 30, wherein the first coin serial number is associated with a respective counter value, and the method comprises transmitting a counter proof to a redeemer, the counter proof representing knowledge of the counter value of the first coin serial number.

[0585] Statement 32. The method of statement 27 or any statement dependent thereon, comprising transmitting the first coin serial number to a redeemer.

[0586] Statement 33. The method of any of statements 24 through 32, comprising transmitting one or more dual consumption values to a redeemer, the one or more dual consumption values being based on one or more respective dual consumption seeds, a consumer identifier, and respective data items selected by the redeemer, each dual consumption value revealing a different component of the consumer identifier for a different respective data item.

[0587] Statement 34. The method of statement 33, comprising obtaining each data item from a redeemer.

[0588] Statement 35. The method of statement 33 or statement 34, comprising transmitting one or more dual consumption value proofs to a redeemer, the one or more dual consumption value proofs representing knowledge of a signature for a dual consumption value and / or knowledge of one or more dual consumption values, respectively.

[0589] Statement 36. The method of statement 35, wherein the double spend value is associated with a double spend counter value, and the method comprises transmitting a double spend counter proof to a redeemer, the double spend counter proof representing knowledge of the double spend counter value of the double spend value.

[0590] Statement 37. The method of any of statements 24 to 36, comprising obtaining a spend transaction, the spend transaction comprising a first input for unlocking a first output of the withdrawal transaction, the first input comprising a signature generated based on the spend private key; and transmitting the spend transaction to a redeemer, a third party, and / or a blockchain network to be recorded on the blockchain.

[0591] Statement 38. The method of statement 37, wherein the first input of the spending transaction comprises a first coin serial number.

[0592] To prevent the bank from spending the withdraw output, a serial number can be used to lock the output of the withdraw transaction (this is desirable in the case of double-spends). Without a serial number to lock the output, the bank can spend the output at any time, not just in the case of double-spends. This is less secure, but is not an issue if the bank is trustworthy. The coin serial number is also present in the OP_RETURN output of the spend transaction, so even if it is not in the withdraw transaction locking script, it will be found as spent in the OP_RETURN output.

[0593] Statement 39. The method of statement 37 or statement 38, wherein the spend transaction comprises a first output comprising a signature generated based on the redemption private key.

[0594] Statement 40. The method of any of statements 37-39, wherein the spend transaction comprises a second output comprising a hash of a second coin serial number from the set of coin serial numbers.

[0595] Statement 41. A computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued by an issuer to a consumer, and each digital coin represents an amount of an asset redeemable by a redeemer in exchange for the digital coin, the method being performed by the redeemer and comprising the steps of: obtaining a first coin serial number from the consumer; determining whether the first coin serial number exists on the blockchain; and, in response to one or more conditions being satisfied, obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising the first coin serial number; and transmitting the spend transaction to one or more of the consumer, the issuer, a third party, and / or the blockchain network to be recorded on the blockchain, wherein a first condition of the one or more conditions is that the first coin serial number does not exist on the blockchain.

[0596] Statement 42. The method of statement 41, wherein the redeemer is associated with a redemption private key-public key pair, and the spend transaction comprises a first input comprising a signature generated based on the redemption private key.

[0597] Statement 43. The method of statement 41 or statement 42, wherein the consumer is associated with a consumption private key-public key pair, and the consumption transaction comprises a second input comprising a signature generated based on the consumption private key.

[0598] Statement 44. The method of statement 43, wherein the second input of the consume transaction is configured to unlock the output of the withdraw transaction.

[0599] Statement 45. The method of statement 44, wherein the second input comprises a first coin serial number.

[0600] Statement 46. The method of statement 44 or statement 45, wherein the issuer is associated with a private key-public key pair, and a second condition of the one or more conditions is that the withdrawal transaction comprises an input comprising a signature generated based on the issuing private key.

[0601] Statement 47. The method of any of statements 41-46, comprising obtaining a coin seed signature certificate and / or a candidate coin seed certificate from a consumer, wherein the coin seed signature certificate represents knowledge of a blinded signature of a coin seed used to generate the first coin serial number, and the candidate coin seed signature certificate represents knowledge of the candidate coin seed, and wherein a second condition of the one or more conditions is that the blinded signature is generated by the issuer, and / or a third condition of the one or more conditions is that the candidate coin seed is a coin seed.

[0602] Statement 48. The method of any of statements 41 to 47, wherein a first coin serial number is associated with a respective counter value, and the method comprises the steps of obtaining a counter proof candidate, the counter proof candidate representing knowledge of the counter proof candidate for the first coin serial number, and determining whether the counter value candidate represented by the counter proof candidate is within a predetermined range, wherein a third condition of the one or more conditions is that the counter value candidate represented by the counter proof candidate is within the predetermined range.

[0603] Statement 49. The method of any of statements 41 through 48, comprising obtaining one or more dual consumption values from a consumer, the one or more dual consumption values being based on a respective dual consumption seed, an identifier of the consumer, and a respective data item selected by the redeemer, each dual consumption value revealing a different component of the consumer's identifier for a different respective data item.

[0604] Statement 50. The method of statement 49, comprising obtaining one or more dual consumption seed certificates from a consumer, the one or more dual consumption seed certificates representing knowledge of a blinded signature for each of one or more dual consumption seeds used to generate one or more dual consumption values, and a fourth condition of the one or more conditions being that each blinded signature is generated by an issuer.

[0605] Statement 51. The method of statement 49 or statement 50, wherein each duplication value is associated with a respective duplication counter value, and the method comprises the steps of: for each duplication value, obtaining a candidate duplication counter proof, the candidate duplication counter proof representing knowledge of the candidate duplication counter for that duplication value; and determining whether the candidate duplication counter value represented by the candidate duplication counter proof is within a predetermined range, and a fifth condition of the one or more conditions is that the candidate duplication counter value represented by the candidate duplication counter proof is within the predetermined range.

[0606] Statement 52. The method of any of statements 49 through 51, wherein the consumption transaction comprises one or more obtained dual consumption values.

[0607] Statement 53. The method of any of statements 49 to 52, comprising generating each data item.

[0608] Statement 54. The method of any of statements 49 to 53, comprising transmitting each data item to a consumer.

[0609] Statement 55. The method of any of statements 41 through 54, comprising the steps of obtaining an identifier hash from the consumer, the identifier hash being a hash of at least the redeemer's identifier and a data item selected by the redeemer, and transmitting the obtained identifier hash to the issuer.

[0610] Statement 56. The method of any of statements 41-55, comprising obtaining a deposit transaction, the deposit transaction comprising an input that references the output of the consume transaction and comprises one or more of a signature generated based on the redemption private key, a signature generated based on the consume private key, and / or a signature generated based on the issue private key; and, in response to one or more conditions being satisfied, transmitting the deposit transaction to the issuer, a third party, and / or the blockchain network to be recorded on the blockchain.

[0611] Statement 57. The method of statement 56, wherein the deposit transaction comprises an output locked to the issuing public key.

[0612] Statement 58. The method of any of statements 41 to 57, comprising, in response to determining that at least one of the one or more conditions is not satisfied, transmitting to the issuer one or more of the first coin serial number, the spend public key, the one or more dual spend values, and / or the consumer's identifier.

[0613] Statement 59. A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, wherein the memory stores code adapted to execute on the processing device, and the code, when executed on the processing device, is configured to perform the method of any of statements 1 to 58.

[0614] Statement 60. A computer program embodied on a computer-readable storage and configured to perform the method of any of statements 1 to 58 when executed on the computing device of statement 46.

[0615] According to another aspect disclosed herein, a method may be provided that comprises issuer, consumer, and redeemer actions.

[0616] According to another aspect disclosed herein, a system may be provided that includes computer devices of an issuer, a consumer, and a redeemer.

[0617] 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 not limited by the described embodiments, but only by the appended claims. [Explanation of symbols]

[0618] 101 Network 102 Computer Equipment 103 users 104 nodes 105 Client Applications 106 P2P networks 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 201 Header 202 Input 203 Output 301 Side Channel 401 Transaction Engine 402 UI layer 411 UI Elements, User Selectable Elements 412 UI elements 413 UI elements 601 Issuer 602 Consumer 603 Redeemer< / g>

Claims

1. 1. A computer-implemented method for implementing a system for issuing digital coins using blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin represents an amount of an asset redeemable by a redeemer in exchange for said digital coin, said issuer maintains a record of coin serial numbers, each coin serial number representing a respective digital coin, said method being performed by said issuer; obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising a first coin serial number of a set of coin serial numbers; determining whether the first coin serial number is present in a database of spent coin serial numbers; and transferring the amount of the asset represented by the first coin serial number to the redeemer in response to one or more conditions being satisfied, wherein a first of the one or more conditions is that the first coin serial number does not exist in the database.

2. 10. The method of claim 1, wherein the record of coin serial numbers is maintained on the blockchain.

3. 3. The method of claim 1 or 2, wherein the consume transaction comprises an output locked to the issuer's issuing public key, and wherein the obtaining of the send transaction comprises obtaining the consume transaction from the consumer and / or from the blockchain.

4. 3. The method of claim 1 or 2, wherein the blockchain comprises withdrawal transactions, the withdrawal transactions comprising one or more outputs, each output comprising an indication of a respective coin serial number of the set of coin serial numbers.

5. 5. The method of claim 4, wherein the indicia is a hash of each coin serial number in the set of coin serial numbers.

6. the issuer is associated with an issuing private key-public key pair, and the method comprises: generating the withdrawal transaction, the withdrawal transaction comprising an input comprising a signature generated based on the issuing private key; and transmitting the withdrawal transaction to the consumer, a third party, and / or the blockchain network to be recorded on the blockchain.

7. 7. The method of claim 4, wherein a second condition of the one or more conditions is that the consume transaction comprises an input to unlock an output of a withdraw transaction.

8. 8. The method of claim 7, wherein the output of the withdrawal transaction, when executed with an input of a later transaction, is configured to require that the input of the later transaction require the first coin serial number.

9. 9. The method of claim 6, wherein the consumer is associated with a spending private key-public key pair and is configured to require that the output of the withdrawal transaction, when executed with an input of a later transaction, require that the input of the later transaction require a signature generated based on the spending private key.

10. 3. The method of claim 3 or any claim dependent thereon, wherein a third condition of the one or more conditions is that the withdrawal transaction comprises an input comprising the signature generated based on the issuing private key.

11. 11. The method of claim 1, wherein the redeemer is associated with a private-public redemption key pair, and a fourth condition of the one or more conditions is that the consumption transaction comprises a further input, the further input comprising a signature generated based on the private redemption key.

12. obtaining a deposit transaction, the deposit transaction comprising an input that references an output of the consume transaction and comprises one or more of a signature generated based on the issuing private key, a signature generated based on the consuming private key, and / or a signature based on the redemption private key; and in response to one or more conditions being met, transmitting the deposit transaction to the redeemer, a third party, and / or the blockchain network to be recorded on the blockchain.

13. obtaining a blinded version of a coin seed generated at least in part by the consumer, the coin seed being for generating a set of coin serial numbers, each coin serial number representing a respective digital coin; generating a blind signature of the coin seed; and transmitting the blind signature of the coin seed to the consumer.

14. The method of claim 13 , wherein the coin seed is generated at least in part by the issuer.

15. obtaining a candidate coin seed proof and / or a candidate coin seed signature proof, wherein the candidate coin seed proof represents knowledge of a candidate coin seed and the candidate coin seed signature proof represents knowledge of a candidate coin seed signature; determining whether the candidate signature represented by the candidate seed proof is the blinded signature of the coin seed, wherein a fifth condition of the one or more conditions is that the candidate signature represented by the candidate seed proof is the blinded signature of the coin seed; and / or 15. A method according to any one of claims 12 to 14, comprising a step of determining whether the coin seed candidate represented by the coin seed proof candidate is the coin seed, wherein a sixth condition of the one or more conditions is that the coin seed candidate is the coin seed.

16. the redeemer is associated with a known identifier, and the method comprises: obtaining a candidate identifier proof, the candidate identifier proof representing the redeemer's knowledge of the candidate identifier; and determining whether the candidate identifier represented by the candidate identifier proof is the known identifier of the redeemer, wherein a seventh condition of the one or more conditions is that the candidate identifier represented by the candidate identifier proof is the known identifier of the redeemer.

17. the first coin serial number being associated with a respective counter value, and the method comprising: obtaining a counter proof candidate, the counter proof candidate representing counter proof candidate knowledge of the first coin serial number; and determining whether the candidate counter value represented by the candidate counter proof is within a predetermined range, wherein an eighth condition of the one or more conditions is that the candidate counter value represented by the candidate counter proof is within a predetermined range.

18. obtaining a blinded version of at least one dual consumption seed generated by the consumer, the at least one dual consumption seed being used to generate at least one dual consumption value, each dual consumption value being based on the dual consumption seed, the consumer's identifier, and a respective data item selected by the redeemer, each dual consumption value revealing a different component of the consumer's identifier for a different respective data item; generating a blind signature of the at least one double consumption seed; and transmitting the blind signature of the at least one dual consumption seed to the consumer.

19. obtaining a dual consumption value; and in response to determining that the first coin serial number is present in the database of spent coin serial numbers, revealing the identifier of the consumer using the obtained dual spend value and a previously obtained dual spend value.

20. 20. The method of claims 4 and 19, wherein the withdrawal transaction comprises a plurality of outputs, each output comprising a hash of a respective one of the set of coin serial numbers, each output locked to the issuing public key, and the method comprises consuming each output locked to the issuing public key in response to determining that the first coin serial number is present in the database of consumed coin serial numbers.

21. 20. The method of claims 6 and 19, wherein the consuming transaction comprises an output comprising a hash of each coin serial number in the set of coin serial numbers, and wherein the method comprises, in response to determining that the first coin serial number is present in the database of consumed coin serial numbers, consuming the output comprising the respective hash of the each coin serial number in the set of coin serial numbers and / or publishing the each coin serial number in the set of coin serial numbers.

22. the issuer maintains a record of identifier hashes, and the method comprises:

22. The method of claim 1, further comprising obtaining an identifier hash, the identifier hash being a hash of at least the redeemer's identifier and a data item selected by the redeemer, and a ninth condition of the one or more conditions being that the obtained hash does not exist in the database of identifier hashes.

23. 23. The method of claim 22, wherein the record of identifier hashes is maintained on the blockchain.

24. 1. A computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued by an issuer to a consumer, each digital coin representing an amount of an asset redeemable by a redeemer in exchange for said digital coin, said method being performed by said consumer; obtaining a withdrawal transaction, the withdrawal transaction comprising one or more outputs, each output comprising a hash of a respective coin serial number of a set of coin serial numbers, each coin serial number representing a respective digital coin; transmitting the withdrawal transaction to the redeemer, a third party, and / or the blockchain network to be recorded on the blockchain.

25. 25. The method of claim 24, wherein the consumer is associated with a consuming private key-public key pair, and wherein the obtaining of the withdrawal transaction comprises generating the withdrawal transaction, the withdrawal transaction comprising an input comprising a signature generated based on the consuming private key.

26. 25. The method of claim 24, wherein the issuer is associated with an issuing private key-public key pair, the withdrawal transaction is generated by the issuer, the withdrawal transaction comprises an input comprising a signature generated based on the issuing private key, and the obtaining the withdrawal transaction comprises obtaining the withdrawal transaction from the issuer or from the blockchain.

27. 27. The method of any of claims 24 to 26, wherein a first output of the one or more outputs of the withdrawal transaction comprises a hash of a first coin serial number of the set of coin serial numbers, the method comprising generating the first coin serial number based on a coin seed.

28. 28. The method of claim 27, wherein the coin seed is generated at least in part by the issuer.

29. sending a blinded version of the coin seed to the issuer; and receiving a blind signature of the coin seed from the issuer.

30. 30. The method of claim 29, comprising transmitting a coin seed proof to the redeemer, the coin seed proof representing knowledge of the blinded signature over the coin seed.

31. 31. A method according to any of claims 24 to 30, wherein the first coin serial numbers are associated with respective counter values, the method comprising the step of transmitting a counter proof to the redeemer, the counter proof representing knowledge of the counter value of the first coin serial number.

32. 28. A method according to claim 27 or any claim dependent thereon, comprising the step of transmitting the first coin serial number to the redeemer.

33. 33. A method according to any of claims 24 to 32, comprising the step of transmitting one or more dual consumption values to the redeemer, the one or more dual consumption values being based on one or more respective dual consumption seeds, an identifier of the consumer, and respective data items selected by the redeemer, each dual consumption value revealing a different component of the identifier of the consumer for a different respective data item.

34. 34. The method of claim 33, comprising obtaining the respective data item from the redeemer.

35. 35. A method according to claim 33 or 34, comprising the step of transmitting one or more dual consumption value proofs to the redeemer, wherein the one or more dual consumption value proofs represent knowledge of a signature for the dual consumption value and / or knowledge of the one or more dual consumption values, respectively.

36. 36. The method of claim 35, wherein the double spend value is associated with a double spend counter value, the method comprising the step of transmitting a double spend counter proof to the redeemer, the double spend counter proof representing knowledge of the double spend counter value of the double spend value.

37. obtaining a spend transaction, the spend transaction comprising a first input for unlocking the first output of the withdraw transaction, the first input comprising a signature generated based on the spend private key; and transmitting the consumption transaction to the redeemer, a third party, and / or the blockchain network to be recorded on the blockchain.

38. 38. The method of claim 37, wherein the first input of the spending transaction comprises the first coin serial number.

39. 39. The method of claim 37 or 38, wherein the consumption transaction comprises a first output comprising a signature generated based on the redemption private key.

40. 40. The method of any of claims 37 to 39, wherein the spend transaction comprises a second output comprising a hash of a second coin serial number of the set of coin serial numbers.

41. 1. A computer-implemented method for implementing a system for issuing digital coins using a blockchain, wherein each digital coin is issued to a consumer by an issuer, each digital coin represents an amount of an asset redeemable by a redeemer in exchange for said digital coin, said method being performed by said redeemer; obtaining a first coin serial number from the consumer; determining whether the first coin serial number exists in the blockchain; 1. A method comprising: in response to one or more conditions being satisfied, obtaining a spend transaction, the spend transaction being a blockchain transaction and comprising a first coin serial number; and transmitting the spend transaction to one or more of the consumer, the issuer, a third party, and / or the blockchain network to be recorded on the blockchain, wherein a first condition of the one or more conditions is that the first coin serial number does not exist on the blockchain.

42. 42. The method of claim 41, wherein the redeemer is associated with a private-public redemption key pair, and the consumption transaction comprises a first input comprising a signature generated based on the private redemption key.

43. 43. The method of claim 41 or 42, wherein the consumer is associated with a consumption private key-public key pair, and the consumption transaction comprises a second input comprising a signature generated based on the consumption private key.

44. 44. The method of claim 43, wherein the second input of the consume transaction is configured to unlock an output of a withdraw transaction.

45. 45. The method of claim 44, wherein the second input comprises the first coin serial number.

46. 46. The method of claim 44 or 45, wherein the issuer is associated with a private-public key pair, and a second of the one or more conditions is that the withdrawal transaction comprises an input comprising a signature generated based on the issuing private key.

47. 47. A method according to any of claims 41 to 46, comprising the step of obtaining a coin seed signature certificate and / or a candidate coin seed certificate from the consumer, wherein the coin seed signature certificate represents knowledge of a blinded signature of a coin seed used to generate the first coin serial number, and the candidate coin seed signature certificate represents knowledge of a candidate coin seed, wherein a second condition of the one or more conditions is that the blinded signature is generated by the issuer, and / or a third condition of the one or more conditions is that the candidate coin seed is the coin seed.

48. the first coin serial number being associated with a respective counter value, and the method comprising: obtaining a counter proof candidate, the counter proof candidate representing counter candidate knowledge of the first coin serial number; and determining whether the candidate counter value represented by the candidate counter proof is within a predetermined range, wherein a third condition of the one or more conditions is that the candidate counter value represented by the candidate counter proof is within a predetermined range.

49. 49. A method according to any of claims 41 to 48, comprising obtaining one or more dual consumption values from the consumer, the one or more dual consumption values being based on a respective dual consumption seed, an identifier of the consumer, and respective data items selected by the redeemer, each dual consumption value revealing a different component of the identifier of the consumer for a different respective data item.

50. 50. The method of claim 49, further comprising obtaining one or more dual consumption seed certificates from the consumer, the one or more dual consumption seed certificates representing knowledge of blinded signatures of each of the one or more dual consumption seeds used to generate the one or more dual consumption values, and a fourth condition of the one or more conditions being that the respective blinded signatures are generated by the issuer.

51. Each duplication value is associated with a respective duplication counter value, and the method comprises, for each duplication value: obtaining a candidate doubling counter proof, said candidate doubling counter proof representing the candidate doubling counter's knowledge of its doubling value; and determining whether the candidate double consumption counter value represented by the candidate double consumption counter proof is within a predetermined range, wherein a fifth condition of the one or more conditions is that the candidate double consumption counter value represented by the candidate double consumption counter proof is within the predetermined range.

52. 52. The method of any of claims 49 to 51, wherein the consumption transaction comprises the obtained one or more dual consumption values.

53. 53. A method according to any of claims 49 to 52, comprising generating said respective data items.

54. 54. A method according to any of claims 49 to 53, comprising the step of transmitting said respective data item to said consumer.

55. obtaining an identifier hash from the consumer, the identifier hash being a hash of at least the redeemer's identifier and a data item selected by the redeemer; and sending the obtained identifier hash to the issuer.

56. obtaining a deposit transaction, the deposit transaction comprising an input that references an output of the spend transaction and comprises one or more of a signature generated based on the redemption private key, a signature generated based on the spend private key, and / or a signature generated based on the issue private key; and in response to the one or more conditions being satisfied, transmitting the deposit transaction to the issuer, a third party, and / or the blockchain network to be recorded on the blockchain.

57. 57. The method of claim 56, wherein the deposit transaction comprises an output locked to the issuing public key.

58. 58. The method of any of claims 41 to 57, comprising the step of transmitting one or more of the first coin serial number, the spending public key, the one or more dual spending values, and / or the identifier of the consumer to the issuer in response to determining that at least one of the one or more conditions is not satisfied.

59. a memory comprising one or more memory units; 59. A computing apparatus comprising: a processing unit having one or more processing units; and the memory storing code adapted to execute on the processing unit, the code configured, when executed on the processing unit, to perform the method of any of claims 1 to 58.

60. A computer program embodied on a computer readable storage and configured to perform the method of any of claims 1 to 58 when executed on a computing device according to claim 46.

Images