A method for implementing a digital coin system using blockchain

Abstract

A computer-implemented method for implementing a system for issuing digital coins using blockchain, wherein each digital coin is issued by an issuer and represents an amount of assets redeemable by a redeemer in exchange for the digital coins, the issuer maintains a record of coin serial numbers, each coin serial number representing a respective digital coin, the method comprising the steps of: obtaining a spend transaction executed by the issuer 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; and transferring assets in an amount represented by the first coin serial number to the redeemer in response to one or more conditions being satisfied, a first of the conditions being that the first coin serial number does not exist in the database.

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 Art

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

[0003] Transactions in a blockchain are used to carry digital assets, i.e., a number of digital tokens. However, a blockchain can also be utilized to overlay additional functionality on top of the blockchain. For example, a blockchain protocol may enable additional user data to be stored in the output of a transaction. Recent blockchains have increased the maximum data capacity that can be stored in a single transaction, enabling 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 of three roles: transfer, mining, and storage. Transfer nodes spread transactions across all nodes of the network. Mining nodes perform the mining of transactions into blocks. Storage nodes each store a unique copy of the mined blocks of the blockchain. To record a transaction on the blockchain, a party sends the transaction to one of the nodes of the network to be spread. A mining node that receives a transaction can compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not spread and are not mined into blocks. Assuming that the validity of a transaction is confirmed and thus accepted into the blockchain, the transaction (including any user data) then 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 to create the latest block are typically rewarded with a new transaction called a "coinbase transaction" that generates a new amount of digital assets. Proof-of-work gives miners an incentive not to cheat the system by including double-spend transactions in their blocks, as it requires a large amount of computational resources to mine a block and blocks containing attempts at double-spending are likely not to be accepted by other nodes.

[0006] In an "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction consists of one or more inputs and one or more outputs. Any spendable output comprises an element that specifies an amount of digital assets, which may be called a UTXO ("unspent transaction output"). The output may further comprise a locking script that specifies the conditions for redeeming the output. Each input comprises a pointer to such an output in a previous transaction and may further comprise an unlocking script for unlocking the locking script of the indicated output. Thus, consider a pair of transactions, and call them the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output that specifies an amount of digital assets, which 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 an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when the second target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node is that the unlocking script satisfies all of the 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 valid transaction. Any node that deems the target transaction invalid according to any of these conditions will neither propagate the transaction nor include the transaction in a block for mining to be recorded in the blockchain.

Prior Art Documents

Non-Patent Documents

[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] [Problems 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 more implementations, but none of them have been able to reproduce a fiat currency system. It should be noted that ecash, in its conventional form, does not utilize a blockchain. [Means for Solving the Problems]

[0010] One of the biggest problems with the ecash system (and digital coin systems in general) is that it is vulnerable to "double spending," which means it is very easy to copy and spend the same ecash (or digital coin) again. This has prevented all previous systems from being widely adopted.

[0011] According to one aspect disclosed herein, a computer-implemented method for implementing a system for issuing digital coins using a blockchain is provided, each digital coin being issued by an issuer to a consumer, each digital coin representing an amount of assets that can be exchanged by an exchanger in exchange for the digital coin, the issuer maintaining 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 consumption transaction, the consumption 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 consumed coin serial numbers, and transferring, in response to one or more conditions being met, the amount of assets represented by the first coin serial number to the exchanger, 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 the consumed digital coins. The issuer may receive the consumption transaction directly from the exchanger from the blockchain or from another source. If the first coin serial number exists in the database, the corresponding digital coin has been previously consumed and the consumer or exchanger 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 consumed and the issuer may accept the coin, which may also be conditional upon some other criterion being met.

[0013] According to another aspect disclosed herein, a computer-implemented method for implementing a system for issuing digital coins using a blockchain is provided, each digital coin being issued by an issuer to a consumer, each digital coin representing an amount of an asset that can be exchanged by an exchanger in exchange for the digital coin, the method being executed by a consumer and comprising the steps of obtaining a withdrawal transaction, the withdrawal transaction comprising 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 an exchanger, a third party, and / or a blockchain network for recording on the blockchain.

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

[0015] The withdrawal transaction also functions as a record of the consumer having been issued a set of digital coins, each coin having a unique serial number. Since the withdrawal transaction can be issued by the issuer to the consumer, it can enable the issuer to trace the origin of the consumed coins to the consumer. Alternatively, the consumer can generate the withdrawal transaction.

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

[0017] The exchanger checks whether the first coin serial number exists on the blockchain. As described above, if the first coin serial number exists on the blockchain, it means that the consumer has previously consumed the relevant digital coin. If the first coin serial number does not exist on the blockchain, the exchanger can be confident that the relevant digital coin has not been consumed.

[0018] The present invention provides a system for implementing a digital coin system (e.g., an ecash system) on a blockchain. Advantageously, by utilizing the characteristics of the blockchain, the security of the digital coin system is enhanced. Specifically, due to two basic characteristics of the blockchain, the double-spending security of the proposed system is improved compared to previous systems. The first property utilized is that a transaction output has a binary state of being consumed or not consumed. When the output represents a coin, the coin is only accepted in the system's spending and deposit protocols if the corresponding output has not been consumed (as described below). This property is used to prevent double-spending. The second property used is the fact that the blockchain is a distributed immutable database. The blockchain can be used to store the serial numbers of coins that have been consumed and are on a blacklist, and anyone can access this if necessary.

[0019] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be implemented, reference is made, by way of example only, to the accompanying drawings.

Brief Description of the Drawings

[0020]

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7a

Figure 7b

Figure 8a

Figure 8b

Figure 9a

Figure 9b

Figure 10a

Figure 10b

Figure 11a

Figure 11b

Figure 12a

Figure 12b

Figure 13a

Figure 13b

Figure 13c

Figure 14a

Figure 14b

Figure 14c

Figure 15a

Figure 15b

Figure 15c

Figure 16a

Figure 16b

Figure 16c

Figure 17a

Figure 17b

Figure 17c

Figure 18a

Figure 18b

Figure 18c

Figure 19a

Figure 19b

Figure 19c

Figure 20a

Figure 20b

Figure 20c

[0021] Exemplary System Overview FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switching network 101, typically a wide area network such as the Internet. The packet-switching network 101 includes a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switching network 101. Each node 104 includes a peer computer device, and different nodes of the nodes 104 belong to different peers. Each node 104 includes a processing device including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field programmable gate arrays (FPGAs). Each node also includes a memory in the form of a non-transitory computer-readable medium, i.e., computer-readable storage. The memory may include one or more memory units utilizing one or more memory media, such as 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 data blocks 151, and a respective copy of the blockchain 150 is maintained at each of a plurality of nodes in the P2P network 160. Each block 151 in the chain comprises one or more transactions 152, and a transaction in this context refers to a certain type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an 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 exchanged or consumed). Each input refers to an output of a preceding transaction 152, thereby linking multiple transactions together.

[0023] At least some of the nodes 104 assume the role of forwarding nodes 104F that transfer and thereby spread the transactions 152. At least some of the nodes 104 assume the role of miners 104M that mine the blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes also 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 that are waiting to be mined into a block 151. A given node 104 can be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0024] In a given current transaction 152j, each of its inputs comprises a pointer that references an output of a previous transaction 152i in the sequence of transactions, which designates that this output should be redeemed or "spent" in the current transaction 152j. Generally, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i need not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but the previous transaction 152i must exist and be verified for validity for the current transaction to be valid. Thus, "previous" as used herein refers to the predecessor in the logical order linked by the pointer and does not necessarily refer to the time of creation or transmission in chronological order, so it does not necessarily exclude the possibility that transactions 152i, 152j are created or sent in a different order (see the following discussion on orphan transactions). The previous transaction 152i may also be equally referred to as an ancestor transaction or a preceding transaction.

[0025] The input of the current transaction 152j also comprises the signature of user 103a to which the output of the preceding transaction 152i is locked. And the output of the current transaction 152j can be cryptographically locked to a 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, transaction 152 can have multiple outputs in order to divide the amount input among multiple users (one of the multiple users can be the original user 103a for giving change). In some cases, the transaction can also have multiple inputs in order to gather together amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0026] The above is sometimes referred to as an “output-based” transaction protocol and sometimes as an unspent transaction output (UTXO) type protocol (in which case the outputs are called UTXOs). The total balance of a user is not defined by any one number stored in the blockchain. Instead, the user requires a special “wallet” application 105 to reconcile the value of all of the user's UTXOs scattered across many different transactions 152 in the blockchain 151.

[0027] Alternative types of transaction protocols may be referred to as "account-based" protocols as part of the account-based transaction model. In the case of account-based, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXOs of previous transactions in the sequence of past transactions. The current state of all accounts is stored by the miner separately from the blockchain and updated periodically. In such a system, transactions are ordered using the transaction tally of the account (also called the "position") being executed. This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field of the transaction may also be signed. This data field may refer to a previous transaction, for example if the previous transaction ID is included in the data field.

[0028] When user 103 wishes to define a new transaction 152j, regardless of the type of transaction protocol, the user sends the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is usually a server or data center, but in principle could be another user terminal). This node 104 checks whether the transaction is legitimate according to the node protocol applied at each of the nodes 104. The details of the node protocol correspond to the type of transaction protocol used in the target blockchain 150 that together forms the overall transaction model. The node protocol typically requires the node 104 to verify that the cryptographic signature in the new transaction 152j matches the expected signature, where the expected signature depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of an output-based one, this may include verifying that the user's cryptographic signature included in the input of the new transaction 152j matches the conditions defined in the output of the preceding transaction 152i that the new transaction consumes, which usually includes at least verifying that the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i indicated by the input of the new transaction. In some transaction protocols, this condition may be at least partially defined by custom scripts included in the input and / or output. Alternatively, it may be determined solely by the node protocol, or by a combination of these. In any case, if the new transaction 152j is legitimate, 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 by applying the same test according to the same node protocol, so they forward the new transaction 152j to one or more additional nodes 104, and so on.In this way, the new transaction is spread across the entire network of node 104.

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

[0030] In addition to the validity confirmation, at least a part of node 104M also competes to first create a block of transactions in a process known as mining, which is supported by "proof of work". In the mining node 104M, new transactions are added to a pool of legitimate transactions that have not yet appeared in the block. The miner then attempts to assemble a new legitimate block 151 of transactions 152 from the pool of transactions 154 by trying 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 output of the hash meets a predetermined condition. For example, the predetermined condition could be that the output of the hash has a certain predetermined number of leading zeros. The nature of the hash function is such that it has an output that is unpredictable with respect to its input. Therefore, this search can only be performed by brute force and consumes a significant amount of processing resources at each node 104M attempting to solve the puzzle.

[0031] The first minor node 104M attempting to solve the puzzle notifies this to the network 106 and provides a solution as proof that can be easily verified later by other nodes 104 in the network (it is easy to verify that given a solution to a hash, the output of the hash meets the condition by that solution). And the pool of transactions 154 for which the winner has solved the puzzle is recorded as a new block 151 in the blockchain 150 based on each such node having verified the solution notified by the winner by at least some of the nodes 104 functioning as storage nodes 104S. The 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 spending, because creating a new block 151 requires a large amount of effort, and any block containing double spending may be rejected by other nodes 104, so the mining nodes 104M are motivated not to allow double spending to be included in those blocks. Once created, the block 151 cannot be modified, because it is recognized and maintained in each of the storage nodes 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes a sequential order on the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each storage node 104S in the P2P network 106, this thus provides an immutable public ledger of the transactions.

[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 that given time, depending on when the miner started looking for a solution. The first one to solve each puzzle defines which transactions 152 are included in the next new block 151n, and the current pool 154 of unmined transactions is updated. The miner 104M then continues to compete to create blocks from the newly defined prominent pool 154, and so on. There is also a protocol for resolving any possible "forks", which is a situation where two miners 104M solve the puzzle within a very short time of each other, thereby spreading conflicting views of the blockchain. That is, the one that has grown the longest among the prongs of the fork becomes the final blockchain 150.

[0033] In most blockchains, the winning miner 104M is automatically rewarded by a special type of new transaction that creates a new amount of digital assets out of nothing (as opposed to a normal transaction that transfers a certain amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "coinbase" transaction. It automatically forms part of the new block 151n. This reward gives the miner 104M an incentive to participate in the proof-of-work competition. To further reward the winning miner 104M that created the block 151n in which the transaction was included, ordinary (non-coinbase) transactions 152 often also specify an additional transaction fee in one of the outputs.

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

[0035] The memory of each node 104 stores software configured to execute on the processing device of the node 104 to perform their respective roles and handle transactions 152 according to the node protocol. It will be understood that any action attributed to a node 104 can be performed by software executed on the processing device of the respective computing device. The node software can be implemented in one or more applications of the application layer, or in lower layers such as the operating system layer or protocol layer, or any combination thereof. Also, the term "blockchain" as used herein is a general term referring to this type of technology in general and is not limited to any particular proprietary blockchain, protocol, or service.

[0036] Each of the computer devices 102 of the plurality of parties 103 that play the role of users who consume is also connected to the network 101. These function as payers and payees in a transaction, but do not necessarily participate in mining or spreading the transaction on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 can be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference herein to Alice and Bob can be replaced by "the first party" and "the second party", respectively.

[0037] The computer device 102 of each party 103 includes respective processing devices that include one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application - specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, i.e., computer - readable storage in the form of a non - transitory computer - readable medium. This memory may include one or more memory units that utilize one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memories, or EEPROMs, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software that includes respective instances of at least one client application 105 to be executed on the processing device. It will be understood that any action attributed to a given party 103 herein can be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other network - connected resources, such as cloud computing resources accessed via the user terminal.

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

[0039] The client application 105 has at least a "wallet" function. This has two main functions. One of these is to enable each user party 103 to create, sign, and send a transaction 152 so that it is spread across the entire 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 involves reconciling the amounts defined in the output to the various transactions 152 scattered across the entire blockchain 150 belonging to the party in question.

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

[0041] An instance of the client application or software 105 on each computer device 102 is operably coupled to at least one of the forwarding nodes 104F of the P2P network 106. This enables the wallet function of the client 105 to send the transaction 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 in order to query the blockchain 150 about any transaction for which each party 103 is the recipient (or to actually investigate the transactions of other parties in the blockchain 150, because in the embodiments, the blockchain 150 is a public institution that gives credit to some transactions by virtue of the transactions being publicly visible). The wallet function on each computer device 102 is configured to compose and send the transaction 152 according to a transaction protocol. Each node 104 executes software that is configured to verify the validity of the transaction 152 according to a node protocol and, in the case of the forwarding node 104F, forward the transaction 152 to spread the transaction across the entire network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is associated with a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (however, the transaction protocol may allow different subtypes of transactions therein). The same node protocol is used by all nodes 104 in the network 106 (however, the same node protocol may handle different subtypes of transactions differently according to the rules defined for that subtype, and different nodes may assume different roles and thus implement different corresponding aspects of the protocol).

[0042] As noted, the blockchain 150 comprises a chain of blocks 151, each block 151 comprising a set of one or more transactions 152 created by a proof-of-work process as previously discussed. Each block 151 also comprises a block pointer 155 that indicates a previously created block 151 in the chain to define a sequential order for the block 151. The blockchain 150 also comprises a pool of legitimate transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than a generation 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 permitted to branch). The chain of blocks 151 goes back to the genesis block (Gb) 153 which was the first block in the chain. One or more initial original transactions 152 in the chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0043] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, she composes the new transaction according to the relevant transaction protocol (using the wallet function of her client application 105). She then sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which she is connected. For example, this could 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 processes the transaction according to the node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets several conditions for it to be "valid", examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for being valid may be configurable for each transaction by the script included in the transaction 152. Alternatively, the conditions may simply be features inherent in the node protocol, or defined by a combination of the script and the node protocol.

[0044] For the condition that the newly received transaction 152j passes the test to be considered legitimate (i.e., the condition that "its legitimacy is confirmed"), every memory node 104S that receives the transaction 152j adds the newly confirmed legitimate transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 104S. Further, every forwarding node 104F that receives the transaction 152j spreads the confirmed legitimate transaction 152 forward to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, assuming the transaction 152j is legitimate, this means that the transaction will soon be spread across the entire P2P network 106.

[0045] When the miner node 104M gets a new transaction 152 put into the pool 154 in the copy of the blockchain 150 maintained at one or more memory nodes 104, it starts competing to solve the proof-of-work puzzle for the latest version of the pool 154 that includes the new transaction 152 (although other miners 104M may still be trying to solve the puzzle based on an older view of the pool 154, the first one to reach it defines where the next new block 151 ends and where the new pool 154 starts, and ultimately someone solves the puzzle for a part of the pool 154 that includes Alice's transaction 152j). When the proof-of-work is done for the pool 154 that includes the new transaction 152j, that transaction becomes immutable and becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 has a pointer to earlier transactions, the order of the transactions is also recorded immutably.

[0046] Since different nodes 104 may first receive different instances of a given transaction, there may be conflicting views as to which instance is "valid" before a given instance is mined into block 150, and at the point of mining, all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts one instance as valid and discovers that a second instance is stored in the blockchain 150, that node 104 must accept this and discard the unmined instance it first accepted (i.e., treat it as not valid).

[0047] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a 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 does not limit all possible embodiments.

[0048] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of digital assets. This represents a set number of tokens on the (decentralized) ledger. A UTXO may also include, 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 something indicating the sizes of the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, 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 issued to the miner 104M.

[0049] For example, suppose Alice 103a wishes to create a transaction 152j that transfers a digital asset of a target amount to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx 1 ". It takes the amount of digital assets locked to Alice in the output 203 of a 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 "Tx 0 ". Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction of the blockchain 151, nor that Tx 1 is the very next transaction in the pool 154. Tx 1 may refer to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0050] The preceding transaction Tx 0 is, by the time Alice creates her new transaction Tx 1 or at least by the time she sends it to network 106, already validated and included in blockchain 150. It may already be included in one of blocks 151 at that time, or it may still be waiting in pool 154, in which case it will soon be included in a new block 151. Alternatively, Tx 0 and Tx 1 may be created and sent together to network 102, or, if the node protocol allows buffering of "orphan" transactions, Tx 0 may even be sent after Tx 1 . The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may be equivalently replaced by "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that refers to a preceding transaction (ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that reaches node 104 before its parent is considered an orphan. Orphan nodes may be discarded, or buffered for some time while waiting for a parent, depending on the node protocol and / or miner behavior.

[0051] The preceding transaction Tx0 One of one or more outputs 203 here is a specific UTXO 0 labeled as, with. Each UTXO has a value that specifies the amount of digital assets represented by the UTXO, and a locking script that defines the conditions that must be satisfied by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be valid, and thus for the replacement of the UTXO to succeed. Usually, the locking script locks that amount to a specific party (the beneficiary of the transaction containing the locking script). That is, the locking script usually defines an unlocking condition that the unlocking script in the input of a subsequent transaction must have the cryptographic signature of the party to whom the previous transaction was locked.

[0052] The locking script (also known as scriptPubKey) is a fragment 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). The locking script specifies what information is required to consume the transaction output 203, for example, the requirements for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a fragment of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it may include Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0053] Thus, in the example shown, Tx 0 the UTXO in output 203 of 0 is the UTXO 0 to be replaced (strictly speaking, for the subsequent transaction attempting to replace the UTXO 0 to be valid) Alice's signature Sig P ARequires a locking script [Checksig P A ]. [Checksig P A ] is the public key P from Alice's public-private key pair. A Includes: Tx 1 The input 202 is (for example, in an embodiment, the entire transaction Tx 0 Tx, which is the hash of 1 Transaction ID, TxID 0 By)Tx 1 It has a pointer to Tx 1 The input 202 of the Tx 0 UTXO from all other possible outputs of 0 To identify the Tx 0 UTXOs in 0 It has an index that identifies the Tx 1 The input 202 further includes an unlocking script with Alice's cryptographic signature, which is 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 "messages") need to be signed by Alice to provide a valid signature may be defined by a locking script, or by a node protocol, or by a combination of these.

[0054] New transaction Tx 1 When the locking script arrives at the 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 the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] Here, "||" represents concatenation, "<...>" means putting data on the stack, and "[...]" is a function included in the unlocking script (in this example, a stack-based language). Equivalently, instead of concatenating the scripts, the scripts may be executed alternately using a common stack. In either way, when executed together, the scripts are Tx 1 to authenticate that the locking script in the input of Tx 0 contains Alice's signature that signs the expected part of the data, the public key P A of Alice, as included in the locking script in the output of Tx 0 is used. To perform this authentication, the expected part of the data itself ("message") must also be included in Tx 0 In embodiments, the signed data comprises the entirety of Tx

[0055] Details of authentication by public-private key cryptography are familiar to those skilled in the art. Basically, if Alice signs a message by encrypting the message with her private key, given Alice's public key and the plaintext message (the non-encrypted message), another entity such as node 104 can authenticate that the encrypted version of the message must have been signed by Alice. Signing usually involves hashing the message, signing the hash, and tagging this as the signature to the plaintext version of the message, thus enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing something such as a particular data or part of a transaction may, in embodiments, mean signing the hash of that data or part of the transaction.

[0056] Tx 1 the unlocking script in Tx0 If one or more conditions specified in the locking script are met (thus, in the example shown, if Alice's signature is provided and authenticated in Tx 1 ), node 104 considers Tx 1 to be valid. If node 104 is mining node 104M, this means that node 104 adds it to the pool of transactions 154 waiting for proof of work. If node 104 is forwarding node 104F, since node 104 forwards transaction Tx 1 to one or more other nodes 104 in network 106, transaction Tx 1 is spread throughout the network. When the validity of Tx 1 is confirmed and included in blockchain 150, this defines the UTXO 0 from Tx 0 as being consumed. Note that Tx 1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, Tx 1 is not valid even if all other conditions are met. Thus, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx 0 has already been consumed (has already formed a valid input to another valid transaction). This is one reason why it is important that the blockchain 150 imposes an order on the transactions 152. In practice, a given node 104 may maintain a separate database that marks the UTXO203 consumed by a transaction 152, but ultimately, what determines whether a UTXO has been consumed is whether node 104 has already formed a valid input to another valid 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 basis for it being improper in most transaction models. Thus, such a transaction is not propagated and not mined into block 151.

[0058] Note that in the UTXO-based transaction model, a given UTXO needs to be consumed in its entirety. A UTXO cannot "leave behind" a part of the amount defined in the UTXO while another part is consumed. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in the UTXO 0 within Tx 0 can be split among multiple UTXOs within Tx 1 . Thus, if Alice does not wish to give all of the amount defined in UXTO 0 to Bob, she can use the remainder to give herself change or pay another party in the second output of Tx 1 .

[0059] In practice, Alice usually also needs to include a fee for the winning miner, because today the reward for generating a transaction alone is usually not sufficient to motivate mining. If Alice does not include a fee for the miner, Tx 0Since it is likely to be rejected by the minor node 104M, even if it is technically legitimate, it will not be spread or included in the blockchain 150 (the minor protocol does not force the minor 104M to accept the transaction 152 if the minor 104M does not want it). In some protocols, the mining fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the winning minor 104. For example, if the pointer to UTXO 0 is the only input to Tx 1 and Tx 1 has the only output UTXO 1 . If the amount of the digital asset specified in UTXO 0 is greater than the amount specified in UTXO 1 , the difference automatically goes to the winning minor 104M. However, it is not necessarily excluded that, alternatively or in addition, the mining fee can be explicitly specified in one of the specific UTXOs 203 of the transaction 152.

[0060] The digital assets of Alice and Bob consist of unspent UTXOs that were locked to them in some arbitrary transaction 152 somewhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number that defines the total balance of a given party 103 that is stored anywhere in 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 that are locked to each party and have not yet been spent in some subsequent transaction. It can do this by querying a copy of the blockchain 150 that is stored in a memory node 104S, for example, either the one closest to, or best connected to, the computer device 102 of each party.

[0061] Note that the script code is often represented schematically (i.e., not in an actual language). For example, [Checking P A =OP_DUP OP_HASH160<H(P A )>OP_EQUALVERIFY OP_CHECKSIG means that, for [Checksig P AIt may be written as "OP_...". "OP_..." refers to a specific opcode of 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). At runtime, any occurrence of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain in the transaction being verified at the "sig" input. As another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that can store metadata within the transaction and thereby record the metadata immutably 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, this 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 a part of the transaction input and all or part of the transaction output. The specific part of the output it signs depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature to select which outputs are signed (and thus fixed at the time of signing).

[0063] The locking script may be called "scriptPubKey", which refers to the fact that each transaction is locked to the public key of the party. The unlocking script may be called "scriptSig", which refers to the fact that it supplies the corresponding signature. However, more generally, in all applications of the blockchain 150, it is not essential that the conditions for the UTXO to be exchanged include signature authentication. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0064] Optional side channel Figure 3 shows a further system 100 for implementing the blockchain 150. Except for additional communication functions, the system 100 is substantially the same as that described in connection with Figure 1. Each client application of the computer devices 102a, 102b of Alice and Bob has additional communication functions respectively. That is, it enables Alice 103a to establish a separate side channel 301 with Bob 103b (at the recommendation of any party or a third party). The side channel 301 enables the exchange of data separated from the P2P network. Such communication is sometimes called "off-chain". For example, this can be used to exchange the transaction 152 between Alice and Bob without the transaction being (yet) published on the P2P network 106 or entering the chain 150 until one of Alice and Bob chooses to broadcast the transaction 152 to the network 106. Additionally or alternatively, the side channel 301 can be used to exchange any other transaction-related data such as keys, negotiated amounts or conditions, data content, etc.

[0065] Side channel 301 can be established via the same packet-switching network 101 as P2P overlay network 106. Alternatively or additionally, side channel 301 can be established via 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. Generally, side channel 301, as referred to elsewhere in this specification, can comprise any one or more links via one or more networking technologies or communication media that are "off-chain", i.e., separated from P2P overlay network 106 for exchanging data. If more than one link is used, a bundle or aggregate of off-chain links can be referred to as side channel 301 as a whole. Thus, it should be noted that when it is said that Alice and Bob exchange certain information or data etc. via side channel 301, this does not necessarily imply that all of these data must be transmitted via exactly the same link, or even via the same type of network.

[0066] Client software Figure 4A shows an exemplary implementation of client application 105 for implementing an embodiment of the scheme disclosed herein. Client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. Transaction engine 401 is configured to implement transaction-related functions behind client 105, for example, to orchestrate transaction 152, receive and / or transmit transactions and / or other data via side channel 301, and / or transmit transactions to be disseminated through P2P network 106, as will be discussed in more detail shortly according to the scheme discussed above.

[0067] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing tactile output. The user input means may include, for example, an input array of one or more touch screens (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 voice 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, or joysticks, etc.

[0068] Note: Although various functions in this specification may be 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. For example, one may be a plugin to the other or interface via an API (Application Programming Interface). For example, the functions of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functions of a given module such as the transaction engine 401 may be divided among more than one application. It is not excluded that some or all of the described functions may be implemented, for example, in the operating system layer. When a reference is made anywhere in this specification to a single or given application 105, etc., this is for example only, and more generally, it will be understood that the described functions may be implemented in any form of software.

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

[0070] By way of example, FIG. 4B shows the UI 400 from Alice's perspective. The 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 element may comprise one or more user-selectable elements 411, which may be various on-screen buttons, or various options in a menu, etc. The user input means enables the user 103 (in this case Alice 103a) to select one of the options or otherwise operate by clicking or touching the UI element on the screen, or by speaking the name of the desired option, etc. (note that the term "manual" as used herein is only intended to contrast with automatic and is not necessarily limited to using the hands). The options enable the user (Alice) to generate transactions and send them to another user (Bob), and to generate signatures for the transactions according to the described embodiments.

[0072] Alternatively or additionally, the UI element may comprise one or more data entry fields 412 through which the user can input data to be included in the generated transaction and / or the message to be signed. These data entry fields are rendered, for example, on the screen via the user output means, and the data can be input into the fields via the user input means, such as a keyboard or touch screen. Alternatively, the data can be received orally, for example, 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. For example, this / these may be rendered on the 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 essential. The functions 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 mock-up and may in fact comprise one or more additional UI elements not shown for the sake of brevity.

[0075] Preparation / Terms Coin Serial Number The coin serial number is defined as a unique identifier of the issued digital coin (e.g., similar to the serial number of a banknote). The coin serial number is represented by an integer calculated by the user using a pseudo-random function such that the probability of generating two equivalent serial numbers is minimized.

[0076] Blinded Coin A coin is blinded if it is not practical for someone who does not know the input to the calculation that blinds the coin to calculate the serial number of the coin.

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

[0078] Blind Signature A blind signature is a signature in which the signer does not know the message being signed, i.e., the signer signs a "blinded message". As a result, the blind signature remains valid for the corresponding unblinded message.

[0079] Double Spending Value This value can identify the user Alice only if she double - spends a 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 - spending formula can be used to identify her. In fact, this means that when she double - spends, it is possible to calculate her identification information from the information revealed in each consumption of the coin. The information revealed can be her bank account number, public key, or some other value corresponding to her identification information. The following example is given for context. In an exemplary system, in the case of double - spending, the bank account number u of the double - spender is revealed. The recipient of the coin (e.g., a merchant) obtains some pre - images of a hash function, which are used to calculate the serial number of the coin. The pre - images given to the bank are

[0080] [Number]

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

[0082] [Number]

[0083] Note that ⊕ is the XOR operation and || is concatenation. When Alice double - spends, the bank has knowledge of both these values, called the "double - spending formula" or "double - spending value", and these two terms are used interchangeably. Thus, if the bank has these values, the bank can find Alice's account number by removing a in the second formula. This is done by applying the inverse operation of XOR, which is also just simple XOR, to the first value with the second value,

[0084] [Number]

[0085] From now on, the bank obtains Alice's account number by reading the first l u bits of the result, so the bank knows her identity. Note that if she does not double-spend, the bank only knows one of the above values and cannot deduce her identification information.

[0086] Safe prime A safe prime is a prime number p such that p = 2p' + 1 where p' is also prime.

[0087] RSA modulus An RSA modulus is n = p 1 and p 2 are prime numbers, defined as n = p 1 · p 2 as defined.

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

[0089] Quadratic residue Group

[0090] [Number]

[0091] Assuming 2 an element such that b

[0092] [Number]

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

[0094]

Mathematics

[0095] is called. When n is an RSA modulus, it is computationally difficult to compute b when b 2 ≡ a mod n is given without knowing the factorization of n. Note that when n is an RSA modulus, the probability that a randomly chosen element is a quadratic residue is exactly 1 / 4.

[0096] Generator Assuming a group G of degree n, an element g ∈ G of the group is a generator if repeated application of itself using the group operation results in the group G itself. This is G = <g>It is represented by, and g is a generator. The group that can be generated in this way is called "cyclic".

[0097] Below, we introduce two groups that are cyclic and relevant throughout the following sections.

[0098] The first group is represented by G and is generated by an element g with prime order q. The Decisional Diffie-Hellman problem is considered difficult, which means it is difficult to compute u when g u is given. This group is used in some exemplary schemes to derive public and private key pairs and is also used in the Dodis-Yampolskiy (DY) pseudorandom function described below. The DY function can be used to compute coin serial numbers and double-spending formulas.

[0099] The second group is the element

[0100]

Number

[0101] generated and having prime order q',

[0102]

Number

[0103] represented by. This element is a quadratic residue modulo n, and n = p 1 p 2 is a special RSA modulus. The general element of the group

[0104]

Number

[0105] is

[0106] [Mathematics]

[0107] It is represented by. This group can be used to commit secrets using Pedersen Commitment and may be used in the signature schemes employed by banks.

[0108] Pedersen commitment

[0109] [Mathematics]

[0110] ,

[0111] [Mathematics]

[0112] and

[0113] [Mathematics]

[0114] is a quadratic residue modulo n and is a generator of degree q'.

[0115] [Mathematics]

[0116] Assuming it is a generator, the Pedersen commitments of positive integers x 1 ,..., x m ∈ [0, n) are

[0117] [Mathematics]

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

[0119] Camenisch-Lysyanskaya (CL) signature It can be assumed that a user desires a third-party signature for l messages without sharing the clear value of the messages. The list of messages can be labeled as (x 1 ,..., x l ) ∈ (0, min(n, n')), where min(n, n') is the smaller value of n and n', and n and n' are the orders of the groups

[0120]

Number

[0121] and

[0122]

Number

[0123] respectively. The signer of the message has the public key (n, a 1 ,..., a l , b, c), where

[0124]

Number

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

[0126]

Number

[0127] is

[0128] [Number]

[0129] is a generator, n is a special RSA modulus, and the signer's private key is p 1 which implies that only the signer knows the factorization of n = p 1 ·p 2 . Additionally,

[0130] [Number]

[0131] ,

[0132] [Number]

[0133] is,

[0134] [Number]

[0135] and it can be assumed that n' is some integer.

[0136] To obtain a CL signature for the values (x 1 ,..., x l ) committed in the Pedersen commitment, the following steps are performed.

[0137] 1. The user has the Pedersen commitments

[0138] [Number]

[0139] and

[0140]

Number

[0141] calculate,

[0142]

Number

[0143] and r' are randomly generated integers.

[0144] 2. The user knows the values (x 1 ,..., x l ),

[0145]

Number

[0146] both and A are the same value x 1 ,..., x l to the commitment, and finally prove to the signer that they are within the correct range.

[0147] 3. The signer selects a random integer

[0148]

Number

[0149] and a prime number q,

[0150]

Number

[0151] calculate.

[0152] 4. The signer then, (V,

[0153]

Number

[0154] Send (,q) to the user.

[0155] 5.

[0156]

Number

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

[0158] An important feature of this signature is that only the signer knows its factorization, so only the signer can efficiently compute the q-th root of an element modulo n = p 1 p 2 .

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

[0160]

Number

[0161] It is defined as follows. This function shall be called a DY pseudo-random function.

[0162] Zero-knowledge proof of knowledge The general idea is that the prover provides the verifier with sufficient information to prove that the prover knows a certain value without explicitly revealing that value. Depending on what is to be proven, there are various predefined methods to do this. Generally, the verifier needs to provide an input in the form of a challenge, otherwise, it should be noted that the verifier could simply pretend to know the hidden value and pass the same proof to another party. There are cases of non-interactive proofs of knowledge, where the challenge is simply pre-agreed or has a standard format, such as a hash of the verifier's identification information and a timestamp of time and date.

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

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

[0165]

Number

[0166] such that for each

[0167]

Number

[0168] For, Alice takes the input x i and runs the simulator S to generate a conversation(

[0169]

Number

[0170] , c i ,

[0171]

Number

[0172] ). These conversations are 3-round in the zero-knowledge proof protocol of knowledge, and c i is the challenge sent by Bob, and

[0173]

Number

[0174] is Alice's response. Then, for each i ∈ A, Alice assumes a proof for the input x i and wants to send it to Bob to prove knowledge as

[0175]

Number

[0176] is determined. Alice determines the values for i = 1, 2

[0177]

Number

[0178] Send it to Bob.

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

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

[0181]

Number

[0182] Consider.

[0183]

Number

[0184] is disqualified in Γ * , which means that

[0185]

Number

[0186] Even if the value of c corresponding to i is given, Bob cannot reconstruct Alice's secret. Therefore, Alice can complete these shares into the entire set of shares that do not conflict with the string str without the risk of Bob being able to calculate the secret. Alice forms task c i for index i ∈ A such that share(c i ) is equal to the share generated in the completion process. This is done by copying the bits of the share and padding with random bits if necessary. In Step 1, S, by executing the prover's algorithm,

[0187]

Number

[0188] and c i Final message for

[0189]

Number

[0190] is generating. Finally, Alice sends the set of messages c for i = 1, 2 i ,

[0191]

Number

[0192] to Bob.

[0193] 3. Bob checks that all conversations (

[0194]

Number

[0195] , c i ,

[0196]

Number

[0197] ) lead to acceptance by the verifier in the corresponding zero - knowledge proof protocol as described in step 1, and also checks that the share share(c i ) does not conflict with the string s. He accepts only if these checks are satisfied.

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

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

[0200] Let p be a large prime number such that q|p - 1. And let g, h ∈ Z * p be elements of degree q such that the discrete logarithm of h with base g is unknown.

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

[0202] 2. She rewrites J as a binary representation such that J = J 0 2 0 + J 1 2 1 +…+ J l-1 2 l-1 . And Alice calculates the Pedersen Commitment for these J i ; r i ), i = 0,..., l - 1 using Pedcom(J i ),

[0203]

Number

[0204] .

[0205] 3. She determines that the number hidden by PedCom(x i ; r i ) is either 0 or 1 by the discrete logarithm of PedCom(J i ; r i ) with base h or the discrete logarithm of PedCom(J i ; r i ) / g, she proves it by showing that she knows either of the discrete logarithms. This is done by a proof of knowledge of the discrete logarithm as described below, and a proof of knowledge of one of the two secrets as described above.

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

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

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

[0209] We start by assuming that Alice wants to convert the proof of knowledge of the secret into a signature of knowledge that Bob can verify. Here, f is a pseudo-random function that maps a string of arbitrary length to the range [0,n), and n is the RSA modulus. To sign the message m, Alice performs the following steps.

[0210] 1. Alice selects random numbers r 1 ,...r τ ∈ [0,n) and

[0211]

Number

[0212] calculates.

[0213] 2. Alice calculates f(m,x 1 ,...,x τ ) and takes the first kτ bits, naming them e ij , where 1 ≤ i ≤ τ, 1 ≤ j ≤ k. This forms a matrix of values e ij .

[0214] 3. For j = 1,..., k, Alice calculates v j = f(ID A , j), where ID A is Alice's identification information.

[0215] 4. She then

[0216]

Number

[0217] and calculates.

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

[0219]

Number

[0220] and calculates.

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

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

[0223] 1. For j = 1,..., k, Bob calculates v j = f(ID A , j).

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

[0225]

Number

[0226] and calculates.

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

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

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

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

[0231] 1. Alice computes

[0232]

Number

[0233] where r 1 , r 2 , and r 3 are randomly generated secret integers, and sends V and U to Bob.

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

[0235] 3. Alice is then required to compute l = r 2 + eu, m = r 3 + er 1 and return these to Bob.

[0236] 4. Bob then computes g l h m =UV e Verify that it is so.

[0237] If 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 is a very simple system where users can withdraw blinded coins from the issuer, spend the unblinded coins with merchants, and the merchants can deposit the coins with the issuer without any involvement with the withdrawal. Since then, many ecash systems have been proposed that improve various aspects of this system, whether it is the prevention of double spending leading to offline ecash, the divisibility of coins, batch spending of coins, the efficiency of coin storage, the recovery of lost coins, or other improvements. In all ecash systems, the issuer provides a database service that stores previously spent coins to monitor double spending. Chaum's ecash is online cash, which means that the coin issuer needs to be online when the coin is spent. This is because in order to accept a coin, the coin recipient has to contact the issuer to check the issuer's database to see if the coin has already been spent. Offline ecash systems can deposit coins at a convenient time because they have some way of later deriving the identity information of double spenders. Note that in the following, the coin issuer is called a bank, but generally, this can be any trusted third party.

[0239] All e-cash systems involve the same basic protocols of setup, withdrawal, consumption, and deposit. In the following example, Alice wishes to withdraw some e-cash (digital coins) from the bank and spend them at a merchant, who then deposits them back with the bank. This is shown in Figure 5.

[0240] Setup In all e-cash systems, there is an initial setup where Alice and the merchant in this scheme register their identification information. This may involve either opening an account with the bank or setting up a public-key - private-key pair and sharing the public key. Similarly, in all e-cash systems, the bank must create a unique public-key - private-key pair and publish the public key.

[0241] Withdrawal 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 a blinded coin serial number or a wallet seed from which she can derive the serial number. The bank then signs these blinded values so that Alice can prove to the merchant that she has obtained the wallet correctly. The protocol for obtaining the signature on the wallet may involve Alice sending the blinded coin serial numbers to the bank, which then signs them and returns the signatures to Alice. Each e-cash specifies which signature scheme to use. Alice then stores this signature as part of the wallet. The format of the wallet depends on the specific e-cash system, but generally, this is a set of values corresponding to the coin serial number, the bank's signature on the coin, and in the case of offline cash, some additional information that enables the tracking of double spenders. At this point, only Alice has knowledge of the coin serial numbers, so only she can spend them.

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

[0243] Deposit In the case of online e - cash, the merchant immediately contacts the bank to deposit the coin. Then the bank checks its database of spent coins to see if it has already been consumed. If it has not been consumed, the bank accepts the coin and the merchant receives the value of the coin. If it has already been consumed, the merchant rejects the payment. In offline e - cash, the merchant can deposit the coin with the bank at any time when needed, such as at the end of the business day. The bank then stores the serial number and any double - spending information. If the coin is a double - spend, this additional double - spending information can be used to identify the culprit. In some protocols, it is also possible to calculate the remaining unspent coins after a double - spend, so these can be put on a blacklist.

[0244] Digital Coin System FIG. 6 shows an exemplary system 600 for implementing a digital cash system for issuing digital coins. System 600 includes an issuer 601 (e.g., a bank or other trusted third party) responsible for issuing digital coins to a consumer 602 (e.g., end-user Alice103a, or a business, service, university, charity, etc.). The system also includes an exchanger 603 (e.g., a merchant) that can receive digital coins from the consumer 602 and deposit the digital coins with the issuer 601 in exchange for receiving digital assets represented by the digital coins. For example, the consumer 602 may provide digital coins to the exchanger 603 in return for services provided by the exchanger, and the exchanger can exchange the digital coins with the issuer for an amount of conventional money (i.e., fiat currency) represented by the digital coins. System 600 further includes a blockchain network 106. Each of the issuer 601, the consumer 602, and the exchanger 603 is configured to interact directly or indirectly with the blockchain 150, e.g., to send transactions to the blockchain 150, to retrieve transactions from the blockchain 150, etc.

[0245] Note that each of the issuer 601, the consumer 602, and the exchanger 603 may perform some or all of the functions attributed to Alice103a and Bob103b in connection with FIGS. 1 through 4.

[0246] As shown in FIG. 6, the issuer 601 may be configured to send a withdrawal transaction Tx withdraw to the consumer 602, e.g., via a side channel 301. The withdrawal transaction Tx withdraw may also be sent to the blockchain network 106. The consumer 602 may be configured to send a consumption transaction Tx spend to the exchanger 603, e.g., via the side channel 301. The consumption transaction Tx spend can also be sent to the blockchain network 106. The exchanger 603 can be configured to send the deposit transaction Tx deposit to the issuer 601, for example, via the side channel 301. The deposit transaction Tx deposit can also be sent to the blockchain network 106. It should be noted that this is only an example for one explanation of the transaction flow between the parties. Other flows are possible and will be discussed below.

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

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

[0249] Merchant 603 may go through a similar process for Alice602 to register the identifier of merchant 603.

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

[0251] In some examples, the coin seed s can be based on an input from bank 601. That is, bank 601 provides input r' to Alice 602. Then, the coin seed is generated based on input s' from Alice and input r' from the bank, for example 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 digital asset of a predetermined amount, which can be set by bank 601. For example, each digital coin can 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 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 the first of the plurality of coin serial numbers (and in some examples, the only coin serial number) based on the coin seed. The first coin serial number can be generated by applying a pseudo-random function, such as the DY pseudo-random function, to the coin seed. Thus, the first coin serial number is associated with the coin seed but appears to be a random value.

[0254] Here, a withdrawal transaction is 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 generating the withdrawal transaction depends on whether the digital coin system is a traceable coin system or a non-traceable coin system.

[0255] For a traceable coin system, a withdrawal transaction includes a bank signature Sig B . That is, the withdrawal transaction is signed by the bank 601. An exemplary traceable withdrawal transaction is shown in FIG. 7a. The bank signature Sig B is included in the input of the withdrawal transaction (along with the corresponding public key P B of the bank in this example).

[0256] The withdrawal transaction also includes a first output that includes a hash of the first coin serial number. Note that other alternative one-way functions may be used instead of the hash function. The first output is configured such that when executed with the input of the consumption transaction, subsequent transaction inputs need to include the preimage of the hash function (i.e., the first coin serial number itself) to unlock the first output, and includes an output script. Optionally, as shown in the example of FIG. 7a, the output script may also be locked to the public key P A of Alice and / or the public key P B of the bank 601. For example, the first output may be a multi-signature output. That is, to unlock the first output, the consumption input must include a signature Sig A corresponding to the public key P A of Alice and / or a signature Sig B corresponding to the public key P B of the bank. A second output that returns a change to the bank 601 may be included.

[0257] In the example of FIG. 7a, the withdrawal transaction includes first data representing the first digital coin. The first data may be included in a consumable output or a non-consumable output (e.g., an OP_RETURN output). An example of the first data is shown in FIG. 7b. The first data may include a prefix that represents a digital asset represented by a digital coin (e.g., currency), a coin protocol flag, a coin action flag (e.g., withdrawal), and one, some, or all of the balances of the digital coin.

[0258] In a non-traceable coin system, the withdrawal transaction has the signature Sig of Alice A That is, the withdrawal transaction is signed by Alice 602. An exemplary non-traceable withdrawal transaction is shown in FIG. 10a. The signature Sig of Alice A is included in the input of the withdrawal transaction (along with the corresponding public key P of Alice in this example A ). The non-traceable withdrawal transaction has the same first output as described above for the traceable withdrawal transaction. As described above, the non-traceable withdrawal transaction may also include the first data representing the first digital coin. An example of the first data is shown in FIG. 10b.

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

[0260] When Alice 602 signs the withdrawal transaction, Alice 602 does not need to send the withdrawal transaction to the bank 601. Alice 602 only needs to send the withdrawal transaction to the blockchain network.

[0261] Optionally, a withdrawal transaction may comprise more than one output with a hash of the coin serial number. For example, Alice602 may generate a second coin serial number to represent a second digital coin. The first coin serial number may be the seed of 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 applying a pseudorandom function directly to the coin seed. In these examples, the withdrawal transaction comprises a series of outputs similar to the first output, except that the hash values are different. Each output may be associated with its respective data output, i.e., an output having data similar to the first data.

[0262] Consume To consume the first digital coin in a transaction (e.g., a deal) with merchant603, Alice602 provides the first coin serial number to merchant603. Merchant603 checks whether the first coin serial number is included in the blockchain transaction. Note that only the hash of the first coin serial number is included in the withdrawal transaction, and not the first coin serial number itself. If the first coin serial number is included in the blockchain, merchant603 rejects the first digital coin and ends the transaction. As discussed below, the first coin serial number may be included in the blockchain as part of the consumption of the first digital coin by Alice602, or as part of the blacklisting of the first digital coin by bank601. If the first coin serial number is not included in the blockchain, merchant603 may decide to accept the digital coin and proceed with the transaction.

[0263] Merchant 603 obtains a consumption transaction in response to one or more conditions being met. The one or more conditions include the condition that a first coin serial number does not exist on the blockchain. The consumption transaction includes the first coin serial number and serves as evidence that Merchant 603 has received the digital coin represented by the first coin serial number. Merchant 603 may generate the consumption transaction in whole or in part, for example, in combination with Alice602. That is, one, some, or all of the inputs and / or outputs of the consumption transaction may be generated by Merchant 603. Similarly, one, some, or all of the consumption transaction inputs and / or outputs may be generated by Alice602.

[0264] Figure 8a shows an example of a traceable consumption transaction. Since the traceable consumption transaction includes a first coin serial number, the first coin serial number is revealed when the consumption transaction is issued to the blockchain network. In this example, the first coin serial number is included in the first input of the consumption transaction. Since the first input of the consumption transaction may reference the first output of the withdrawal transaction, a chain of transactions is created. If required by the first output of the withdrawal transaction, the first input may include Alice's signature Sig A and / or public key P A . The consumption transaction may include a second output that includes the merchant's signature Sig M and / or public key P M . The second output may reference a transaction output that is locked to the merchant's public key P M .

[0265] If Alice602 wishes to spend another of her digital coins later, the spend transaction may have a first output similar to the first output of the withdrawal 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 have a second output locked to the respective public keys of Alice602, the bank601, and / or the merchant603. A multi-signature output may be used to lock the output to the lowest n public keys of the entire set of public keys.

[0267] The spend transaction may have a third output with second data, for example to a spendable or unspendable output. FIG. 8b shows an example of the 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 the remaining balance of Alice's digital coin. The second data may include additional items discussed below.

[0268] FIG. 11a shows an example of an untraceable spend transaction. Like a traceable spend transaction, an untraceable spend transaction has a first coin serial number. In this example, the first coin serial number is included in the first input of the spend transaction. Since the first input of the spend transaction may reference the first output of the withdrawal transaction, it creates a chain of transactions. If required by the first output of the withdrawal transaction, the first input may include Alice's signature Sig A and / or public key P A The spend transaction may have a second output including the merchant's signature Sig M and / or public key P M The second output may be locked to the merchant's public key P M can refer to the transaction output locked to it.

[0269] The un-trackable consumption transaction may comprise a first output comprising a hash of second data representing the consumed digital coin. This output may be signed by Alice, which serves as evidence that Alice602 has proven the consumption of the digital coin. The second data itself may be included in a different output of the transaction (the third output of FIG. 11a). The first output may be configured such that an input of a later transaction requires the inclusion of the second data itself. The second output of the consumption transaction may be locked to the respective public keys of Alice602, the bank 601, and / or the merchant 603.

[0270] The second data may be included in a consumable or non-consumable output. FIG. 11b shows an example of the second data. As in the example of FIG. 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] When the merchant 603 adds Alice602's input (i.e., the input comprising her signature Sig A and the output of the transaction, it may sign the (trackable or un-trackable) consumption transaction. The merchant 603 may then send the consumption transaction to the blockchain network or send the consumption transaction to Alice602 for her to send the consumption transaction to the blockchain network. As another example, the merchant 603 may send the consumption transaction to a third party, which may be a service provider such as a wallet provider.

[0272] Optionally, Alice602 may provide the withdrawal transaction to the merchant 603, or the merchant may obtain the withdrawal transaction from the blockchain using, for example, the transaction identifier TxID provided by Alice602. The merchant 603 may confirm that the first input of the consumption transaction unlocks or at least references the first output of the withdrawal transaction.

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

[0274] The merchant 603 sends the first coin serial number to the bank 601. The merchant 603 may send the first coin serial number directly to the bank 601. Additionally or alternatively, the merchant 603 may provide the bank 601 with a consumption transaction that includes the first coin serial number, or at least the transaction identifier TxID of the consumption transaction. As another option, when warned about a transaction locked to the public key P B the bank 601 may obtain the consumption transaction directly from the blockchain.

[0275] Bank 601 checks whether the first coin serial number exists in the record of consumed coin serial numbers maintained by Bank 601. The coin serial number may be maintained on the blockchain 150, that is, record the serial number on-chain in the transaction or in a separate database. When stored in the database, the blockchain 150 can be scanned for the serial number, for example when the coin flag appears on-chain. The database can also be stored on the blockchain 150. If the first coin serial number exists in the database, since the digital coin represented by the first coin serial number has already been consumed, the deposit of digital coins by merchant 603 is rejected. If the first coin serial number does not exist in the database, Bank 601 can accept the digital coin and transfer the assets of the amount represented by the digital coin to merchant 603. There may be one or more additional conditions that must be met for Bank 601 to transfer the assets of that amount to merchant 603.

[0276] Merchant 603 obtains a deposit transaction. Merchant 603 can generate the deposit transaction completely or in cooperation with Bank 601. The deposit transaction includes an input that references the output of a consumption transaction, such as a second output. The deposit transaction may include the signature Sig M and / or the signature Sig B of the bank. Merchant 603 can generate the deposit transaction and send it to the blockchain network, or Merchant 603 can generate the deposit transaction and send it to Bank 601 so that the bank can send it to the blockchain network or even to a third party such as a wallet provider. Alternatively, Bank 601 can generate the deposit transaction and then send it to 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 bank 601 and merchant 603. That is, the first input is the bank's signature Sig B and the merchant's signature Sig M and includes. The first input refers to the output of the consumption transaction. In this example, the first input refers to the second output of the consumption transaction, i.e., the multi-signature output.

[0278] The deposit transaction may include third data. An example of the third data is shown in Figure 9b. The third data may include one or more data fields common to the first and / or second data. The third data may include something indicating the value of the deposited coins. If it is found that Alice 602 tried to double-spend digital coins and the deposit transaction was generated by bank 601, the third data may include the serial numbers of any remaining unspent digital coins issued to Alice 602.

[0279] Figure 12a shows an example of an untraceable deposit transaction. Similar to the exemplary deposit transaction shown in Figure 9a, the first input of the deposit transaction is signed by both bank 601 and merchant 603. The first input refers to the output of the consumption transaction, e.g., the first output of an untraceable consumption transaction. In this example, the first output of the untraceable consumption transaction included a hash puzzle of the second data. In other words, the first output of the untraceable consumption transaction was configured such that the input of a subsequent transaction attempting to unlock the first output needed to have a preimage in the form of the second data and included a script. Thus, the first output of the deposit transaction in this example includes the second data in raw form.

[0280] The deposit transaction may include one or more outputs. As shown in Figure 12a, the deposit transaction includes the public key P of bank 601 M may include a first output locked thereto. The deposit transaction may include a second output including third data. FIG. 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 a digital coin is that the consumption transaction includes an input that unlocks by referring to the output of a withdrawal transaction, e.g., a withdrawal transaction signed by bank 601. Similarly, one of the conditions that must be met for merchant 603 to accept a digital coin is that Alice 602 provides a withdrawal transaction, or a reference to a withdrawal 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 a digital coin is that the consumption transaction includes an input signed by Alice 602 and / or bank 601. In some examples, both signatures must be present.

[0283] In some embodiments, Alice 602 may send a coin seed proof to merchant 603. The coin seed proof is proof that Alice 602 has knowledge of the blind signature σ B by the bank of the coin seed. In some examples, the coin seed proof may simply be the blind signature itself. In other examples, the coin seed proof may be a zero-knowledge proof. Zero-knowledge proofs were discussed above. Merchant 603 may determine based on the coin seed proof whether Alice 602 actually has knowledge of the signature σ B by the bank for the coin seed. One of the conditions for merchant 603 to accept a digital coin may be that the coin seed proof proves that Alice 602 has knowledge of the signature σ B .

[0284] In some embodiments, when a merchant 603 attempts to deposit a digital coin, the merchant 603 may send a coin seed proof to a bank 601. Like the merchant 603, the bank 601 may determine, based on the coin seed proof, whether Alice 602, and thus the merchant 603, actually has knowledge of the bank's signature σ B for the coin seed. One condition for the bank 601 to accept the digital coin may be that the coin seed proof proves that Alice 602 has knowledge of the signature σ B for the coin seed.

[0285] In some embodiments, Alice 602 may generate one or more double - spend seeds. Each double - spend seed may be used to generate a double - spend value. The double - spend value has been described above. Alice 602 may send a blinded version of one or more double - spend seeds to the bank 601, and the bank 601 may return a blind signature σ B for the one or more double - spend seeds. The signature σ B for the one or more double - spend seeds may be the same signature σ B for the coin seed. That is, the bank 601 may sign the coin seed and the double - spend seeds as a whole.

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

[0287] When merchant 603 deposits a digital coin, merchant 603 transmits the double - spending value to bank 601. If bank 601 discovers that the first coin serial number exists in the record of consumed coin serial numbers (i.e., in blockchain 150), bank 601 may use the double - spending value together with the previously received double - spending value, i.e., the double - spending value received when the first digital coin was first deposited, to reveal Alice's identification information. If Alice 602 has any remaining unconsumed digital coins, bank 601 may blacklist those coins. An example of blacklisting coins is discussed below.

[0288] Alice 602 may transmit a double - spending seed proof to merchant 603. The double - spending seed proof is a proof of knowledge that Alice 602 has the blind signature σ B of the bank for the double - spending seed. In some examples, the double - spending seed proof is simply the blind signature σ B It can be self. In other examples, the double - spending seed proof can be a zero - knowledge proof. Zero - knowledge proofs were discussed above. Merchant 603 can determine, based on the double - spending seed proof, whether Alice 602 actually has knowledge of the bank's signature σ B for the double - spending seed. One of the conditions for Merchant 603 to accept a digital coin can be that the double - spending seed proof proves that Alice 602 has knowledge of signature σ B . In some embodiments, when attempting to deposit a digital coin, Merchant 603 can send the double - spending seed proof to Bank 601. Like Merchant 603, Bank 601 can determine, based on the double - spending seed proof, whether Alice 602, and thus Merchant 603, actually has knowledge of the bank's signature σ B for the double - spending seed. One of the conditions for Bank 601 to accept a digital coin can be that the double - spending seed proof proves that Alice 602 has knowledge of signature σ B .

[0289] In some embodiments, Alice 602 can use the hash R of the merchant's identifier (e.g., the public key P M and generate data items that can be selected by the merchant 603. As discussed above, the data items can be based on the interaction between Alice 602 and the merchant 603, such as the date and / or time of the interaction. Alice 602 can send the hash R of the merchant's identifier to the merchant 603, for example, as part of a consumption transaction. One of the conditions for the merchant 603 to accept the digital coin can be that the merchant 603 agrees to the hash R of the merchant's identifier. When depositing the digital coin into the bank 601, the merchant 603 can send the hash R of the merchant's identifier to the bank 601. The bank 601 can maintain a record of the received merchant identifier hashes (i.e., the respective hashes of the merchant's identifiers), either on-chain or off-chain. One of the conditions for the bank 601 to accept the digital coin can be that the most recently received merchant identifier hash does not appear in the record (e.g., on the 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] Exemplary Transaction Figures 13a through 13c each show exemplary and comprehensive withdrawal, consumption, and deposit transactions that can be used in any digital cash protocol. These exemplary transactions may be used for any protocol, and the only part of the transaction that changes is the OP_RETURN data.

[0291] Figure 13a shows a comprehensive withdrawal transaction. Alice 602 obtains the signature σ B for the serial number of the coin from the bank 601. The withdrawal transaction is created to inform that this transaction has occurred. The input of this transaction is from the bank 601 in a traceable protocol or from Alice 602 in a non-traceable protocol. The data is specified for each digital coin system.

[0292] Figure 13b shows an inclusive consumption transaction. Alice 602 proves to merchant 603 that she has a coin with the correct format and a signature σ from bank 601 for the coin. To inform her that her consumption has been accepted by merchant 603, a consumption transaction is created, where the input is derived from the withdrawal transaction. This transaction includes the serial number of the coin and additional information that can identify her in case she double-spends. If there is another coin that will be consumed when traceable, there is an additional output with the same format as the output of the withdrawal transaction so that Alice 602 can consume the next coin. The data in OP_RETURN shall be specified for each digital coin system. B To prove to the merchant 603 that she has the coin and the signature σ from the bank 601 for the coin with the correct format. A consumption transaction is created to inform her that her consumption has been accepted by the merchant 603. Here, the input is derived from the withdrawal transaction. This transaction includes the serial number of the coin and additional information that can identify her in case she double-spends. If there is another coin that will be consumed when traceable, there is an additional output with the same format as the output of the withdrawal transaction so that Alice 602 can consume the next coin. The data in OP_RETURN shall be specified for each digital coin system.

[0293] Figure 13c shows an inclusive deposit transaction. Merchant 603 provides bank 601 with proof that the merchant has lawfully accepted the coin. A deposit transaction is created that consumes the output of the consumption transaction and informs that the deposit has been accepted. This transaction is the same for both the traceable protocol and the non-traceable protocol. The data in OP_RETURN shall be specified for each digital coin system.

[0294] Exemplary Protocol Traceable Digital Coin The following describes an exemplary traceable protocol that uses the blockchain to prevent double-spending. In a traceable protocol, digital coins are traceable due to the fact that each consumption transaction is linked to a withdrawal transaction signed by bank 601. This linkage results in the easier proof that the coin has been actually issued by bank 601.

[0295] Alice602 wishes to withdraw a wallet from bank 601 and spend part of the digital coins at merchant 603, and the merchant 603 then deposits the coins into bank 601. Bank 601 has a public / private key pair (pk B , sk B ). In this protocol, bank 601 can sign (i + 3) messages simultaneously. Then, the public key of the bank is (n, a 1 ,..., a i+3 , b, c), and the private key is n = p 1 p 2 where p is such that p 1 is a special RSA modulus. The following exemplary protocol uses i = 1, but it is easy to modify the protocol for larger i. This scalability allows additional secrets to be committed and then revealed in case of double spending. In addition, Alice602 and merchant 603 each have a unique key pair such that (pk

[0296]

Number

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

[0298] Alice contacts bank 601 and requests a value

[0299]

Number

[0300] Ask the bank to withdraw the wallet W, which contains the seed and double-spending formula for the coin serial number. She sends the committed seed (u, s, t) to bank 601, and bank 601 then signs this commitment and returns this signature σ B The total value of the coins

[0301]

Number

[0302] is debited from her account.

[0303]

Number

[0304] To withdraw n coins, the following steps are taken. In this protocol, due to the nature of the zero-knowledge proof of the value of the internal counter J of the coin,

[0305]

Number

[0306] only the wallet containing n coins can be withdrawn, and note that l j is the length of the counter in bits.

[0307] u

[0308] Alice602 identifies herself to bank 601 by providing knowledge of sk using the zero-knowledge proof described at the beginning. Here, Alice602 and bank 601 generate the secret of the wallet in the following way. Alice602 takes random values s', t,​ [Mathematics]

[0309] Select and perform a Pedersen Commitment

[0310] [Mathematics]

[0311] Send it to Bank 601. Bank 601 selects a random integer r' to contribute to the wallet and sends this to Alice602. Both the bank and Alice individually

[0312] [Mathematics]

[0313] Calculate.

[0314] This step is basically to create the wallet's secret and give the bank 601 randomness for this step. Alice602 and Bank 601 execute the CL signature protocol to obtain the bank's signature for the values in Pedersen Commitment A, and the signature σ B (u, s, t) = (V, r, e) results, where

[0315] [Mathematics]

[0316] is. The method for calculating this signature is given above in the preparation section, where (x 1 , x 2 , x 3 ) is (u, s, t).

[0317] Alice602 creates the wallet W = (u, s, t, σ B (u, s, t), J) is saved and J is initialized to 0. j It is a bit counter. Note that since the signature by bank 601 is only for wallet seeds s and t, the serial number and double-spending formula do not necessarily have to be stored in the wallet. Instead, they can be derived using the wallet seed and wallet counter when needed. Bank 601 withdraws

[0318] [Number]

[0319] a certain number of coins from the account corresponding to Alice 602.

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

[0321] Furthermore, the wallet may contain additional variables used to reveal further secrets if Alice 602 double-spends. The additional variables are (z 1 ,..., z l ) is denoted as such, where l is an additional secret number that one wishes to reveal. l ∈ [0, n - 3), and the group of the CL signature scheme is modulo n, with the range up to n - 3. It should be noted that in the Camenish, Hohenberger, and Lysyanskaya (CHL) protocol, as described in J. Camenisch, S. Hohenberger, and A. Lysyanskaya, "Compact e-cash", Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2005, there are already three values to be signed (see below for further details). Since the bank 601 signs these new variables with the secrets of other wallets, the wallet becomes W=(u,s,t,(z 1 ,...,z l ),σ B (u,s,t,(z 1 ,...,z l )),J) .

[0322] These additional wallet secrets can be used to calculate l double-spending equations Z 1 ,..., Z l in exactly the same way that t is used to calculate T in CHL.

[0323] The wallet seed s in CHL is given by s = s' + r' where Alice 602 randomly selects 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 and is interpreted as Alice's contribution to the wallet seed. Thus, the wallet seed s is here s = hash(g s'' ) + r' is defined, Alice randomly selects s'', and bank 601 randomly selects r'. The purpose of redefining the seed s in this way is to immediately derive from the new double-spending formula

[0324]

Number

[0325] which provides the same characteristics as T in the original implementation (see below for the description of the CHL protocol). As a result, if Alice 602 double-spends, her seed becomes derivable by bank 601. This is done in the following way. If Alice 602 double-spends, bank 601 knows two different values of Z and R labeled 1 , R 1 , Z 2 , R 2 . And the bank

[0326]

Number

[0327] calculates and can calculate the complete seed s = hash(g s'' ) + r' , where r' is the bank's unique contribution, which is what the bank stored together with Alice's information during withdrawal. Then, using the formula for the coin serial number

[0328]

Number

[0329] for all the remaining

[0330]

Number

[0331] For the rest, the 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 can be repeated for any number of additional secrets as long as the secret is in the form of g ■ and can be repeated for any number of additional secrets as long as the secret is in this form. Here, this double-spending value Z is included in the coin exchange. At this point, Bank 601 W=(u,s,t,z 1 ,σ B (u,s,t,z 1 ),J) has given Alice 602 the wallet in the form of, so Bank 601 broadcasts the transaction as given in Figure 7a.

[0332] The first output includes a 1-of-2 multisig that can be unlocked by Alice P A or Bank P B and the hash of the serial number of the first coin. All subsequent coin outputs also have this format. This means that to unlock any of these outputs, one needs to know the serial number of the coin, and at this point only Alice 602 knows the serial numbers. If Alice 602 double-spends, only Bank 601 can calculate the serial numbers before they appear on the chain. And the bank can consume any coin output in this form, thereby blacklisting the coin. This additional requirement in the locking script means that Bank 601 cannot maliciously blacklist coins. Note that since the serial numbers are on the chain, it is more secure for Alice 602 to consume the serial numbers in a random order. One way to do this without having to remember all the consumed serial numbers is to randomly select a ∈ J and

[0333]

Number

[0334] be the greatest common divisor

[0335]

Mathematics

[0336] is to select so that. And, in order to consume the i-th coin,

[0337]

Mathematics

[0338] is selected. In this process, since the counter is not repeated until all coins are consumed, she only needs to record the total number consumed and the initial values a and b, without the need to record the serial numbers of the coins already consumed. The second output in the transaction is simply the change to bank 601.

[0339] Finally, the data given in the OP_RETURN output is as given in Figure 7b. 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 is a withdrawal in this example. The value of the coin is the number of coins withdrawn. In this example, 64 coins are issued. After this, there is an 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, anyone who receives a coin from Alice602 can verify that the balance and the value of previous consumption match. This also serves as a guarantee that the counter is within the correct range. In this case, it is easy to consume multiple coins at once because they can be easily described in the OP_RETURN. As another option, there can be multiple P2PKH outputs in the withdrawal transaction. Then, each output represents a single coin, and one output is consumed each time one coin is consumed. The wallet balance can be easily calculated by the number of unspent outputs of the transaction, and it is easy to blacklist a coin in this protocol because it is blacklisted by consuming the corresponding unspent transaction output (UTXO). The drawback of this case is that when the number of issued coins is large, the number of UTXOs is large, which burdens the miner 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 exemplary protocol, to consume a coin, Alice602 gives to merchant603 · The serial number of the coin, · The double-spending formula calculated using R and obtained by Alice from the merchant, · A zero-knowledge proof that all these formulas are correctly formed, · The signature σ B A zero-knowledge proof of knowledge that is the bank's signature for the values (u, s, t, z 1 ), · A proof that the counter J is within the correct range, and · The withdrawal transaction, and any additional consumption transactions to the merchant603.

[0342] Assume that Alice602 withdraws X coins. Since the serial numbers of these coins all have the same seed "s", in order to create different serial numbers, a counter going from 1 to X may also be in the coins, and including this counter in the serial number basically means that each coin has a different serial number. Alice602 may be required to prove that a given serial number was derived from the seed and the counter. The range may be arbitrary, for example, it may be from 1,...,X. However, there is nothing to stop her from creating coin serial numbers derived from X+1,X+2,... and claiming that these are the coins withdrawn from the bank602 and that there is proof here that the seed was signed. Therefore, to prevent this, Alice includes a proof that the counter value is between 1,...,X.

[0343] More specifically, to consume a coin, Alice602 and the merchant603 perform the following steps. Alice602 calculates R = H(pk M ||info), where info is some variable chosen by the merchant603 and H is some collision-resistant hash function. info needs to be something that changes with each transaction to ensure that the corresponding double-spending formula is different, for example, the time and date of consumption, the consumption invoice, or the transaction counter. Alice602 calculates the coin serial number and the double-spending formula,

[0344]

Number

[0345] Here

[0346]

Number

[0347] It is the DY pseudo-random function given in the preparation section. Since the double-spending value depends on the merchant ID and its input info, these cannot be calculated beforehand.

[0348] Alice602 sends a zero-knowledge proof of knowledge of (u, s, t, z 1 , σ B , J), which is transformed 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 correctly formed, and that the signature σ B is correctly formed. This is done in the following way. Let A = PedCom(J). Prove that A is a commitment to an integer in the range

[0349]

Number

[0350] Let B = PedCom(u), C = PedCom(s), D = PedCom(t), E = PedCom(z 1 ), and prove the knowledge of the CL signature for u, s, t, and z 1 without revealing them. Prove that the serial number S and the double-spending formula T are correctly formed. Then, the signature is for the message

[0351]

Number

[0352] .

[0353] Finally, the coin that Alice602 is spending has the form (S, R, T, Z, Φ) .

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

[0355]

Number

[0356] When it is, the wallet is empty.

[0357] If the merchant 603 is given the withdrawal transaction and the chain of all coin consumptions stemming from this transaction, this proves to the merchant 603 that the coins were issued by the bank 601. And Alice 602 needs to prove that the serial number and the double - spending formula are correctly calculated from the seed s, t, z 1 , and the counter J, that the bank 601 has signed the value (u, s, t, z 1 ), and that the counter is within the correct range. This is summarized using a zero - knowledge proof of knowledge of the signature Φ on the message

[0358]

Number

[0359] as described above.

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

[0361] Alice 602 creates a transaction by signing the output of the withdrawal transaction as her input. She then creates three outputs. The first output corresponds to the next coin that Alice 602 wishes to spend, so this consumption protocol can be repeated. The second output is used for depositing the coin to bank 601. The third output contains the data of the coin being spent. Since she needs to sign the three outputs, she uses the flag SIGHASH_ALL|SIGHASH_ANYONECANPAY. Since Alice 602 uses this specific flag, after Alice 602 signs it, merchant 603 can only add its input and cannot add outputs. An input from merchant 603 is required so that there is a record that the merchant has accepted the coin as a payment from Alice 602. Alternatively, relying on merchant 603 to sign the transaction first would also require some exchange of transaction data, so it is more beneficial to have Alice 602 sign the transaction first and send it along with the zero-knowledge proof of knowledge. Merchant 603 then signs the transaction with its input and broadcasts it to the blockchain network.

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

[0363] In this protocol, since the serial number is on the chain, merchant 603 can wait for contacting bank 601 to deposit the coin, and if double spending occurs, it can already be identified at this point. During the deposit, bank 601 performs the same verification as merchant 603 and additionally must verify that the preimage of R is actually the merchant's ID (and some other information info). Bank 601 also verifies that all previous transactions have the correct format and rejects deposits that do not. This ensures that all users follow the protocol. When the serial number is presented and it is known not to be double spending, merchant 603 and bank 601 sign the deposit transaction as shown in Figure 9a, which functions as confirmation that the coin has been deposited. Merchant 603 can create a transaction template, sign the input, and send this along with other information about the coin. Bank 601 then adds its signature to the input and broadcasts the transaction to the blockchain. This transaction notifies that bank 601 has received the coin deposited from merchant 603. The data has the format shown in Figure 9b.

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

[0365] If R is the same, the bank 601 considers that the merchant 603 has already deposited the coin and is responsible. In this case, it can be either that only the merchant 603 is responsible, or both Alice 602 and the merchant 603 are responsible. Since there is no reason for the merchant 603 to collude with Alice 602, it is safe for the bank 601 to consider it that way. In this situation, since Alice 602 should not be identified and punished, only the merchant 603 suffers losses. This case is solved by using the blockchain to utilize the binary nature that only whether the transaction output has been consumed or not. Therefore, simply using the blockchain makes any case of double spending impossible.

[0366] If R is different, at least Alice 602 (and possibly the merchant 603 as well) should have acted fraudulently, and the bank 601 can calculate the identification information of both parties. To calculate Alice's identification information, the following calculations are performed. Denote the previous database entry as R 1 , T 1 and the current values as R 2 , T 2 . Then, the bank 601 can calculate Alice's public key using

[0367]

Number

[0368] .

[0369] To derive all coin serial numbers and thus be able to put unconsumed coins on the blacklist, there are equivalent calculations corresponding to Z s'' and Z 1 and Z 2 that result in g.

[0370] Finally, if the merchant 603 should also be responsible, in both versions of the double-spent coin, info is different, and pk M is equivalent. info and pk M Since both are stored with each deposit, bank 601 can immediately detect this and the bank can penalize both Alice 602 and merchant 603. Thus, neither party has an incentive to collude.

[0371] If double spending of a coin is a fact, the coin serial number appears twice on the blockchain and bank 601 accepts only the first appearing coin. Then, bank 601 uses the equations from both appearances to calculate the double spending value T 1 , T 2 and merchant ID R 1 , R 2 to calculate the identification information of the double spender. Additionally, the seed can be calculated from Z 1 , Z 2 and R 1 , R 2 in a similar way. These calculations are shown above. Bank 601 can then calculate Alice's identification information g u and the coin seed s. Next, bank 601 can derive the serial numbers corresponding to Alice 602, publish these on the chain, and put the coins on a blacklist. Of course, this protocol allows the bank the option to reward merchant 603 for turning in Alice 602 to bank 601 by including a payment to merchant 603 in the above transaction.

[0372] Recall that bank 601 knows that if a double spent coin has the same serial number and merchant ID, merchant 603 must be held responsible. If there is a deposit immediately after all the transactions explained above, it is never possible for merchant 603 to deposit the coin twice with this protocol because the first deposit consumes 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 merchant 603 and bank 601 to verify that the coins are legitimately issued. This burden includes the same checks as are performed in the traceable protocol described above, but with the additional feature that double-spending is impossible and any attempt at double-spending can be immediately detected.

[0374] Similar to the traceable protocol, Alice 602 wishes to withdraw some digital coins from bank 601 and spend them at merchant 603, and merchant 603 deposits them with bank 601. The setup is the same as the previous setup. Bank 601 has a public / secret key pair (pk B , sk B ). Then, the bank's public key is (n, a 1 ,..., a 4 , b, c), and the secret key is such that n = p 1 p 2 where p is a special RSA modulus like p 1 . In addition, Alice 602 and merchant 603 each have a unique key pair such that for some

[0375]

Number

[0376] , (pk u , sk u ) = (g u , u). Since all users also have a unique EC public / secret key pair of the form (pk = sk·G, sk), they can receive and spend bitcoins. Alice's key pair is denoted (P A , sk A ), the bank's key pair is given by (P B , sk B ), and finally, the merchant's key pair is (P M , sk M ).

[0377] In this protocol, Alice602 withdraws the wallet in the form of W=(u, s, t, z 1 , σ B (u, s, t, z 1 ), J) where u is Alice's private key, s is the seed of the coin serial number, t, z 1 are the seeds of the double - spending formula, σ B is the signature by bank 601 for the secret, and J is the counter of the wallet. Alice602 broadcasts the transaction to confirm the withdrawal. In an untraceable protocol, there must be a withdrawal transaction corresponding to each coin in her wallet, and these cannot be linked. Alice602 later creates a withdrawal transaction for the wallet withdrawal from bank 601. If she does it simultaneously, bank 601 is likely to be able to know which withdrawal the transaction corresponds to. In fact, the ease of identifying Alice602 depends on the number of users of the ecash system. If there is only one (or a few) user, the user can be easily identified by bank 601 whenever a withdrawal transaction is made on the chain.

[0378] Alice602 creates her withdrawal transaction representing each coin. Note that it is an important difference between a traceable protocol and an untraceable protocol that Alice602 rather than bank 601 creates the withdrawal transaction. This transaction has the form given in Figure 10a. This transaction represents a single coin. As before, since the locking script contains the hash of the coin, bank 601 can consume the output only if it knows the serial number of the coin, which occurs only when Alice602 double - spends.

[0379] The OP_RETURN data is shown in Figure 10b. In this protocol, since the coin has a certain set value, no balance is required as each UTXO represents one unit of value. Alice602 can create this transaction at any time she desires as long as the consumption protocol has not started. As mentioned, it is more secure for Alice602 to create this transaction at a random time after withdrawal and at a different time from the transactions corresponding to the 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 malicious behavior by Alice602, such as creating an output that Bank 601 cannot consume.

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

[0381] All the proofs are sent as a signature of knowledge Φ over the message

[0382]

Number

[0383] and there is an additional commitment E corresponding to an additional secret z 1 which is defined as E = PedCom(z 1 )

[0384] ​First, the merchant 603 must confirm that the serial number has not yet appeared on the blockchain. This confirmation utilizes the immutable history of the blockchain. If the coin serial number is not found in this search, the merchant 603 can be confident that it has never appeared on the blockchain and thus has never been spent. If it is found that there are no suspicious points in the blockchain search, Alice 602 must then prove to the merchant 603 that the serial number and the double - spending formula are all correctly formed. Finally, Alice 602 must prove that the counter is within the correct range.

[0385] When the merchant 603 accepts the coin, it creates a consumption 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. Since the hash <h 2 =SHA - 256(data 2 )> is included in the output, Alice 602 indirectly signs it and it cannot be changed. Then she sends this to the merchant 603, who adds his own input and change to himself and signs the entire transaction. This input is included to represent the signature from the merchant for accepting the coin.

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

[0387] This transaction is a record by merchant 603 that the merchant received the coin without sharing all the information necessary to deposit the coin, because, as before, no one other than the merchant knows the preimage of R. Additionally, the signature for the proof of knowledge is kept secret. The only information shared here is what is necessary to identify the double spender, and the rest of the knowledge is hidden until the coin is deposited. Note that if merchant 603 discovers that Alice 602 is attempting double spending, bank 601 can motivate merchant 603 to pass on the coin details so that Alice 602 can be identified.

[0388] Here, merchant 603 contacts bank 601 to deposit the coin at any time convenient for the merchant. Bank 601 accepts only the coins that first appeared in the second transaction if all previous transactions have the correct format. Merchant 603 gives the transaction, the preimage of R, and the signature Φ to bank 601. Bank 601 then checks the blockchain for the data to confirm that the serial number S and R are being presented to the bank for the first time and that the serial number is not on the blacklist. They should appear only once within the transaction presented by the bank. If this holds, bank 601 verifies the same proof as merchant 603 and, in addition, that the withdrawal transaction and the consumption transaction are correctly formed. Once all these verifications are complete, the deposit transaction of Figure 12a is published to the blockchain.

[0389] This transaction notifies that merchant 603 has deposited coins and bank 601 has accepted them. The input is from a consumption transaction and is signed by both merchant 603 and bank 601, indicating that both of them were involved in this interaction. The first output is simply the change to the bank (if any), and the second output contains the data shown in Figure 12b. There is space to publish the double - spent serial number. If it is determined that the deposit is a deposit of a double - spent coin, bank 601 can check whether Alice 602 or merchant 603 should be held responsible. If it is a coin with the same serial number and merchant ID R, merchant 603 is considered to be responsible and bank 601 rejects the coin. If the merchant IDs are different, Alice 602 is responsible. And bank 601 uses the double - spending formula to calculate Alice's key g u and her seed s', from which all serial numbers can be calculated, consume all UTXOs created by Alice 602, and additionally can publish the serial numbers on the chain.

[0390] The greatest advantage of this system over the first system is that the coins are completely untraceable. Bank 601 can know that it has issued coins to Alice 602 and that merchant 603 has deposited coins, but does not know which route the coins have taken from withdrawal to consumption, unless it is the result of double - spending.

[0391] Both the traceable protocol and the untraceable protocol prevent someone from double - spending at the point of sale, because the merchant checks at this point rather than at the time of deposit for previously consumed coins. This applies to any digital coin system implemented in this way. Additionally, since 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 previous ecash systems by using two properties of the blockchain. The first property used is the fact that since the blockchain is a distributed immutable database, the list of consumed coins is publicly available to anyone. This makes it easier for the person receiving the coin to check whether the coin has already been consumed. Additionally, these protocols utilize the binary state of an output transaction being either consumed or not consumed. Since the state of an output cannot be consumed again once it changes from unconsumed to consumed, double - spending is simply impossible.

[0393] Each stage of coin withdrawal, consumption, and deposit can be connected and is, in a sense, "traceable". Anyone can see that a digital coin has been withdrawn, consumed, and deposited, but the user's identifying information is hidden from everyone except those who have knowledge of the identifying information corresponding to the public key used in each transaction (this is a feature common to blockchains in general). The important difference is that in a traceable protocol, the bank 601 knows exactly who withdrew the coin, while in a non - traceable protocol, the bank 601 does not know the identity information of the withdrawer at the time of deposit.

[0394] The following describes some exemplary ecash protocols that can be implemented using the general transactions of FIGS. 13a through 13c by specifying the content of the OP_RETURN data.

[0395] Chaum ecash protocol Figures 14a through 14c each show exemplary OP_RETURN data for a withdrawal transaction, a spending transaction, and a deposit transaction according to this protocol. Chaum's is an online ecash system, which means that the bank has to be online in order to accept any coins at the time they are spent. Moving this protocol on the chain makes the ecash protocol go offline.

[0396] Alice wishes to obtain coins from the bank and she spends it at a merchant. The bank selects two RSA prime numbers p, q, calculates n = p·q, and keeps the factorization secret. Then, calculating the m-th root of an integer modulo n is computationally infeasible without knowledge of the prime factorization. This concept serves as the bank's signature on the coin. The coin is (s,f(s) 1 / 3 mod n) in the form of, where f is some one-way function such as a hash function, which is publicly known, and s is the random seed of 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 and it can be the calculation of the m-th root of f(s) mod n for any m ≥ 2 as long as the choice of m is constant for all the ecash withdrawn. To issue a coin, the following steps are taken.

[0397] Alice selects a random coin seed s and a blinding value r, and sends the "blinded" coin serial number B = r 3 ·f(s) mod n to the bank. The bank calculates the cube root of B, B 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. This is because only the bank knows the factorization of n, so 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, since the bank does not know the value of r, it cannot determine 1 / 3 f(s) mod n. However, the bank knows that it has calculated this value and that no one else can calculate it. Alice C = r -1 ·B 1 / 3 = f(s) 1 / 3 mod n As such, by multiplying this result by the reciprocal r of her blinding value, 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 mod n). Alice then stores this and is ready to spend it when needed. 1 / 3

[0398] At this point, the bank does not know the explicit value of f(s) 1 / 3 mod n, so it is important to note that when it is later deposited, the bank will not be able to associate it with this conversation. However, the bank can verify that it is a cube root modulo n and that only the bank has the ability to calculate this, so the bank knows that it has "signed" it. In this example, it is only possible to withdraw a single coin. To withdraw more than one coin, this protocol will be repeated for different s and r.

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

[0400]

Number

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

[0402] Before using the blockchain, the merchant contacts the bank to verify that the coin has not already been spent before accepting it. The bank can then further confirm that this coin has the correct format by calculating the same result as the merchant. Once the coin is verified, the bank adds this coin serial number to its database.

[0403] The great advantage of using the blockchain to record Chaumian ecash is that it makes the protocol offline. Instead of contacting the bank to immediately check the database, the merchant can check this distributed database himself and reject coins that have already been spent. This applies to any online protocol. Coins can be moved offline from the blockchain.

[0404] In addition, 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 the bank does not sign the same coin more than once, so there is only one spendable UTXO for the withdrawal transaction representing the coin. And, similarly, since the UTXO of the corresponding withdrawal transaction can only be spent once, the deposit can only occur once. In an untraceable protocol, this depends on both the nature of this UTXO and the nature of the distributed database. Here, the merchant and the bank must ensure that no other withdrawal transactions corresponding to the same coin are created. This is sufficient to improve Chaumian ecash.

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

[0406] The Chaum ecash system described above can be extended to allow cash to be spent offline without using a blockchain. This is done by incorporating the identifier information of the withdrawer into the coin, and it can be calculated whether the withdrawer double-spends their identifier information. It is also possible to withdraw more values at once (and different values at different times). This means that a merchant can wait for the coin to be deposited, and if it is a double-spend, the identifier information of the double spender can be calculated. Additionally, in this protocol, Alice can j spend coins up to the withdrawn value of 2 - 1 and 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 and n' such that n = p·q and n' = p'·q', where p, q, p', q' are prime numbers 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 will be seen, if she double-spends, her bank account number will be derivable. Two collision-resistant functions f and g with two arguments are publicly known. That is, there are two functions with two arguments.

[0408] When Alice has a value of 2 j If she wishes to withdraw a coin of - 1, she sends t pairs of the formula to the bank and calls these "major" candidates and "minor" candidates. The major candidates contribute to the serial number of the coin and double - spending prevention. And the minor candidates are used to obtain change from the transaction. In addition, the relationship between the number t of pairs and how many coins Alice wishes to withdraw will be known eventually. For each major candidate, Alice randomly selects a, b, c, d, e, r with bit - length l for i = 1,..., t. The major candidate M is in the form of M = f(x, y), where x = g(a||b, c) and || means concatenation. And each minor candidate m is given by m = g(b, e). Alice blinds the candidates using the random value r. i b i c i d i e i r i is randomly selected. The major candidate M i is 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 given by m i = g(b i , e i ).

[0413] Alice blinds the candidates using the random value r i and

[0414]

Number

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

[0416]

Number

[0417] as follows.

[0418] Alice sends the blinded candidates to the bank. The bank randomly selects half of the pairs and clearly verifies that they have the appropriate form. Then, there remain 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 is withdrawing one coin with value 2 j -1, but she could have sent more candidates at this point that could be split into multiple coins. This is done by the bank that simply divides the remaining major candidates into a set of size k. In this way, the size of t depends on the number of coins Alice wishes to withdraw. The bank selects the degree of the remaining candidates and then 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 extracts

[0426]

Number

[0427] for the major candidates

[0428]

Number

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

[0430] To make a purchase, Alice first labels the first j of M i as denominations 1, 2,..., 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 pre-images of y i 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 is only to reveal. To prevent double spending in the following way, the last k - j terms are used. The merchant selects random binary strings z j+1 ,...,z k . For j < l ≤ k, if z l = 1, Alice reveals to the merchant the preimages of y i and x i . For j < l ≤ k, if z l = 0, Alice reveals to the merchant the preimages of x i and y i . And if Alice double - spends, the probability that the merchant selects different strings is high, and it is possible to calculate Alice's account number from any of the colliding bits z l , which is why the larger k - j is, the more secure the prevention of double spending becomes. Alice gives the merchant all the relevant preimages of the coin.

[0431] The bank verifies that the coin has not been consumed previously by checking the blockchain and / or the bank's off - chain database of consumed coins (the database can be stored on the chain). If it has not been consumed, the bank then adds S and the preimages given to the merchant to the database. For Alice to get change, she brings E i as well as the preimages b i and e i to the bank. The bank compares i and b i with previously consumed coins and identifies Alice as a double - spender if they have been presented before.

[0432] Alice, as a merchant, may consume coins and obtain a refund before the merchant contacts the bank. If the bank stores her identification information along with the counterfeit transaction, the bank can identify her and charge her bank account. However, if she withdraws the value as cash again, there is no way to prevent it from being consumed as long as she acts legitimately. This attack can be prevented by using a blockchain, as will be explained below.

[0433] It is possible to modify this scheme so that all coins withdrawn by Alice are invalidated when double spending is detected. This is done by linking the initial candidates within the matrix, where each initial candidate has an index corresponding to its position in the matrix. And the bank can blacklist coins by publishing a blacklist on the chain, and the merchant can check any presented coin against this blacklist.

[0434] Moving this ecash system on the chain prevents double spending at the time of consumption rather than at the time of deposit. It is also possible to report this attempt of double spending to the bank, and the bank can identify Alice by signing the counterfeit transaction in the case of a traceable protocol. Finally, any double spender has identification information derivable from the information presented on the chain. This provides another deterrent to users attempting double spending.

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

[0436] Since this ecash can be exchanged as unendorsed ecash, Alice can prove that she owns the coins without revealing the entire coins.

[0437] This protocol has the same setup and withdrawal as the CHL protocol. For Alice to spend ecash with a merchant, they perform the following steps. Before giving the coin serial number S and the double - spending formula T to the merchant, Alice first selects a random endorsement (x 1 ,x 2 ,x 3 ). She calculates the un - endorsed coin (S', T', Φ', R, y), where

[0438]

Number

[0439] ,

[0440]

Number

[0441] , and y = PedCom(x 1 ,x 2 ,x 3 ). Φ' is a zero - knowledge proof that the un - endorsed coin (J, u, s, t, σ B ,x 1 ,x 2 ,x 3 ) is valid. S', T' are just intermediate values that she endorses, so that the actual coin represented by S, T becomes the value ultimately given to the bank. These values S, T were explained above. The un - endorsed coin is the blinded coin that can be given to the merchant later. Similar to CHL, the merchant can verify Φ' and confirm that the un - endorsed coin is valid. When Alice and the merchant intend to continue the exchange, the merchant gives the endorsement (x 1 ,x 2 ,x 3 ). Using this, the merchant can easily calculate the endorsed coin (S, T, Φ', R, (x 1 ,x 2 ,x 3 ), y) using the following equation

[0442]

Number

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

[0444] Alice can create as many unsigned coins as she desires, but can only be identified if she double-spends. This process enables Alice to show that she has the coin without sharing the coin, which means she can prove to the merchant that she actually owns the coin.

[0445] In addition, even if the sale is not completed, Alice can use her unsigned coins elsewhere without being identified. In CHL, if Alice gives the coin to the merchant and for some reason the exchange is not completed, she cannot use her coin elsewhere without the possibility of being identified. If two different merchants have the same serial number with different double-spending formulas, they can use those double-spending formulas to calculate her identification information.

[0446] In this protocol, the merchant deposits the coin (S, T, Φ', R, (x 1 , x 2 , x 3 ), y) and the bank, under the same conditions as for CHL coins, further (u, s, t, σ B , J, x 1 , x 2 , x 3 ) A new signature Φ' for () can be verified. The bank can identify double spenders in the same way as before by remembering (S, T, R) for any presented coin on the blockchain.

[0447] As with other ecash protocols, double spending is now prevented at the time of spending rather than at the time of deposit. This is because merchants can check this distributed database for previously spent coins. Additionally, traceable ecash prevents double spending by making it impossible to double spend UTXOs. Untraceable ecash relies on this and the fact that anyone can check for previously spent coins. In this protocol, like other protocols, anyone can also calculate the identifying information of double spenders, which serves as another deterrent to double spending attempts.

[0448] Practical Compact Ecash Figures 17a through 17c each show exemplary OP_RETURN data for withdrawal transactions, consumption transactions, and deposit transactions according to this protocol.

[0449] This protocol allows for spending multiple coins at once. That is, either spending the entire wallet at once, called "compact" spending, or spending multiple coins at once, called "batch" spending.

[0450] This is similar to the original CHL protocol, but the bank needs to sign four messages (instead of three) with a signature, and the bank additionally signs an integer representing a signature on a counter. Assume the bank has a public key / secret key pair (pk B , sk B ) that can use the CL signature scheme to sign four messages with one signature. It has the form where the public key is (n, a 1 ,..., a 4 , b, c), and the secret key is n = p 1 p 2 such that p is a special RSA modulus 1 which means that. Additionally, both Alice and the merchant each have several

[0451]

Number

[0452] for (pk u , sk u ) = (g u , u) generate a unique key pair such that, m is a prime number, and g ∈ G. Finally, the integers σ B (1), σ B (2),..., σ B (k) signed by the bank are published, where k = 2 l which is the number of coins to be withdrawn. These are denoted as σ 1 := σ B (1), σ 2 := σ B (2),..., σ k := σ B (k = 2 1 ).

[0453] Withdrawals are very similar to CHL withdrawals. The only difference is that the bank signs an additional variable called y along with other seeds. To withdraw 2 l coins, the following steps must be taken. In this protocol, Alice can only withdraw a wallet containing 2 l coins due to the nature of the zero - knowledge proof of the value of the internal coin counter J of the wallet.

[0454] Alice identifies herself to the bank by proving knowledge of sk u using the zero - knowledge proof described in the preparation section. Then, Alice and the bank generate the wallet secret in the following way. Alice takes random values s, t,

[0455]

Number

[0456] Select and Pedersen Commitment

[0457]

Number

[0458] Send it to the bank. The bank selects a random integer r' to contribute to the wallet and sends this to Alice. Both the bank and Alice calculate

[0459]

Number

[0460] respectively.

[0461] This step is basically to create the wallet's secret and give the bank randomness at this step. Alice and the bank execute 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) results, where

[0462]

Number

[0463] is. The method for calculating this signature is given in the preparation section, where (x 1 , x 2 , x 3 , x 4 ) is (u, s, t, y). Alice creates the wallet W = (u, s, t, y, σ B (u, s, t, y), J) is saved, where J is an l-bit counter initialized to 0. Since the bank's signature is only for the wallet seeds s, t, y, the serial number and double-spending formula do not necessarily have to be stored in the wallet. Instead, note that they can be derived using the wallet seed and wallet counter when needed. The bank debits 2 l coins from the account corresponding to Alice.

[0464] At this point, depending on whether Alice wishes to spend the entire wallet at once or wishes to spend n of the coins in the wallet, the protocol splits into two. 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] For compact spending, to spend the entire wallet, Alice and the merchant perform the following steps. Alice sends =PedCom(s, t, u, y), where s, t, u are the same as in CHL and y is another random number used to prevent double compact spending. Alice then sends T c = g u g R / (y+1) , and a proof that she has the signature σ B from the bank for (s, t, u, y). Finally, Alice discloses s, t to the merchant. If the proof of the signature is valid and s, t are correct, the merchant accepts the coins.

[0466] For batch spending, to spend n coins, the following steps are taken. Alice sends the commitment C = PedCom(s, t, u, y, J) and S i = g 1 / (s+J+i+1) , T i = g u g R / (t+J+i+1) for i = 0,..., n - 1.

[0467] She also sends (σ B , s, t, u, y, σ J , j, σ J+n-1 Send a zero - knowledge proof of knowledge of the signature for ) and σ J and σ J+n-1 and σ are signatures for the first and last values of the coin counter. The zero - knowledge proof of knowledge of signature Φ is the signature σ for (s, t, u, y) B , the signature σ for J J , the signature σ for J + n - 1 J+n-1 , all S for i = 0,..., n - 1 i and T i , and a signature that provides knowledge that C is a commitment for the value (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 information about the coin and the signature for the zero - knowledge proof of knowledge. If the merchant has deposited batch consumption, the bank must calculate all serial numbers and double - spending formulas and store them as if they were consumed individually. The bank then stores (S i , T i , R), where S i and T i are for all individual coins deposited, and in the case of compact consumption, the bank stores T c . Then the formula for calculating the double - spender's identification information is as follows. If Alice performs two compact consumptions,

[0469]

Number

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

[0471] As expected, the OP_RETURN data is almost identical to CHL ecash. Note that for compact consumption, there are minor modifications to the protocol, and the merchant, rather than the bank, must calculate all serial numbers. This is then published on the chain in the consumption transaction. If the merchant waits for the bank to calculate all serial numbers, Alice can double - spend a single coin consumed as compact consumption.

[0472] Like other protocols, this protocol prevents double - spending at the time of consumption rather than deposit. As with previous protocols, this is because the merchant now has access to the database (blockchain) of consumed coins. The merchant can check this database and reject coins that have already been consumed. In addition, now the identification information of the double - spender can be calculated by anyone with access to the information on the chain. This serves as a deterrent to anyone, as there is a risk of ruining one's reputation.

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

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

[0475] p and q are large prime numbers with corresponding binary length l p , l q accompanied by, g, g 1 ,

[0476]

Number

[0477] Let p, q, g, g be such that has degree q. 1 , g 2 be publicly known system parameters. 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] is. The bank calculates z = (Ig 2 ) x mod p and sends it to Alice. Alternatively, the bank

[0484]

Number

[0485] and

[0486]

Number

[0487] Since it can be published as part of the public key, the user can calculate it by themselves.

[0488] Alice wishes to withdraw coins from the bank. The bank generates a random number

[0489]

Number

[0490] and sends \(a = g^r\) w and \(b=(I g^r)\) 2 to Alice. Alice sends the blinded coin to the bank and obtains a Schnorr signature from the bank in the following way. Alice w generates three random numbers \(r\), \(x\)

[0491]

Number

[0492] , and \(x\) 1 ,

[0493]

Number

[0494] and calculates \(S=(I g^r)\) 2 and s and \(z' = z^r\)

[0495]

Number

[0496] . \(S\) is the serial number of the coin, \(B\) is used in the zero - knowledge proof of the coin's seed, and \(z'\) forms part of the Schnorr signature. Alice generates two more random numbers \(\mu, v\in\mathbb{Z}\) S and calculates \(a' = a^\mu\) q and μ g v and b' = b sμ S v Calculate. These two values also form part of the Schnorr signature. Alice finally calculates the challenge c' = H(S, B, z', a', b'), where H is some collision-resistant hash function that produces an l H bit output. Alice then sends the blinded challenge c = c'μ -1 mod q to the bank. Alice gives c' to the merchant who returns it to the bank, but it should be noted that the important point is that the bank cannot identify which c and c' are related, so the deposit cannot be linked to Alice's withdrawal. The bank responds with r = cx + w mod q and debits Alice's account. Alice accepts as long as r g c = h 2 ) r = z c b. Alice then calculates r' = rμ + v mod q. This is the last part of the signature. Finally, the signed coin is (S, B, σ(S, B) = (z', a', b', r')).

[0497] If Alice wishes to spend the coin at a merchant, they perform the following steps. To spend the coin (S, B, σ(S, B)), Alice first sends it to the merchant. The merchant checks if S ≠ 1 and then calculates the challenge R = H 0 (S, B, ID M , date / time) and sends it to Alice, where H 0 is another collision-resistant hash function, ID M is the merchant's identification information, and date / time represents when the transaction takes place. Alice calculates r 1 = R(us) + x 1 mod q and r 2 = Rs + x 2 mod q and sends the response to the merchant. The merchant finally

[0498]

Number

[0499] and confirm 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 it holds, the merchant accepts the coin.

[0500] The merchant sends a payment transcript consisting of S, B, σ(S,B), (r 1 ,r 2 ), and the date and time of the transaction to the bank. If S = 1, the bank rejects the deposit. Otherwise, the bank uses the identification information of the merchant who sent the transcript to verify the same information according to the transcript. If this is verified, the bank checks whether S is not yet stored. If not, the bank stores (S, date / time, r 1 ,r 2 ,R) and credits the merchant's account. If S has appeared before, the bank determines the identification information of the double spender in the following way. If the date / time data is the same, the bank knows that the merchant is a double spender and immediately rejects the coin. If the times are different, the bank knows that the user is a double spender. The bank can use (r 1 ,r 2 ,R) and (r 1 ',r 2 ',R') to calculate the private key u using (r 1 -r 1 ') / (r 2 -r 2 '). The bank then

[0501]

Number

[0502] By calculating, the identification information of double consumers can be discovered.

[0503] Also, moving this protocol on the chain shifts the detection of double spending to the point of consumption. This means that double spending will never occur because it is detected immediately. Along with this, the identification information of those attempting double spending becomes derivable by anyone with access to the blockchain. Like other protocols, this discourages users from double spending to protect their reputation.

[0504] Restorable ecash (LTW) Figures 19a through 19c each show exemplary OP_RETURN data for a withdrawal transaction, a consumption transaction, and a deposit transaction according to this protocol.

[0505] This protocol is an extension of the Brands protocol and adds a recovery center to the protocol so that Alice can recover lost coins. This extension can actually be applied to any protocol where coins are not splittable or transferable, as is the case with all the protocols described here.

[0506] This protocol has the same parameters as Brands. That is, p and q are large prime numbers with corresponding binary lengths l p , l q accompanied by, and g, g 1 ,

[0507]

Number

[0508] such that p, q, g, g 1 , g 2 are publicly known system parameters, and

[0509]

Number

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

[0511]

Number

[0512] is used as Alice's private key, and her public key is

[0513]

Number

[0514] is. The bank calculates z = (Ig 2 ) x mod p and sends it to Alice. Alternatively, the bank

[0515]

Number

[0516] and

[0517]

Number

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

[0519] To withdraw n coins, Alice performs the following steps. First, she executes a protocol like Brands' ecash to obtain (S i , B i , σ(S i , B i )) for i = 1,..., n, where n is the number of coins. RC prepares n numbers x n (x 1 ) = H n (x 2 ) = … = H n (x n ) = y, where H 1 ,...x n is defined as an n - collision cryptographic hash function that produces an output of l n bits. This means that RC can find n inputs that produce 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 pre - image. Alice sends the coin (S H' , B i , σ(S i , B i , B i )) to RC and records the serial number S i . RC verifies the signature for each i. If it is valid, RC

[0520]

Number

[0521] calculates. RC returns x i ,

[0522]

Number

[0523] . Alice takes x i ,

[0524]

Number

[0525] Attach it to the coin. RC is another signature S b =σ RC (y, n) is calculated, and S b , y is sent to Alice. Alice securely stores this for restoration purposes.

[0526] To spend the coin with the merchant, Alice does the following. Alice and the merchant execute the payment protocol in the same way as Brands. The merchant then

[0527]

Number

[0528] is a valid signature for (S i , B i , σ(S i , B i ), x i ). The merchant calculates y = H'(x i ) and checks whether y is on the blacklist, which is a list of all coins reported to the bank as lost. If all these checks pass, the merchant accepts the coin.

[0529] To deposit the coin with the bank, the following steps are completed. The merchant and the bank perform the deposit as in Brands. Additionally, the bank checks whether the hash value of x i of each coin is in the blacklist. If not, the coin is accepted.

[0530] To restore a lost coin, Alice must do the following steps. Alice reveals her identification information to the bank and sends (S b , y) to the bank. The bank checks S b Verify whether it is a valid signature for (y, n). The bank checks the database to find all coins where the value of H' is equal to y. The maximum number of coins should be n. There are already spent coins. The bank calculates the difference between the total amount of coins and the spent amount and returns that difference as a value. To prevent double - spending, this y is then added to the publicly available blacklist. If any customer tries to spend a coin that has been refunded, the merchant does not accept the transaction. This is very similar to Brands. The difference is that there is additional space for broadcasting the restored coins.

[0531] This protocol already has the concept of a database that merchants can check for coins on the blacklist. Thus, in addition to being able to detect double - spending earlier on the chain in the same way as other ecash, moving this protocol on the chain naturally incorporates these spent coins into the same list as other coins on the blacklist.

[0532] Bounded - accumulator ecash (ACC) Figures 20a through 20c each show exemplary OP_RETURN data for a withdrawal transaction, a consumption transaction, and a deposit transaction according to this protocol.

[0533] This protocol makes coin storage more efficient and involves a bounded accumulator. An accumulator is the concept of storing any number of values in the same - sized storage, with proof when a value is added to the accumulator and no proof when a value is not added to the accumulator. The concept of a bounded accumulator is simply the concept of an accumulator with an upper limit on the number k of values that can be added to the accumulator.

[0534] Assume that g, h ∈ G are generators of G of degree p. All elements of G have length l G Assume it has a unique binary representation. First, the bank sets up a public / private key pair (x, g x ), and a bounded accumulator with an upper bound k. Each user has a public / private key pair in the form of (u, g u ).

[0535] To withdraw k coins, Alice executes 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. She accumulates s i to form the accumulated value v, and obtains k proofs w i . Then the bank signs σ B = sig(v, commit(u)). Then the wallet has the form (σ B , s i , w i , u) for i = 1,..., k.

[0536] To spend a coin, Alice executes the following steps. The merchant's identification information is denoted by ID M . Alice selects an unused random number from her wallet and

[0537]

Number

[0538] calculates.

[0539] Alice generates a non-interactive zero-knowledge proof of the following knowledge π 1 . ·verify(σ B , v, commit(u)) = 1 ·s i is in v using w i as a proof ·S, T, Y are correctly formed

[0540] Alice calculates the signature of knowledge π for the representation of Y that uses T as a commitment. This is to calculate z 2 such that it becomes

[0541]

Number

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

[0543] To deposit coins, the merchant provides the communication transcript of the consumption protocol to the bank. The bank verifies the transcript in exactly the same way as the merchant. In addition, the bank can verify that ID M is the merchant's identification information and that (ID M ||info) has not been used before, preventing malicious merchants from intercepting legitimate transactions and consuming coins. If these are verified, the bank stores (S, c, z u ). In the case of double - spending, S exists in the database. The bank can then calculate u using u = (z u - z u ') / (c' - c). The output is the identification information of the double - spender in the form of g u . If z u is the same, the bank can consider that the merchant is acting maliciously by attempting double - deposit, and the bank rejects the deposit.

[0544] This protocol can be extended to include tracking all coins of the double - spender in the following way. During a withdrawal, Alice obtains a signature on (v, commit(u, tr)), where tr is a random number. Alice verifiably encrypts tr under her secret key u, and the bank stores this encrypted value. During the spending protocol, Alice additionally computes a tracking R = H(ID M ||info) tr where H is a hash function that yields an l H - bit integer. Then the signature π 1 is modified to include · verify(σ B , v, commit(u, tr)) = 1 · s i is in v using w i as evidence · S, T, Y, R are correctly formed .

[0545] If Alice double - spends, the bank can compute u and then decrypt tr. The bank can then put tr on a blacklist, and anyone can check if the user is spending them, and can reject any further spending. At the point of sale, the merchant simply checks if tag = H(ID M ||info) tr is the same as what was presented to the merchant for each tr on the respective blacklist.

[0546] As with other protocols, double - spend detection occurs at the time of spending, so it completely prevents double - spending. Separately, moving this protocol on - chain enables anyone to identify double - spenders, which serves as a deterrent against users double - spending.

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

[0548] Statement 1. A method implemented on a computer 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 represents an amount of an asset that can be exchanged by an exchanger in exchange for the digital coin, the issuer maintains a record of coin serial numbers, each coin serial number represents a respective digital coin, the method being executed by the issuer, the method comprising the steps of: obtaining a consumption transaction, wherein the consumption transaction is a blockchain transaction and comprises a first coin serial number from a set of coin serial numbers; determining whether the first coin serial number exists in a database of consumed coin serial numbers; and transferring, in response to one or more conditions being satisfied, the amount of the asset represented by the first coin serial number to the exchanger, wherein a first condition of the one or more conditions is that the first coin serial number does not exist in the database.

[0549] Consumer transactions are used to carry tokens (coins, sometimes called bitcoins) of the underlying blockchain (the "first system"), but the digital coins are part of a different system (the "electronic cash system"). That is, consumer transactions, withdrawal transactions, and deposit transactions are necessarily used to transfer ownership of a certain amount of tokens (e.g., bitcoins) of the underlying blockchain and also to transfer ownership of digital coins of the electronic cash system. In other words, the coin serial number identifies the digital coin of the electronic cash system and does not identify the digital coin (e.g., bitcoin) of 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, the coin serial number does not identify the amount of the underlying blockchain token (e.g., bitcoin).

[0550] Statement 2. The method of Statement 1, wherein the record of the coin serial number is maintained on the blockchain.

[0551] Statement 3. The method of Statement 1 or Statement 2, wherein the consumer transaction comprises an output locked to the issuer's issuing public key, and the obtaining of the transfer transaction comprises obtaining the consumer transaction from the consumer and / or from the 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, and each output comprises an indication of each coin serial number of a set of coin serial numbers.

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

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

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

[0556] Statement 7. The method according to any one of Statements 4 to 6, wherein a second one of the one or more conditions is that the consumption transaction comprises an input for unlocking the output of the withdrawal transaction.

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

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

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

[0560] Statement 11. A method according to any preceding statement, wherein the exchanger is associated with an exchange private key-public key pair, and a fourth condition of one or more conditions is that the consumption transaction comprises further input, the further input comprising a signature generated based on the exchange private key.

[0561] Statement 12. A method according to any preceding statement, comprising: obtaining a deposit transaction, the deposit transaction comprising input that references an output of a consumption transaction and comprises one or more of a signature generated based on an issuance private key, a signature generated based on a consumption private key, and / or a signature based on an exchange private key; and transmitting the deposit transaction to an exchanger, a third party, and / or a blockchain network for recording on the blockchain in response to one or more conditions being satisfied.

[0562] Statement 13. A method according to any preceding statement, comprising: obtaining a blinded version of a coin seed at least partially generated by a 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.

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

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

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

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

[0567] Act 16. The exchanger is associated with a known identifier, and the method comprises a step of obtaining an identifier proof candidate, wherein the identifier proof candidate represents knowledge of an identifier candidate of the exchanger, and a step of determining whether the identifier candidate represented by the identifier proof candidate is the known identifier of the exchanger, wherein the seventh of one or more conditions is that the identifier candidate represented by the identifier proof candidate is the known identifier of the exchanger, the method according to any preceding Act.

[0568] Statement 17. The method of any preceding statement, wherein a first coin serial number is associated with respective counter values, the method comprising: obtaining a counter proof candidate, the counter proof candidate representing knowledge of a counter candidate for the first coin serial number; and determining whether a counter value candidate represented by the counter proof candidate is within a predetermined range, wherein an eighth one of 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: obtaining a blinded version of at least one double-spending seed generated by a consumer, the at least one double-spending seed being for generating at least one double-spending value, each double-spending value being based on the double-spending seed, an identifier of the consumer, and respective data items selected by an exchanger, each double-spending value revealing different components of the identifier of the consumer for different respective data items; generating a blind signature for the at least one double-spending seed; and transmitting the blind signature for the at least one double-spending seed to the consumer.

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

[0571] Statement 19. The method of Statement 18, comprising: obtaining a double-spending value; and revealing an identifier of the consumer using the obtained double-spending value and a previously obtained double-spending value in response to determining that the first coin serial number exists in a database of spent coin serial numbers.

[0572] Statement 20. The withdrawal transaction has a plurality of outputs, each output having a hash of one of the sets of coin serial numbers, each output being locked to an issuing public key, the method comprising, in response to determining that a first coin serial number exists in a database of coin serial numbers that have been consumed, consuming each output locked to the issuing public key, the method of Statements 4 and 19.

[0573] Statement 21. The consumption transaction has an output having a hash of each coin serial number of a set of coin serial numbers, the method comprising, in response to determining that a first coin serial number exists in a database of coin serial numbers that have been consumed, consuming the output having a 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, the method of Statements 6 and 19.

[0574] For example, a double-spent coin may not yet be on the chain, i.e., it may be in some hash. This occurs when all hashes of coin serial numbers are not yet on the chain since the consumption transaction includes the hash of the next coin. Thus, the bank may broadcast the serial number to prevent the next coin from being consumed.

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

[0576] Statement 23. The method of Statement 22, wherein the record of 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 by an issuer to a consumer, each digital coin represents an amount of an asset that can be exchanged by an exchanger in exchange for the digital coin, the method being executed by the consumer, the method comprising the steps of obtaining a withdrawal transaction, the withdrawal transaction having one or more outputs, each output comprising a hash of each 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 an exchanger, a third party, and / or a blockchain network for recording on the blockchain.

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

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

[0580] Statement 27. The method according to any one 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, the method comprising generating the first coin serial number based on a coin seed.

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

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

[0583] Statement 30. The method of Statement 29, comprising the step of sending the coin seed proof to the exchanger, wherein the coin seed proof represents knowledge of the blind signature on the coin seed.

[0584] Statement 31. The method of any one of Statements 24 to 30, wherein the first coin serial number is associated with each counter value, and the method comprises the step of sending the counter proof to the exchanger, wherein the counter proof represents knowledge of the counter value of the first coin serial number.

[0585] Statement 32. The method of Statement 27 or any statement subordinate thereto, comprising the step of sending the first coin serial number to the exchanger.

[0586] Statement 33. The method of any one of Statements 24 to 32, comprising the step of sending one or more double-spending values to the exchanger, wherein the one or more double-spending values are based on one or more respective double-spending seeds, the identifier of the consumer, and each data item selected by the exchanger, and each double-spending value reveals a different component of the identifier of the consumer for a different respective data item.

[0587] Statement 34. The method of Statement 33, comprising the step of obtaining each data item from the exchanger.

[0588] Statement 35. The method of Statement 33 or Statement 34, comprising the step of sending one or more double-spending value proofs to the exchanger, wherein the one or more double-spending value proofs each represent knowledge of the signature on the double-spending value and / or knowledge of the one or more double-spending values.

[0589] Statement 36. The double spending value is associated with the double spending counter value, and the method comprises the step of sending a double spending counter proof to the exchanger, the double spending counter proof representing knowledge of the double spending counter value of the double spending value, the method of Statement 35.

[0590] Statement 37. A method according to any of Statements 24 to 36, comprising the step of obtaining a consumption transaction, the consumption transaction comprising a first input for unlocking a first output of a withdrawal transaction, the first input comprising a signature generated based on a consumption private key, and the step of sending the consumption transaction to the exchanger, a third party, and / or a blockchain network for recording on the blockchain.

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

[0592] To prevent the bank from consuming the withdrawal output, a serial number that locks the output of the withdrawal transaction may be used (this is desirable in the case of double spending). Without a serial number that locks the output, the bank can consume the output at any time, not just in the case of double spending. This is less secure but not a problem if the bank can be trusted. Since the coin serial number also exists in the OP_RETURN output of the consumption transaction, it will be found as something to be consumed in the OP_RETURN output even if it is not in the withdrawal transaction locking script.

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

[0594] Statement 40. The method according to any of Statements 37 to 39, wherein the consumption transaction comprises a second output comprising a hash of a second coin serial number of a set of coin serial numbers.

[0595] Statement 41. A method implemented on a computer 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 represents an amount of an asset that can be exchanged by an exchanger in exchange for the digital coin, the method being executed by the exchanger and comprising the steps of: obtaining, from the consumer, a first coin serial number; determining whether the first coin serial number exists on the blockchain; in response to one or more conditions being satisfied, obtaining a consumption transaction, the consumption transaction being a blockchain transaction and comprising the first coin serial number; and transmitting the consumption transaction to one or more of the consumer, the issuer, a third party, and / or the blockchain network for recording 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 exchanger is associated with an exchange private key - public key pair and the consumption transaction comprises a first input generated based on the exchange private key and comprising a signature.

[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 generated based on the consumption private key and comprising a signature.

[0598] Statement 44. The method of Statement 43, wherein the second input of the consumption transaction is configured to unlock the output of a withdrawal transaction.

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

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

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

[0602] Statement 48. The method according to any one of Statements 41 to 47, wherein the first coin serial number is associated with respective counter values, the method comprising the steps of obtaining a counter proof candidate, wherein the counter proof candidate represents knowledge of a 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, the third of one or more conditions being that the counter value candidate represented by the counter proof candidate is within a predetermined range.

[0603] Statement 49. The method according to any one of Statements 41 to 48, comprising the step of obtaining from the consumer one or more double - spending values, wherein the one or more double - spending values are based on respective double - spending seeds, the consumer's identifier, and respective data items selected by the exchanger, and each double - spending value reveals different components of the consumer's identifier for different respective data items.

[0604] Statement 50. The method of statement 49, comprising the step of obtaining from the consumer one or more double-spending seed proofs, wherein the one or more double-spending seed proofs represent knowledge of the blind signature of each of one or more double-spending seeds used to generate one or more double-spending values, and wherein the fourth of the one or more conditions is that each of the blind signatures is generated by the issuer.

[0605] Statement 51. The method of statement 49 or statement 50, wherein each double-spending value is associated with a respective double-spending counter value, and the method comprises, for each double-spending value, the step of obtaining a double-spending counter proof candidate, wherein the double-spending counter proof candidate represents knowledge of a double-spending counter candidate for that double-spending value, and the step of determining whether the double-spending counter value candidate represented by the double-spending counter proof candidate is within a predetermined range, and wherein the fifth of the one or more conditions is that the double-spending counter value candidate represented by the double-spending counter proof candidate is within a predetermined range.

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

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

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

[0609] Statement 55. The method of any of statements 41 to 54, comprising the step of obtaining from the consumer an identifier hash, wherein the identifier hash is a hash of at least the identifier of the exchanger and a data item selected by the exchanger, and the step of sending the obtained identifier hash to the issuer.

[0610] Step 56. A step of obtaining a deposit transaction, wherein the deposit transaction comprises an input that references the output of a consumption transaction and includes one or more of a signature generated based on an exchange private key, a signature generated based on a consumption private key, and / or a signature generated based on an issuance private key; and a step of sending the deposit transaction to an issuer, a third party, and / or a blockchain network so as to be recorded on the blockchain in response to one or more conditions being satisfied. The method according to any one of Statements 41 to 55.

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

[0612] Statement 58. A step of sending to the issuer one or more of a first coin serial number, a consumption public key, one or more double-spending values, and / or a consumer identifier in response to determining that at least one of one or more conditions is not satisfied. The method according to any one of Statements 41 to 57.

[0613] Statement 59. A computer device comprising a memory having one or more memory units and a processing device having one or more processing units, the memory storing code configured to be executed on the processing device, and the code being configured to execute the method according to any one of Statements 1 to 58 when executed on the processing device.

[0614] Statement 60. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of Statements 1 to 58 when executed on the computer device of Statement 46.

[0615] According to another aspect disclosed herein, a method may be provided that includes actions of an issuer, a consumer, and an exchanger.

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

[0617] Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of this disclosure is not limited by the described embodiments, but is limited only by the appended claims.

Description of the Reference Numerals

[0618] 101 Network 102 Computer Device 103 User 104 Node 105 Client Application 106 P2P Network 150 Blockchain 151 Block 152 Transaction 153 Genesis Block 154 Pool 201 Header 202 Input 203 Output 301 Side Channel 401 Transaction Engine 402 UI Layer 411 UI Element, User Selectable Element 412 UI Element 413 UI Element 601 Issuer 602 Consumer 603 Exchanger< / g>

Claims

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 represents an amount of an asset that can be exchanged by an exchanger in exchange for the digital coin, the issuer maintains a record of coin serial numbers, each coin serial number represents a respective digital coin, the blockchain includes withdrawal transactions, the withdrawal transactions include one or more outputs, each output includes an indication of a respective coin serial number of a set of coin serial numbers, and when the output of the withdrawal transaction is executed together with an input of a later transaction, the input of the later transaction is configured to require a first coin serial number, the method being executed by the issuer, obtaining a consumption transaction, wherein the consumption transaction is a blockchain transaction and includes the first coin serial number of the set of coin serial numbers; determining whether the first coin serial number exists in a database of consumed coin serial numbers; transferring the amount of the asset represented by the first coin serial number to the exchanger in response to one or more conditions being met, wherein a first condition of the one or more conditions is that the first coin serial number does not exist in the database, and a second condition of the one or more conditions is that the consumption transaction includes an input for unlocking an output of a withdrawal transaction.

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

3. The method according to claim 1 or 2, wherein the consumption transaction includes an output locked with an issuing public key of the issuer, and obtaining the consumption transaction includes obtaining the consumption transaction from the consumer and / or from the blockchain.

4. The method according to any one of claims 1 to 3, wherein the indication is a hash of each coin serial number in the set of coin serial numbers.

5. The issuer is associated with an issuance 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 issuance private key, and sending the withdrawal transaction to the consumer, a third party, and / or a blockchain network for recording on the blockchain, the method according to any one of claims 1 to 4.

6. The consumer is associated with a consumption private key - public key pair, and the method is configured to require that when the output of the withdrawal transaction is executed together with the input of a subsequent transaction, the input of the subsequent transaction requires a signature generated based on the consumption private key, the method according to claim 5.

7. The method according to claim 5, wherein a third condition among the one or more conditions is that the withdrawal transaction comprises an input comprising the signature generated based on the issuance private key.

8. The exchanger is associated with an exchange private key - public key pair, and a fourth condition among the one or more conditions is that the consumption transaction comprises a further input, the further input comprising a signature generated based on the exchange private key, the method according to any one of claims 1 to 7.

9. The exchanger is associated with an exchange private key - public key pair, and the method comprises obtaining a deposit transaction, the deposit transaction referring to the output of the consumption transaction and comprising an input comprising one or more of a signature generated based on the issuance private key, a signature generated based on the consumption private key, and / or a signature based on the exchange private key, and sending the deposit transaction to the exchanger, a third party, and / or the blockchain network for recording on the blockchain in response to one or more conditions being satisfied, the method according to claim 6.

10. Obtaining a blinded version of a coin seed at least partially generated by the consumer, wherein the coin seed is for generating a set of coin serial numbers, and each coin serial number represents a respective digital coin; Generating a blind signature of the coin seed; Sending the blind signature of the coin seed to the consumer, the method according to any one of claims 1 to 9. **Claim 11** The method according to claim 10, wherein the coin seed is at least partially generated by the issuer. **Claim 12** Obtaining a coin seed proof candidate and / or a coin seed signature proof candidate, wherein the coin seed proof candidate represents knowledge of a coin seed candidate, and the coin seed signature proof candidate represents knowledge of a signature candidate of the coin seed; Determining whether the signature candidate represented by the coin seed proof candidate is the blinded signature of the coin seed, wherein the fifth condition among the one or more conditions is that the signature candidate represented by the coin seed proof candidate is the blinded signature of the coin seed; and / or Determining whether the coin seed candidate represented by the coin seed proof candidate is the coin seed, wherein the sixth condition among the one or more conditions is that the coin seed candidate is the coin seed, the method according to claim 10 or 11. **Claim 13** The exchanger is associated with a known identifier, and the method Obtaining an identifier proof candidate, wherein the identifier proof candidate represents knowledge of an identifier candidate of the exchanger; Determining whether the identifier candidate represented by the identifier proof candidate is the known identifier of the exchanger, wherein the seventh condition among the one or more conditions is that the identifier candidate represented by the identifier proof candidate is the known identifier of the exchanger, the method according to any one of claims 1 to 12. **Claim 14** The first coin serial number is associated with a respective counter value, and the method A step of obtaining a counter proof candidate, wherein the counter proof candidate represents knowledge of a counter value candidate of the first coin serial number A step of determining whether the counter value candidate represented by the counter proof candidate is within a predetermined range, wherein an eighth condition among the one or more conditions is that the counter value candidate represented by the counter proof candidate is within a predetermined range, the method according to any one of claims 1 to 13 comprising the step

15. A step of obtaining a blinded version of at least one double spending seed generated by the consumer, wherein the at least one double spending seed is for generating at least one double spending value, each double spending value being based on the double spending seed, the identifier of the consumer, and each data item selected by the exchanger, each double spending value revealing different components of the identifier of the consumer for different respective data items A step of generating a blind signature for the at least one double spending seed A step of transmitting the blind signature of the at least one double spending seed to the consumer, the method according to any one of claims 1 to 14 comprising the step

16. A step of obtaining a double spending value A step of revealing the identifier of the consumer using the obtained double spending value and a previously obtained double spending value in response to determining that the first coin serial number exists in the database of consumed coin serial numbers, the method according to claim 15 comprising the step

17. The withdrawal transaction comprises a plurality of outputs, each output comprising a hash of one of the respective coin serial numbers of the set of coin serial numbers, each output being locked to the issuing public key, the method comprising, in response to determining that the first coin serial number exists in the database of consumed coin serial numbers, a step of consuming each output locked to the issuing public key, the method according to claim 3 comprising the step

18. The consumption transaction comprises an output comprising a hash of each coin serial number of the set of coin serial numbers, and the method comprises, in response to determining that the first coin serial number exists in the database of consumed coin serial numbers, consuming the output comprising the respective hashes of the respective coin serial numbers of the set of coin serial numbers, and / or publishing the respective coin serial numbers of the set of coin serial numbers, the method according to claims 5 and 16.

19. The issuer maintains a record of identifier hashes, and the method comprises obtaining an identifier hash, the identifier hash being a hash of at least the identifier of the exchanger and a data item selected by the exchanger, wherein a ninth one of the one or more conditions is that the obtained hash does not exist in the database of identifier hashes, the method according to any one of claims 1 to 18.

20. The method according to claim 19, wherein the record of identifier hashes is maintained on the blockchain.

21. a memory comprising one or more memory units, a processing device comprising one or more processing units, the memory storing code adapted to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 20 when executed on the processing device, a computer device.

22. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 1 to 20 when executed on a computer device.

Images