Divisible Tokens

Abstract

A computer-implemented method for generating a second transaction for a blockchain. The blockchain includes a first transaction including a first token and a first output transferring an amount of a digital asset between a second party and the first party. The first token represents a first amount of a token asset other than the digital asset, and the second transaction is for transferring a second token representing a second amount of the token asset from the first party to a third party. The method is executed by the first party and includes generating a second transaction. The second transaction includes a first input configured to unlock the first output of the first transaction and a first output including the second token. The second token includes data representing a second amount of the token asset, the second amount being less than the first amount.

Description

[Technical field]

[0001] The present disclosure relates to methods for generating divisible tokens and transferring tokens between parties. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction may point to a previous transaction in the sequence, which may span one or more blocks. Transactions can be contributed to the network and included in new blocks through a process known as "mining." "Mining" involves each of multiple mining nodes competing to perform a "proof-of-work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

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

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

[0005] A universal electronic cash system, hereafter referred to as the Ok-Oh system (Okamoto T., Ohta K. (1992) Universal Electronic Cash. In: Feigenbaum J. (eds) Advances in Cryptology-CRYPTO '91. CRYPTO 1991. Lecture Notes in Computer Science, vol576. Springer, Berlin, Heidelberg), has been proposed previously, in which a trusted bank could issue electronic cash to its customers. Once issued, the customers had the flexibility to divide the cash into smaller parts. To spend the parts, the recipient had to rely on the bank to validate the transaction. After validation, the bank could settle the transaction in legal tender (fiat). Summary of the Invention

[0006] Although Okamoto and Ohta generally solved the double-spending problem, they did not consider the problem of double-spending replay, which is when a customer replays their payment to another merchant. Furthermore, the Ok-Oh system is limited to electronic cash.

[0007] The technology described herein improves upon previously proposed systems by using the security of a blockchain network to distribute divisible tokens that represent any asset. Similar to the Ok-Oh system, the divisible tokens may represent electronic cash. However, according to embodiments disclosed herein, the divisible tokens are not limited to representing electronic cash, but instead can be used to represent any asset, for example, company stock, artwork, or real estate. The divisible tokens can also be redeemed for services. For example, the tokens may represent a total amount (e.g., minutes) of media content that can be streamed from a content provider.

[0008] A single token can be split into multiple sub-tokens, each representing a smaller asset amount than a single token. These tokens can be used to redeem services, transfer ownership, purchase goods, etc. Additionally, providing transparency and auditability, some embodiments of the inventive system also solve the problem of replaying double spends while inheriting all the benefits from the Ok-Oh system.

[0009] According to one aspect disclosed herein, there is provided a method of generating a second transaction for a blockchain, the blockchain including a first transaction, the first transaction including a first token and a first output transferring an amount of a digital asset between a second party and the first party, the first token representing a first amount of a “token asset” (i.e., a second or further asset) other than the digital asset, and the second transaction for transferring a second token representing a second amount of the token asset from the first party to a third party. The method includes a step of generating the second transaction, the second transaction being executed by the first party, the second transaction including: i) a first input configured to unlock a first output of the first transaction; and ii) a first output including the second token, the second token including data representing the second amount of the token asset, the second amount being less than the first amount.

[0010] The first token is immutably stored on the blockchain in the first transaction and acts as a record of the amount of the token asset issued to the first party. For example, the token may be an amount of currency (e.g., 100 pounds), (the currency unit of Great Britain and Northern Ireland in this example). The second transaction has an input to unlock the first transaction, thus providing the first token to any party that issued it. The second transaction has an output that stores a second token. The second token is a division of the first token, i.e., it represents a second, smaller amount (e.g., 50 pounds or 75 pounds) of the token asset represented by the first token. To divide the first token, the first party includes data in the second token representing the second amount, the second amount being less than the first amount. For example, the data may include one or more values, each value representing a sub-amount of the first amount to be added to the second, smaller amount. For example, if the first party wants to transfer £75 to a third party, the second token may contain two values ​​representing £50 and £25, respectively. In this example, the third party still has the £25 value of her original token to appropriate for a different purpose. The term "token asset" is used simply as a label for the asset represented by the token. This can be a digital or physical (tangible) asset, and can be any asset other than the digital asset that is inherently transferred as part of the blockchain protocol of the blockchain network.

[0011] As another example, a first party (Alice) may be issued (with a first transaction) a first token representing complete (i.e., 100%) ownership of an asset, such as a house. The first party may decide to transfer partial ownership of the house to a third party, such as the first party's child, Charlie. If Alice decides to transfer 25% of her house to Charlie, she may include one or more values ​​that, when added together, represent 25%. For example, a single value represents 25%.

[0012] According to another aspect disclosed herein, there is provided a method of updating a second transaction for a blockchain, the blockchain including a first transaction, the first transaction including a first token and a first output for transferring an amount of a digital asset from a second party to a first party, the first token representing a first amount of a "token asset" (i.e., a second or further asset) other than the digital asset, and the second transaction for transferring a second token representing a second amount of the token asset from the first party to a third party. The method is performed by the third party, obtaining the second transaction, the second transaction including: i) a first input including the first token; and ii) a first output including the second token, the second token including one or more values, each value being used to represent a respective sub-amount of the token asset; determining whether the second transaction is valid based on a) whether each value was generated based on at least an identifier of the first transaction, and b) whether the first token in the second transaction is identical to the first token in the first transaction; updating the second transaction based on the determination by signing the second transaction with the public key of the third party; and sending the updated second transaction to the blockchain network for inclusion in the blockchain.

[0013] For example, the third party may receive the second transaction from the first party. The second transaction has a first input and a first output. The first input includes the first token. This may be the single token mentioned above issued to the first party, for example by a bank. Alternatively, the first token may itself be a division of a larger token. The first output includes one or more values, each value representing a sub-amount of the amount defined by the first token. For example, the first amount may be 120 units, each unit representing one minute of video, and values ​​may represent 45 units, e.g., one value representing 30 units and one value representing 15 units. The third party performs a set of checks to determine the validity of the second token. If the third party is satisfied, the third party signs the second transaction (e.g., by adding an input including the third party's signature to the second transaction). This updates the second transaction, which may be a template transaction that is not submitted to the blockchain, and the updated second transaction may be a complete transaction that is actually submitted to the blockchain.

[0014] When the updated second transaction is included on the blockchain, the second transaction serves as an immutable record of the transfer of a particular division of the divisible token from the first party to the second party. Because the second transaction is signed by the third party (Charlie), Charlie has attested to the amount of tokens he redeemed. The second token is a division of the first token. The third party is free to further divide the second token.

[0015] The third party may offer the first party something in exchange for the second tokens, for example something worth the second amount of the second tokens, for example the second amount may be £75 and Charlie may give Alice goods or services worth £75.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for generating a first transaction for a blockchain, the first transaction including a first output transferring an amount of a digital asset from a second party to a first party, the first transaction being for transferring a first token from the second party to the first party, the first token representing a first amount of a token asset other than the digital asset (i.e., a second or further asset), the method being performed by the second party; generating the first transaction, the first transaction including: i) a first output configured, when executed together with a second transaction input, to require the second transaction input to include a first public key of the first party to be unlocked; and ii) a second output including the first token, the first token including: a) a first amount of the token asset; and b) an encrypted identifier of the first party, the encrypted identifier being generated by encrypting an identifier of the first party with a second public key of the first party, the second public key including a modulus; and the first token including c) a modulus. The second party is a party that issues the first token to the first party.

[0017] For example, a service provider (e.g., an energy supplier) may issue a token redeemable for an amount of services, content, etc. to the first party. A token issuer generates a first transaction that includes the token among the transaction outputs. The token itself includes at least three data fields, one representing the total amount of the token and one representing a cryptographic identifier of the first party. The identifier is encrypted at least in part with a public key defined by a modulus, e.g., an RSA modulus. [Brief description of the drawings]

[0018] To aid in the understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates diagrammatically some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 1 is a schematic block diagram of the output-based model node protocol; the piece of node software that processes transactions. [Diagram 5] 1 illustrates a schematic diagram of a binary tree structure. [Figure 6] 1 illustrates generally a system for transferring divisible tokens between parties. [Figure 7] 1 illustrates an example representation of a first blockchain transaction. [Figure 8] 1 illustrates an exemplary representation of a first token. [Figure 9] 1 illustrates an example representation of a second blockchain transaction. [Figure 10] 13 illustrates an exemplary representation of a second token. [Figure 11]1 illustrates a schematic diagram of a mapping between token quantities and nodes of a binary tree structure. [Figure 12] Schematic of a binary tree structure along with the formula for computing the nodes of the tree [Figure 13] 14 illustrates an example representation of an updated version of a second blockchain transaction. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

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

[0022] For a given current transaction 152j, the input (or each of them) includes a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but the previous transaction 152i must exist and be verified for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in the chronological order. Thus, it does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or a predecessor transaction.

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

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

[0025] As part of the account-based transaction model, another type of transaction protocol is sometimes called an "account-based" protocol. In the account-based case, each transaction transfers by referencing an absolute account balance, rather than defining the amount to be transferred by referencing back to the UTXO of the preceding transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by miners separately from the blockchain. In such a system, transactions are ordered using the successive transaction records (so-called "positions") of the accounts. This value is signed by the senders as part of their cryptographic signatures and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

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

[0027] In an output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it has already been validly redeemed by an input of another onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of a preceding transaction 152i that it attempts to spend or redeem has not yet been spent / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded on the blockchain. This prevents double spending, where a payer attempts to spend an output of the same transaction multiple times. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, because of the defined order of transactions, an account balance has a single defined state at a time.

[0028] In addition to validating, at least some of the nodes 104M compete to be the first to create a block of transactions in a process called mining, which is backed by a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. This typically 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 satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. A property of a hash function is that it has an output that is unpredictable with respect to the input. This search can therefore only be performed by brute force and therefore uses a significant amount of processing resources at each node 104M trying to solve the puzzle.

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

[0030] Note that different miners 104M, who are constantly competing to solve the puzzle, may be solving the puzzle based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started looking for a solution. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, and the current pool of unmined transactions 154 is updated. Miners then continue to compete to produce blocks from the newly defined pending pool. There is also a protocol to resolve possible "forks", which are cases when two miners 104M solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150.

[0031] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nothing (a normal transaction transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generation" transaction. It automatically forms part of a new block 151n. This reward motivates miners 104M to participate in the proof-of-work competition. A normal (non-generation) transaction 152 often specifies an additional transaction fee for one of its outputs, further rewarding the winning miner 104M who produces the block 151n that contains that transaction.

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

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

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

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

[0036] The client application or software 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer readable storage media, for example downloaded from a server, or 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, for example a CD or DVD ROM, or a removable optical drive.

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

[0038] An instance of the client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet function of the client 105 to transmit the transaction 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust of transactions in part through its public visibility). The wallet function on each computing device 102 is configured to form and transmit the transaction 152 according to a transaction protocol. Each node 104 executes software configured to validate the transaction 152 according to the node protocol and, in the case of the forwarding node 104F, forward the transaction 152 for propagation throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model together with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although a transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes process different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

[0039] As described above, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 back to a previously created block 151 in the chain, so as to define a sequential order to the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the creation transaction) includes a pointer to a previous transaction to define an order to the sequence of transactions (note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153, but not to a preceding transaction.

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

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

[0042] Once in the pool 154 in the copy of the blockchain 150 maintained in one or more storage nodes 104, the miner nodes 104M start competing to solve the proof-of-work puzzle of the latest version of the pool 154 that contains the new transaction 152 (other miners 104M are still trying to solve the puzzle based on their old view of the pool 154, but whoever gets there will first define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j). Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0043] <UTXOベースのモデル> Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible implementations.

[0044] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It includes, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and output fields 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 submitted to the miner 104M.

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

[0046] For example, Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice into the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0047] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and sent to the network 102, or Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may equally be replaced by "preceding" and "inheriting" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily mean the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") will not be validated unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or miner behavior.

[0048] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the following transaction for the following transaction to be validated, and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

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

[0050] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A[ChecksigPA] contains the public key PA from Alice's public / private key pair. Input 202 of Tx1 contains a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 contains an index that identifies UTXO0 in Tx0, in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 further contains an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0051] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

number

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

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

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

[0055] In practice, Alice should usually also include a fee for the winning miner, because nowadays the reward of the generating transaction alone is usually not enough to motivate mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the miner's protocol does not force the miner 104M to accept the transaction 152 if the miner does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the 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 miner 104. For example, suppose that a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, nothing in this document precludes that a miner's fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0056] Note that if the total amount specified in all of a given transaction 152's outputs 203 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction will not be propagated or mined into a block 151.

[0057] Alice and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to aggregate the value of all the various UTXOs locked to each party that have not yet been used in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the storage nodes 104S, for example, the storage node 104S that is closest or best connected to each party's computer device 02.

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

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

[0060] A lock script is sometimes referred to as a "scriptPubKey" to denote that the respective transaction includes the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig" to denote that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions under which a UTXO is redeemed include authenticating a signature. More generally, the scripting language may be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" are preferred.

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

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

[0063] <Node software> FIG. 4 illustrates an example of node software 400 that may be executed by each node 104 of the P2P network 106 in the example UTXO or output-based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related functional modules 405. For any given node 104, these may include any one, two, or all three of a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on the node's role or roles). The protocol engine 401 is configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152m (Tx m ) is received, and another preceding transaction 152m-1 (Tx m-1 When the protocol engine 401 has an input that points to an output (e.g., a UTXO) of Tx j Based on the pointer in the input of Tx i It identifies and searches for Tx m-1 If Tx is not already in the blockchain 150, each node can choose to use it from its own pool of pending transactions 154, or m-1 If Tx is already in the blockchain 150, the node may obtain it from a copy of block 151 in the blockchain 150 stored in the respective node or another node 104. m-1 In either case, the script engine 401 may search for Tx i The script engine 402 then identifies the lock script in the output pointed to by the script.

[0064] The script engine 402 therefore m-1 Lock script, and Tx m 4. For example, Tx1 and Tx2 are shown in FIG. 4, but it can be applied to any pair of transactions such as Tx0 and Tx1, etc. The script engine 402 executes the two scripts together as described above, which includes putting data on the stack 403 and retrieving data according to the script language (e.g., Script) based on the stack being used.

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

[0066] In the output-based model, the result "true" from the script engine 402 is one of the conditions for the validity of the transaction. Typically, there are one or more further protocol-level conditions evaluated by the protocol engine 401 that must also be satisfied, and Tx j the total amount of Digital Assets specified in the Outputs of does not exceed the total amount pointed to by its Inputs; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 401 evaluates the result from the script engine 402 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 401 outputs an indication of whether the transaction is valid to the application level decision engine 404. j 4. Provided only that the transaction has been actually verified, the decision engine 404 may then cause one or both of the mining module 405M and the transfer module 405F to perform their respective blockchain-related functions as Tx j This means that the mining module 405M may choose to control the execution of Tx j 4 for each of the nodes, and / or the forwarding module 405F j to another node 104 in the P2P network 106. Note, however, that in an embodiment, the decision engine 404 does not choose to forward or mine an invalid transaction, but conversely, this does not necessarily mean that it must trigger mining or forwarding of a valid transaction simply because it is valid. Optionally, in an embodiment, the decision engine 404 may apply one or more additional conditions before triggering either or both functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only if the transaction is valid and if there are sufficient mining fees remaining.

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

[0068] <Prologue> Definition 1 - Rivest-Shamir-Adleman (RSA) public key cryptography Given two RSA primes p and q, an RSA modulus N=pq, and an Euler Quotient function Φ(N)=(p-1)(q-1), the encryption key e is such that e and Φ(N) are mutually prime, and the decryption key d is d=e -1 modΦ(N). The public key is (e,N) and the private key is d. p, q, and Φ1(N) are all secret, but they are not required to decrypt the ciphertext.

[0069] Definition 2 - Blum integer An integer N is a Blum integer if, for some primes p and q, N=pq is prime, and p=3mod4 and q=3mod4.

[0070] Definition 3 - William Integer An integer N is a William integer if, for some primes p and q, N=pq is prime, and p=3 mod 4 and q=7 mod 8.

[0071] Reasoning 1 William integers are Blum integers.

[0072] Definition 4 - Quadratic Remainder Let n be a positive integer and let:

number

number

[0073] The following formula:

number

[0074] Definition 5 – Legendre symbol Let p be a prime number, and let:

number

number

[0075] Reasoning 2

number

[0076] Definition 6- Jacobi symbol Factor n into:

number

number

number

number

number

[0077] Proposition 1 Let N=pq be William integers. Then, for any:

number

[0078] definition 7 N is a William integer, d∈QR N Here, QR N is the set of quadratic remainders modulo N,

number

number

[0079] Similarly:

number

[0080] definition 8

number

number

[0081] Proposition 2 Let N=pq be the RSA modulus. Let a be the quadratic remainder modulo N. Given the following:

number

[0082] Proof:

number

[0083] In what follows, we use two distinct cryptographic hash functions, H1 and H2, with the following ranges:

number

[0084] Definition 9 - Gamma Tree A Gamma-tree for a William integer N is a binary tree with each node defined as shown in Figure 5. A binary tree consists of a root layer or level 0, and one or more child layers or levels (1,2,…,t). The tree is a t-level tree, where each node has two child nodes (except the lowest level), and there is a root node at the top of the tree (as shown in Figure 5, or at the bottom if Figure 5 is reversed). Thus, there are 2 i-1 There are nodes.

[0085] For level 0, which constitutes the root node, Γ0 =<h1> QR For level i>0, Ω i =<H2(N||i)> 1. Next, for each parent node Γ parent For , one left child node Γ left and one right child node Γright, where

number

[0086] Divisible Tokens

[0003] An embodiment of the present disclosure provides a protocol for generating and transferring divisible tokens. Unlike traditional token systems where a single token can be redeemed for a single asset, a divisible token represents an initial amount of an asset and can be divided to represent different amounts of that asset. For example, the asset can be electronic cash or a tangible asset such as a vehicle, a building, jewelry, art, etc. The asset can be a consumable item, such as media content, a subscription, an energy or water supply, etc. A divisible token can be divided any number of times to represent smaller amounts of the initial amount. Here, we refer to dividing the token into smaller pieces. The token itself is not a physical token. The term pieces simply refers to divisions or smaller portions of the token, with smaller pieces of the first token representing smaller amounts of the asset.

[0087] FIG. 6 illustrates an exemplary system 600 for implementing an embodiment of the present disclosure. The exemplary system is comprised of three parties, a first party 103a, a second party 103b, and a third party 103c, each of which operates a respective computer device. Each party is a party of a blockchain network 106. Each of the first, second, and third parties can assume the role of Alice or Bob, as described above with reference to FIGS. 1-3. Although FIGS. 1-3 illustrate an example scenario in which Alice sends a transaction to Bob, thereby transferring an amount of digital assets to Bob, it will be understood that Bob can also transfer a transaction to Alice, thereby transferring an amount of digital assets to Alice.

[0088] Hereinafter, the first party is denoted as Alice 103a, the second party is denoted as Bob, and the third party is denoted as Charlie. Furthermore, where necessary, reference to the first party (e.g., Alice 103a) is understood to mean the computer device of the first party. Alice 103a and Bob 103b may communicate with each other using off-chain techniques, for example, via the side channel 301 shown in FIG. 3. Similarly, Alice 103a and Charlie 103c may communicate with each other using a side channel (which may or may not be of the same type as the side channel 301). Although not shown, Bob 103b and Charlie 103c may also communicate via a side channel.

[0089] Note that although three parties are illustrated in this example, in some instances one party may perform the actions of two parties: for example, Bob 103b and Charlie 103c may actually be the same party and, in some instances, may operate the same computing device.

[0090] As described in more detail below, Bob 103b may send a first transaction Tx1 to the blockchain network 106, Alice 103a may send a second transaction Tx2 to Charlie, and Charlie may send an updated second transaction Tx2' to the blockchain network. As described above, once a transaction is sent to the blockchain, if it is valid, it is included in the blockchain 150.

[0091] For example, Bob may be a bank and Alice may be a customer of Bob. Bob may issue a token to Alice for a sum of money, say £100. Alice may then use the token to pay for goods and services from a merchant, Charlie.

[0092] According to one aspect disclosed herein, Bob 103b issues a first token to Alice 103a using a first transaction Tx1. Bob 103b includes the first token in the output of the first transaction Tx1 and causes the first transaction to be transmitted to the blockchain network 106. This may involve Bob 103b transmitting the first transaction Tx1 himself to one or more nodes of the network 106, or transmitting the first transaction to another party that performs the step of submitting it to the network 106. Bob 103b may be a trusted party, such as, for example, a government, a bank, or other well-established entity. Alice 103a and Bob 103b each share their own public key P A and P B The first transaction contains an input signed with a signature based on Bob's public key. In other words, Bob provides his public key and a digital signature that unlocks the output of a previous transaction recorded on the blockchain. The first transaction contains an input signed with a signature based on Bob's public key. A , or a key P derived from it A1 The first transaction is sent from Bob 103b to Alice 103a.

[0093] Bob 103b may send a transaction Tx1 to a derived public key from Alice’s public key. For example, Alice 103a has a certification public key P A and Bob 103b may have an authentication public key P A Using the public key P A1 , so that both Alice 103a and Bob know the generated public key, but the link between Alice 103a and the public key is not apparent to other parties. Bob may obtain Alice's public key, for example, from Alice 103a, or it may be publicly available. Alice 103a and Bob may then negotiate a shared secret key, S, for example, using a Diffie-Hellman exchange. AB Alice 103a and Bob generate Alice's (certified) public key and the shared secret key S AB Bob 103b can generate a derived public key using P A1 Later, if Bob wants to send another token, e.g., a second instance of the same first token, or a token worth a different amount of assets, Bob 103b may send the token to the same public key P A1 , or the updated derived public key P A2 That is, Alice and Bob can generate a list of keys based on Alice's (certified) public key and a shared secret key, respectively. For example, a derived public key might be generated using the following formula:

number

[0094] The first token can be included in the same output as Alice's public key or in a different output. Preferably, the first token is included in an unspendable transaction output. A transaction can be made unconfirmed by including an opcode that terminates the execution of that output, i.e., when executed together with the unlock script of a later transaction. Certain blockchain protocols use an OP_RETURN opcode (or an OP_FALSE opcode followed by an OP_RETURN opcode) to achieve this function. Such an output is, for example, referred to below as an OP_RETURN output, although it is understood that other implementations or protocols can use other mechanisms to include payload data in the form of a token in a usable or unspendable output of a blockchain transaction.

[0095] Figure 7 shows an example of a first transaction Tx1. As shown, the first transaction (with transaction identifier TxID1) is composed of an input list and an output list. In this example, there is an input list with one input 701, and an output list with three outputs 702a, 702b, 702c. Input 701 contains an unlock script to unlock the lock script of a previous transaction referenced by the output labeled "Outpoint" in Figure 7. The unlock script contains Bob's public key P B and Bob's digital signature, Sig B The first output 702a of the first transaction includes a first token <data1>Here, "first output" is used as a label to distinguish between different outputs, rather than to refer to a particular order of the outputs. The second output 702b includes Alice's public key P A1 That is, the second output 702b includes a pay-to-public-key-hash (P2PKH) for Alice’s public key P A1 Optionally, the lock script may also be configured to include a pre-image that hashes to hash h1 in the unlock script that attempts to unlock the lock script. In the example, the pre-image is <data1>That is, the input of the subsequent transaction is to use the first token to unlock the second output. <data1>The second output 702b may transfer an amount x of the digital asset to Alice 103a. Note that the digital asset is not the same as the asset represented by the first token (although in some embodiments the latter asset may be another type of digital asset such as a security token). Optionally, a third output 702c is included in the first transaction Tx1. The third output 702c may transfer Bob's public key P B A third output 702c may transfer an amount y of the digital asset to Bob 103b.

[0096] As described above, the first transaction Tx1 includes in output 702a a first token. <data1>MAY be included in unspent outputs. First token <data1>includes multiple data fields. Each data field includes respective data. The first data field includes data representing a first amount of the asset, i.e., defining the first amount. For example, the data can represent a number, e.g., 100. The second data field is comprised of a ciphertext. The ciphertext represents an encrypted identifier of Alice 103a. The identifier may be, for example, Alice's public key (the same public key included in the P2PKH to Alice, or a different public key). The ciphertext may be encrypted with Alice's public key, but not the same public key as the identifier. In some examples, the identifier and the encryption key may be part of the same public key cryptosystem or may be part of different public key cryptosystems (e.g., RSA or both RSA and ECDSA). In some examples, the public key used to encrypt Alice's identifier includes a modulus N, and the first token includes a third data field including data representing the modulus N. The first token may include one or more additional data fields.

[0097] Optionally, Bob103b can obtain Alice's public key P A is certified by a trusted authority. For example, Bob 103b can determine whether Alice 103a provided a public key that is certified by Bob or some other authority, such as a bank, government, or certificate authority. Bob can then determine whether Alice's public key P A If Bob 103b determines that Alice 103a has not been authenticated, Bob may decide not to issue the first token to Alice 103a, i.e., Bob does not generate and send the first transaction Tx1 to Alice 103a.

[0098] Figure 8 shows the first token. <data1>The first token is a first amount (balance), the RSA modulus N(e,N) of Alice's public key, and her identifier P A The first token also contains a representation of the asset (in this case, GBP representing British Pounds). It also contains a data field for the number of payments. The first token issued by Bob103b <data1>In the example, the number of payments is zero. The number of payments represents the number of times the first token has been split into another token. When Alice 103a uses the first token, for example, to pay for a subscription, the number of payments is incremented by one. Further optional data fields may be included.

[0099] Once the first transaction Tx1 has been included in the blockchain 150, Alice 103a can generate a second transaction Tx2. Bob 103b can first notify Alice 103a that the first transaction has been included in the blockchain, or Alice can first create a second transaction Tx2 by using her public key P A1 Alice 103a may notice that Bob is sending outputs to her derived public key, and so she may not be able to send any output to that key, P A1 Monitor.

[0100] In order to spend the first token, or the amount of the asset represented by the first token, Alice must follow a predefined protocol between the token issuer (Bob) and the party with whom Alice is trying to spend the asset (which can be Bob or Charlie).

[0101] FIG. 9 shows an example of a second transaction Tx2 with a transaction identifier TxID2. Note that generation does not necessarily mean generation from scratch. For example, Alice 103a may be issued with a transaction template, e.g., from Bob, which may include one or more pre-filled fields. The second transaction Tx2 comprises an input 901 configured to unlock the output 702b of the first transaction Tx1. For example, the input 901 may include Alice's public key P A1 and a digital signature Sig to unlock the second output 702b of the first transaction. A may also include. If the second output 702b of the first transaction Tx1 is configured to perform a check on whether the input includes a preimage with h1, Alice103a may include that preimage (i.e., the first token <data1) in the input 901 of the second transaction Tx2.

[0102] The second transaction Tx2 includes one or more outputs 902. The first output 902a is a second token representing a second quantity of the asset <data2>Contains the second token <data2>may be included in a non-spendable transaction output of the second transaction, e.g., the OP_RETURN output. The second amount is the amount of the asset being transferred, used, redeemed, etc.

[0103] Second Token <data2>The second token may include data representing the second amount. For example, the second token may include one or more values ​​X, each of which represents a subamount (or division) of the first amount. For example, the second amount may be 75, and the value X may represent 75 together (e.g., 50 and 25). The value X is discussed in more detail below with reference to Figures 11 and 12. The second transaction Tx2 may include a second output 902b. The second output 902b may be a P2PKH to Alice's public key. The public key may be a P2PKH to Alice's public key. A1 or a new public key P A2 (e.g., a derived public key from PA1). Similar to the second output 702b of the first transaction Tx1, the second output 902b of the second transaction Tx2 may include a second token <data2>In other words, the lock script needs a pre-image of hash h2, which is the second token. <data2>It is.

[0104] Figure 10 shows the second token. <data2>Here is an example of the expression: <data1>One or more values ​​X are included in the payment field of the second token. <data2>One or more data fields of the second token may be the same as the first token. For example, the prefix representing the type of asset, Alice's encrypted identifier c, and the RSA modulus N may remain the same. One or more data fields of the second token may differ from the data fields of the first token. For example, Alice 103a may change a field representing the remaining amount of tokens to reflect that a second amount of the asset is being transferred. As another example, the number of payment fields also changes, increasing from 0 to 1. Alice 103a may also include additional information about the payment.

[0105] Once the second transaction Tx2 is generated, Alice 103a can send the transaction to the blockchain network 106. Additionally or alternatively, Alice 103a may send the transaction to Bob or Charlie 103c. Alice 103a may send the second transaction to Bob 103b if she is using the token with the token issuer (Bob 103b). Alice 103a can send the second transaction Tx2 to Charlie if she is using the token for an asset provided by another party, i.e. Charlie.

[0106] In some embodiments, the protocol requires that the first token (or rather the quantity represented by the first token) can be divided according to a binary tree-like structure. At the 0th layer (root layer) of the tree, a single root node Γ0 represents the total quantity of the first token. At the first layer (first child layer) of the tree, each child node Γ 00 , Γ 01 represents 50% of the total amount of the first token. That is, there are two child nodes, each of which represents the same amount of the total amount. At the second layer of the tree (the second child layer), each child node Γ 000 , Γ 001 , Γ 010 , Γ 011 represents half of the amount represented by the child nodes in the second tier (i.e., 25% of the total amount). In other words, there are four child nodes in the second child tier, representing the total amount. This process of successively halving the amount represented by a given node can continue any number of times. Note that the number of times is not necessarily limited to the smallest divisible number of the redeemable asset. For example, the smallest denomination of the British pound is one cent. However, the first token can be divisible into amounts less than one penny.

[0107] FIG. 11 illustrates how a first token can be split according to this protocol. As shown, a root node 1101 in the root tier represents 100 pounds, each child node 1102a, 1102b in the first child tier represents 50 pounds, and each child node 1103a-d in the second child tier represents 25 pounds. Child nodes 1103a-1103d in the second child tier can then be split, and these child nodes can be split, and so on. In other words, each child node represents (or maps to) a partial amount of the first amount. The first tier includes two child nodes 1102a, 1102b. In this tier, each child node 1102a, 1102b represents the same subamount ("first subamount") of the first amount. The second tier includes four child nodes 1103a-1103d. Each node in the second tier represents the same subamount ("second subamount") of the first subamount. The first amount, first subamount and second subamount are different amounts. With reference to FIG. 11, 100 pounds (first amount) is split into 2 lots of 50 pounds (first subamount) in the first child tier and 4 lots of 25 pounds (second subamount) in the second child tier. The subamounts represented by each pair of child nodes in a given tier give the subamount (or amount) represented by their parent node in the "higher" tier.

[0108] If the first token, and therefore the root node, represents the first quantity A, then the i-th layer of the tree structure has 2 i-1 nodes. Therefore, each node in the i-th layer has the quantity A*2 1-i Represents.

[0109] For example, say Alice wants to transfer £75 (second amount) to Charlie103c using the second token. Using the example tree structure in Figure 11, Alice must include two values ​​in the second token, totalling £75: the first value is £50 (first subamount) and the second value is £25.

[0110] Alice 103a could simply include the values ​​50 and 25 in the second token. However, this allows Alice to double-spend tokens: for example, Alice could send a second transaction, Tx2, to Charlie 103c containing a token (and value) representing £75, and then send another transaction to another party containing a token (and value) representing £75.

[0111] To prevent these problems, Alice, Bob 103b and Charlie 103c agree to follow a protocol in which each node in the tree is computed based on a certain component. Each child node is based on the root node. Each root node is based on Alice's public key P A The root node may be based on an identifier TxID1 of the first transaction Tx1. In this manner, the root node is linked to the first transaction. In some examples, the root node is calculated by applying a cryptographic hash function to the modulus N and, optionally, to the first transaction identifier TxID1.

[0112] A hierarchical tree structure may be constructed such that the nodes are calculated as shown in FIG. 12 using the following equations:

[0113] For level 0, which constitutes the root node, Γ0 =<h1> QR For level i>0, Ω i =<H2(TxID1||N||i)> 1. Next, for each parent node Γ parent For one left child node Γ left and one right child node Γright, where

number

[0114] Now, Alice 103a could use the node as the value placed in the token to represent a second quantity. However, this would allow a third party to calculate Alice's modulus N, given Alice's public key P A This would result in damage to the company.

[0115] To prevent such security breaches, preferably, for each node in the tree needed to represent the second quantity, Alice generates one of the square roots X of the node. The square root value X of the required node is included in the first token, and each square root value is used to represent a respective subquantity of the total quantity. For example, Alice may generate one of the square roots X of the node Γ 01 Square root of X 01 to represent 50 pounds, or A / 2. Alice then calculates node Γ to represent 25 pounds, or A / 4. 010 Square root of X 010 can be calculated.

[0116] In other words, the tree represents split tokens. When a node of the tree is spent, an X value is disclosed. The verifier can compute the corresponding Γ value for that node and for the nodes above it. Leaking any Γ value for the nodes below that node allows the public to factor N and thus reveal Alice's identity. Leaking the X value of a node above that node has the same effect.

[0117] Suppose Alice wants to pay Charlie £75, say to buy a chair. Alice calculates:

number

[0118] Note that the "0" in the calculation of Γ0 is not required. In the above example, "0" is simply used as an index and can therefore be represented by any data. When calculating Ω0, Alice can apply the index (in this case "0"). Depending on the token split, Alice can calculate Ω0. i In that case, Alice must use a different index (say, Ω 01 Apply "01" to

[0119] X 00 is set to Γ, such that 00 is one of the square roots of:

number

[0120] Note that any use of parent Γ must disclose the square root X, such that:

number

number

[0121] X 010 is set to Γ, such that 010 is one of the square roots of:

number

[0122] As mentioned before, Alice 103a does not have to compute the entire tree if she wants to, but she can if she wants. She can work her way up and compute the value of each node as she needs to. However, it is important that she publishes all the values, since leaking the child's Γ value along with the X values ​​would impair the factorization of N. For example, if X 00 and Γ 000 is Γ 00 would give two different square roots of

[0123] Alice 103a can add payment details to the second token. For example, Alice can provide an index that corresponds to the X value. For example, 00 is X 00 By having these indexes and balances, Charlie103c can determine the starting balance and the value represented by the value of X. To save some calculations, the value of the starting balance, X, and a subamount corresponding to the value of X can be added to the second token.

[0124] Once the second transaction, Tx2, has been created and contains the second token with the appropriate value, Alice sends the second transaction to Charlie. In other words, Alice sends Charlie (X 00 ,X 010 ,N). Alice sends the first token in the same transaction, e.g. the previous OP_RETURN payload. <data1>Note that Alice does not need to reveal the Γ-tree.

[0125] The input 901 of the second transaction Tx2 is linked to the second output 702b of the previous transaction. This is the field where Alice 103a can pass the first token (e.g., the OP_RETURN data payload of the first transaction Tx1) to Charlie 103c. The input 901 also contains a signature that can hold Alice 103a accountable if she double-spends or violates the protocol rules. To provide a level of privacy for Alice 103a, the public key P used to generate the signature is A1 may be a derived key. The public key appears random, but both Alice and Bob (e.g., the bank) can prove the association of the public key with Alice's identity in case of dispute.

[0126] Alice 103a may construct the first output of the second transaction Tx2 to allow Charlie 103c to add an input to the second transaction. For example, according to some blockchain protocols, Alice 103a may include an identifier or flag in the input that allows another input to be added to the transaction without invalidating the transaction. Alice 103a may use the sighhash flags SIGHASH_SINGLE (0x03) and SIGHASH_ANYONECANPAY (0x80) in her signature, where SIGHASH_ANYONECANPAY allows others to fund the transaction. For example, Charlie 103c can fund this transaction. SIGHASH_SINGLE protects Alice's input and Alice's output. These flags are included in Alice's signature Sig A1 Note that this does not protect the OP_RETURN output with . However, modifications to OP_RETURN will result in a different hash value than the hash value embedded in the first output. This hash value is protected by the signature. Furthermore, modifications to the inputs, including modifications to the first token (data1), will fail when checked with the previous lock script.

[0127] Currently, transaction TxID2 may not be valid for miners because there is no transaction fee. Alternatively, Alice could include enough fees to make miners happy. However, it contains all the information Charlie103c needs to verify Alice's payment, and Alice's signature and the hash function (e.g., any scripted hash function like SHA256 or double SHA256) provide the authenticity and integrity of all the information.

[0128] Charlie 103c obtains a second transaction, Tx2, from Alice 103a. The second transaction, Tx2, contains a second token, <data2>, which contains a value representing a second amount of the asset to be transferred to Charlie 103c, who can obtain the transaction directly from Alice 103a or through an intermediate source. The second token also contains the remaining balance of tokens, e.g., the balance that Charlie can spend himself.

[0129] Charlie103c receives the first token in the second transaction, Tx2. <data1>is the first token included in the first transaction Tx1. <data1>In the example where the first transaction Tx1 includes an output 702c that includes a hash of the first token h1, Charlie may determine whether the first token in the second transaction is equal to <data1>checks whether the first token matches that of the first transaction by applying a cryptographic hash function H1 to it (recall that the first token in a first transaction is a pre-image of the hash included in the output of the first transaction). If the first token does not match, Charlie103c knows that Alice103a has modified at least part of the first token and therefore has not followed the protocol. In that case, Charlie103c does not sign or submit the second transaction to the blockchain.

[0130] Charlie 103c also determines whether the value X, which represents the subquantity, is based on the identifier TxID1 of the first transaction Tx1, respectively. Charlie 103c can also determine whether the value X is based on the (RSA) modulus included in the token. For example, Charlie can determine whether the value X is based on Γ0=<h1> QR To check this, Charlie takes the transaction identifier and modulus from either the first transaction Tx1 or the second transaction Tx2 and applies a hash function to the data.

[0131] If Charlie103c is satisfied, Charlie makes the second transaction using his public key P C That is, Charlie103c updates the second transaction by signing it with his public key P C and the digital signature Sig PC Charlie then submits the updated second transaction Tx2′ to the blockchain network 106.

[0132] Charlie 103c can determine whether output 702b of the first transaction Tx1 paid to Alice 103a is among the unspent transaction outputs in the blockchain, in other words, whether the outpoint TxID1||0 is still in the UTXO set. If the outpoint is not in the UTXO set, Alice 103a attempts to redeem the first token with the same party (i.e., Charlie) or another party.

[0133] If Alice 103a, Bob 103b, and Charlie 103c follow the protocol where each token is represented by a tree structure of Figures 5 and 11, Charlie can determine the amount represented by the value X based on the tree structure. In some examples, Alice 103a can include an index in the first token that maps a given value to a specific location in the tree structure. Upon reviewing the first amount, the balance, and the second amount, Charlie determines whether the sum of the amounts in the portions represented by the values ​​in the tree structure equals the first amount minus the balance.

[0134] Charlie 103c may use the value X of the second token to compute one or more "candidate nodes". Each candidate node Γ' is computed by raising the respective value X to a power based on the value's tree index. For example, the value X with an index corresponding to a child node in the first child layer of the tree is raised to a power of 4, the value X with an index corresponding to a child node in the second child layer of the tree is raised to a power of 8, the value X with an index corresponding to a child node in the third child layer of the tree is raised to a power of 16, and so on. The power is doubled for each successive layer in the tree. This is because each value X is the square root of a child node in the tree. Therefore, values ​​must be squared (to a power of 2) to generate child nodes. Each child node is the square root of its parent node in the tree. Therefore, each child node must be squared to generate parent nodes. If a parent node is itself a child node, that node must be squared as well, and so on until the root layer is reached.

[0135] Candidate node Γ' is the left child node Γ left If , then the candidate node should map the root node by multiplying the candidate node by some value d. The value d represents the fact that each number has a positive and negative square root. The value d depends on the position of the candidate node in the tree, i.e., how many times the candidate node is squared to reach the root layer. For example, the left child node Γ in the first child layer left For the candidate node generated from , d1∈{±1,±2}. The candidate node is the left child node Γ left If ,then the candidate node should map the root node by multiplying the candidate node by some value d.

[0136] Candidate node Γ' is the right child node Γ right If ,then the candidate node should be mapped to the root node by multiplying it with some value d. The value d also depends on the position of the candidate node in the tree. If a child node is

number

[0137] Charlie 103c may perform one or more further checks to validate the second token. For example, Charlie can check that each value obeys the following relationship:

number

[0138] As described above, Charlie 103c verifies the second token and, if satisfied, sends an updated second transaction Tx2' to the blockchain. If Charlie 103c issued the first token, Charlie 103c can provide Alice 103a with goods, services, content, etc., worth the value of the second token. For example, if Charlie 103c is a content provider and the token represents an amount of content, Charlie can provide Alice 103a with content worth the amount of the second token. If Bob 103b issued the first token, Bob can provide Charlie with the amount of the second token. For example, Bob can be a bank and the token can represent electronic cash. Once the updated second transaction Tx2' appears on the blockchain, Bob can transfer the electronic cash worth the second amount to Charlie 103c.

[0139] The following illustrates an example of the steps taken by Alice 103a, Bob 103b, and Charlie in an exemplary scenario where they are customers of a bank and Charlie is a merchant expecting to receive payment from Alice 103a. It will be understood that some steps are not required.

[0140] Alice 103a presents a public key (e.g., an ECDSA public key) P that represents her identity. A Hold P A may be certified by a trusted authority such as a government or other established entity, and Bob also has a public key (e.g., an ECDSA public key) P B Have. P A does not have to be widely available (e.g., P A may relate to national ID number or passport number), P B may be publicly available (e.g., P B Note that the PIN code may relate to the certificate of an online banking website.

[0141] Suppose Alice 103a wants to get a token worth 100 pounds from Bob 103b.

[0142] Step 1: Alice 103a generates two RSA primes p and q, and calculates the public key (e, N) and private key d.

[0143] Step 2: Alice103a is P A and (e,N) to Bob. Bob 103b verifies Alice's identity and account, i.e., checks whether she is eligible to be issued a token of 100 pounds.

[0144] Step 3: Bob103b obtains Alice's identity, public key P A Encrypt with (e,N) to create ciphertext c.

[0145] Note that this cryptogram is published on-chain: if Alice103a were to double-spend her token, her RSA private key would be publicly derived, thus revealing her identity to the public and she could be penalized for double-spending.

[0146] Step 4: Alice103a and Bob103b first A and P B via Diffie-Hellman key exchange on AB Then, they derive a list of public keys:

number

[0147] Step 5: Bob 103b creates a first blockchain transaction to issue £100 tokens to Alice 103a, as shown in Figure 7. The output of the transaction is a colored output. It is Alice's public key P A1 To spend the output, Alice must first obtain the hash value h1 and P A1 The public must provide a pre-image of her ECDSA signature that can be verified by . In this particular example, the transaction includes an OP_RETURN output that colors the output. The data payload includes all the information the public needs to know to verify the payment from Alice, including the pre-image of h1. More precisely, the data payload may have the format shown in Figure 8.

[0148] It is understood that the hash puzzle in the lock script seems redundant since the previous image is available in OP_RETURN. However, this small additional data in the lock script allows anyone to verify Alice's payment without having the entire transaction. It is Alice's responsibility to hold and present the data payload. This is very useful when the miner that the merchant is connecting to is running on a pruned blockchain. All outputs are signed by Bob103b and sent with the trusted public key P B Note that this can be verified by using the output. Therefore, Alice 103a cannot tamper with the data in the output.

[0149] In the first transaction Tx1, Bob 103b A1 effectively signs a statement that the owner of knows the factorization of N. Since Bob is trusted, Charlie103c can get all of P from Alice. A1 The signature by

[0150] Step 6: Suppose Alice 103a wants to pay a merchant, Charlie, £75. Alice calculates:

number

[0151] The Γ-tree is shown together in FIG. 12, and the cash amounts represented by the nodes of the Γ-tree are shown in FIG.

[0152] As mentioned above, Alice 103a computes the necessary node values ​​of the tree and their square roots. Alice 103a does not need to compute the entire tree; she can work her way up and compute the value of each node as needed. It is important that she does not publish all the values ​​of the tree, since leaking the children's Γ values ​​along with the X values ​​would undermine the factorization of N. For example, 00 and Γ 000 is Γ 00 gives two different square roots of

[0153] Next, Alice103a sends the (X 00 ,X 010 ,N). Note that Alice 103a does not need to uncover the Γ-tree. The transaction is shown in FIG. 9, and the data2 payload can be represented by FIG.

[0154] To add payment details to the payload, Alice 103a needs to provide an index that corresponds to the X value. For example, 00 is X 00 By having these indexes and balances, we can calculate the starting balance and the value represented by the value of X. However, we can save some calculations by providing the values ​​explicitly: we add the starting balance and value corresponding to the X value to the payload.

[0155] The inputs for this transaction are the first output of the previous transaction, a field where Alice 103a can pass the previous OP_RETURN data payload to Charlie 103c, and a signature that allows Alice 103a to be held accountable if she double-spends or breaks the rules. The public key appears random; however, both Alice 103a and Bob 103b (the bank) can prove the association of the public key with Alice's identity in case of a dispute.

[0156] Alice103a uses SIGHASH_SINGLE (0x03) and SIGHASH_ANYONECANPAY (0x80) in her signature. SIGHASH_ANYONECANPAY allows others to fund the transaction. In this example, the merchant, Charlie, funds the transaction. SIGHASH_SINGLE protects Alice's inputs and the first output. Note that the OP_RETURN output is not protected by the signature. However, modifying OP_RETURN will result in a different hash value than the hash value embedded in the first output, which is protected by the signature. Also, any changes to the inputs, including changes to data1, will fail when checked with the previous lock script.

[0157] Currently, transaction TxID2 may not be valid for miners because there is no transaction fee, but Charlie103c contains all the information necessary to verify Alice103a's payment, and Alice's signature and hash function provide the authenticity and integrity of all the information.

[0158] Note that Alice 103a has full control and can use the colored out point in other ways, but if the protocol is not followed, any token value represented by this out point will be lost.

[0159] Step 7: H0 denotes the hash function double-SHA256, OP_HASH256.

[0160] Charlie calculates and checks the following:

number

[0161] If all checks pass, Charlie103c accepts the payment and updates the transaction by adding the input and output. Charlie can do this without invalidating Alice's signature because the transaction from Alice is signed using SIGHASH_ANYONECANPAY and SIGHASH_SINGLE. The updated transaction is shown in Figure 13.

[0162] The third output is simply the change to Charlie103c. The difference between his input and his change is the transaction fee paid to the miner. In addition, Charlie's input serves the following purposes: 1.Alice's proof of payment, 2. Notify payee Bob; 3. If Charlie conspires with Alice, he will be held legally liable.

[0163] Final payment: Bob103b uses public key P Ai or can be informed by Charlie 103c that a payment is coming from Alice 103a. Since TxID2' is recorded in the blockchain, Charlie has no urgency to contact Bob 103b. Alice 103a cannot double the payment to Charlie because the corresponding outpoint was used. The payment can be performed by Bob 103b in fiat currency by transferring the balance from Alice's account to Charlie's account.

[0164] Alternatively, to take advantage of trust from the blockchain, Charlie103c could color his output with TxID2' in step 8 and use his £75 as a divisible token. The next recipient, say Dave the lumberjack, would have to verify all the information back to TxID1.

[0165] The mechanism of splitting a token into 2T pieces for some non-negative integer t is generally applicable to any token system. As long as the token issuer recognizes the William integer N, the token holder has the flexibility to split the token however they wish. Putting all the information needed to exchange a token on the blockchain creates a secure way to exchange small portions of a token.

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

[0167] (Statement 1) A computer-implemented method of generating a second transaction for a blockchain, the method comprising: a first transaction, the first transaction including a first token and a first output transferring an amount of a digital asset between a second party and the first party, the first token representing a first amount of a token asset other than the digital asset; and a second transaction, the second transaction for transferring a second token representing a second amount of the token asset from the first party to a third party; and generating the second transaction, the second transaction including: i) a first input configured to unlock the first output of the first transaction; and ii) a first output including the second token, the second token including data representing the second amount of the token asset, the second amount being less than the first amount.

[0168] (Statement 2) The method described in Statement 1, wherein the data representing the second amount of the token asset includes one or more values, each value used to represent a respective sub-amount of the first amount of the token asset.

[0169] The method may include transmitting the second transaction to the second party and / or to the blockchain for inclusion in the blockchain.

[0170] (Statement 3) The method described in Statement 2, wherein each value is generated based on an identifier of the first transaction.

[0171] (Statement 4) The method of Statement 2 or Statement 3, wherein each value is generated based on a modulus of the first party's public key, and the output of the second transaction includes the modulus.

[0172] (Statement 5) The method of Statement 3 or 4, wherein each value is based on a root node of a binary tree structure, the root node being generated based on the identifier of the first transaction and / or the predetermined modulus, the tree structure including a root tier including a root node and a sequence of one or more child tiers, each child tier including one or more child node pairs, each pair being a child of a respective node in a previous tier in the structure, each node representing a respective amount of the token asset, the root node representing the first amount and each child node pair together representing an amount equal to the amount represented by the respective node in the previous tier.

[0173] (Statement 6) The method of Statement 5, wherein each of the one or more values ​​is a square root of a respective one of the one or more generated nodes.

[0174] The method may include generating each node of the tree structure. Alternatively, the method may include generating only a subset of the nodes, for example those nodes required to represent the second amount of the token asset.

[0175] (Statement 7) The method of Statement 5 or Statement 6, wherein the root node is generated by applying a first cryptographic hash function to at least the identifier of the first transaction.

[0176] (Statement 8) The method of Statement 7, wherein the root node is generated by applying the first cryptographic hash function to at least the identifier and the modulus of the first transaction.

[0177] (Statement 9) The method of Statement 8, wherein the first token includes the modulus.

[0178] (Statement 10) The first token represents the first amount A, and the i-th layer of the tree structure is 2 i-1 Each node in the i-th layer has a quantity A*2 1-i The method according to any one of Statements 5 to 9,

[0179] (Statement 11) A method according to any of Statements 5 to 10, wherein each child node pair includes a first child node and a second child node, each first child node in the i-th tier includes a square root of a respective node in the previous layer, and each second child node in the i-th tier includes a square root of a respective node in the previous layer and a component generated by applying a second cryptographic hash function to at least an identifier of the first transaction.

[0180] The second cryptographic hash function may be applied to at least the identifier and the modulus of the first transaction.

[0181] (Statement 12) The method of Statement 11 that depends on Statement 7, wherein the first and second cryptographic hash functions are different cryptographic hash functions.

[0182] (Statement 13) The method of any one of Statements 1 to 12, wherein each of the sub-amounts is a different sub-amount of the first amount, each representing a different amount of the token asset.

[0183] (Statement 14) The method according to any one of Statements 1 to 13, wherein the first output of the second transaction is an unusable transaction output.

[0184] (Statement 15) The method described in any of Statements 1 to 14, wherein the first output of the first transaction includes a hash of the first token, and the first input of the second transaction includes the first token.

[0185] (Statement 16) A method according to any of Statements 1 to 15, wherein the first input of the second transaction includes a first public key of the first party and a digital signature generated based on a first private key corresponding to the first public key.

[0186] (Statement 17) The first transaction is generated by the second party, and the method further comprises: generating a private key corresponding to the second public key of the first party and a shared secret key based on the public key of the second party; generating a first public key of a first party based on the shared secret key and the second public key of a first party; The method described in Statement 16, including: (Statement 18) The method described in Statement 17, wherein the second party and the third party are the same party.

[0187] (Statement 19) A step of generating a third public key of the first party, the third public key including a modulus; sending the third public key of the first party to the second party; The method according to any one of Statements 1 to 18 which is dependent on Statement 4 including:

[0188] (Statement 20) The method of any one of Statements 1 to 19, wherein the first input of the second transaction is configured to enable the third party to add a second input to the second transaction.

[0189] (Statement 21) A computer-implemented method of generating a second transaction for a blockchain, the blockchain including a first transaction, the first transaction including a first token and a first output transferring an amount of a digital asset from a second party to a first party, the first token representing a first amount of a token asset other than the digital asset, and a second transaction for transferring a second token representing a second amount of the token asset from the first party to a third party, the method being performed by the third party; obtaining the second transaction, the second transaction including: i) a first input including the first token; and ii) a first output including the second token, the second token including one or more values, each value being used to represent a respective sub-amount of the token asset; determining whether the second transaction is valid based on a) whether each value was generated based on at least an identifier of the first transaction, and b) whether the first token in the second transaction is identical to the first token in the first transaction; updating the second transaction based on the determination by signing the second transaction with the public key of the third party; sending the updated second transaction to the blockchain network for inclusion in the blockchain; The method includes:

[0190] (Statement 22) The method of Statement 21, wherein the first token includes a modulus of the first party's public key, and the determining step includes the step of c) determining whether each value is generated based on at least the identifier of the first transaction and the modulus.

[0191] (Statement 23) The method of Statement 21 or 22, wherein the determining step includes a step of d) determining whether each value is based on a root node of a binary tree structure, the root node being generated based on the identifier of the first transaction and / or the predetermined modulus, the tree structure including a root tier including a root node and a sequence of one or more child tiers, each child tier including one or more child node pairs, each pair being a child of a respective node of a previous tier in the structure, each node representing a respective amount of the token asset, the root node representing the first amount, and each child node pair together representing an amount equal to the amount represented by the respective node of the previous tier.

[0192] (Statement 24) The method of Statement 23, comprising determining the second amount of the second token based on respective amounts represented by respective nodes corresponding to the one or more values.

[0193] (Statement 25) The first transaction includes a hash of the first token, and a) the step of determining whether the first token in the second transaction is identical to the first token in the first transaction includes the step of determining that the hash of the first token in the second transaction is identical to the hash of the first token in the first transaction.

[0194] (Statement 26) The method according to any of Statements 21 to 25, wherein the determining step includes the step of: d) determining whether an output of the first transaction referenced by the first input of the second transaction is an unspent transaction output.

[0195] (Statement 27) A method according to any of Statements 21 to 26, wherein the second transaction includes a hash of the second token, and the determining step includes the step of e) determining whether the hash of the second token is equal to the hash of the second token in the second transaction.

[0196] (Statement 28) A method according to any one of Statements 21 to 27, wherein the obtaining step includes a step of receiving the second transaction from the first party.

[0197] (Statement 29) generating the first transaction, the first transaction including: i) a first output that, when executed together with an input of the second transaction, is configured to require that the input of the second transaction include a first public key of the first party to be unlocked; submitting the first transaction to the blockchain network for inclusion in the blockchain; 29. The method according to any one of Statements 21 to 28,

[0198] (Statement 30) A computer-implemented method of generating a first transaction for a blockchain, the first transaction including a first output transferring an amount of a digital asset from a second party to a first party, the first transaction being to transfer a first token from the second party to the first party, the first token representing a first amount of a token asset other than the digital asset, the method being performed by the second party; generating the first transaction, the first transaction including: i) a first output configured, when executed together with a second transaction input, to require the second transaction input to include a first public key of the first party in order to be unlocked; and ii) a second output including the first token, the first token including: a) a first amount of the token asset; and b) an encrypted identifier of the first party, the encrypted identifier generated by encrypting the first party identifier with a second public key of the first party, the second public key including a modulus, and the first token including c) a modulus.

[0199] (Statement 31) The method described in Statement 30, wherein the identifier of the first party is a third public key of the first party.

[0200] (Statement 32) generating a shared secret key based on a private key of the second party and the second public key of the first party; generating the first public key of the first party based on the shared secret key and the second public key of the first party; 32. The method according to claim 30 or 31,

[0201] (Statement 33) The method according to Statement 31 or 32, comprising a step of obtaining the second public key and / or the third public key of the first party from the first party.

[0202] (Statement 34) The method of any of Statements 30 to 33, wherein the first transaction includes iii) a third output that, when executed together with an input of the fourth transaction, is configured to require that the input of the fourth transaction include the first public key of the second party to be unlocked.

[0203] (Statement 35) A method as described in any of Statements 30 to 34, wherein the first output of the first transaction includes a hash puzzle that, when executed together with the input of the second transaction, is configured to require that the input of the second transaction include the first token.

[0204] (Statement 36) A method according to any of Statements 30 to 35, comprising a step of sending the first transaction to the blockchain network for inclusion in the blockchain.

[0205] (Statement 37) Obtaining the second public key of the first party; determining that the second public key is certified by a trusted party; Including, The method according to any one of Statements 30 to 36, wherein the transmitting step includes a step of transmitting the first transaction only if the second public key is authenticated.

[0206] (Statement 38) A first-party computer device, a memory including one or more memory units; a processing device including one or more processing units; Including, The memory stores code configured to execute on the processing device, the code configured to execute a method according to any one of Statements 1 to 20.

[0207] (Statement 39) A computer program embodied on a computer readable storage device and configured to perform the method of any of Statements 1 to 20 when executed on a first party computing device.

[0208] (Statement 40) A third party computer device, a memory including one or more memory units; a processing device including one or more processing units; Including, The memory stores code configured to execute on the processing device, the code configured to execute a method according to any one of Statements 21 to 29.

[0209] (Statement 41) A computer program embodied on a computer readable storage device and configured to perform the method of any of Statements 21 to 29 when executed on a third party computing device.

[0210] (Statement 42) A second party computer device, a memory including one or more memory units; a processing device including one or more processing units; Including, The memory stores code configured to execute on the processing device, the code configured to execute a method according to any one of Statements 30 to 37.

[0211] (Statement 43) A computer program embodied on a computer readable storage device and configured to perform the method of any of Statements 30-37 when executed on a second party computing device.

[0212] (Statement 44) A first transaction for inclusion in a blockchain, the first transaction to transfer a first token from a second party to a first party, the first token representing a first amount of a token asset, the first transaction including: i) a first output configured, when executed together with an input of a second transaction, to require that the input of the second transaction include a first public key of the first party to be unlocked; and ii) a second output including the first token, the first token including: a) the first amount of the token asset; and b) a cryptographic identifier of the first party, the cryptographic identifier generated by encrypting an identifier of the first party with a second public key of the first party, the second public key including a modulus; and the first token including c) the modulus.

[0213] (Statement 45) A computer-readable storage medium having stored thereon the first transaction recited in Statement 44.

[0214] (Statement 46) A second transaction for inclusion on a blockchain, the second transaction for transferring a second token representing a second amount of a token asset from a first party to a third party, the second transaction including: i) a first input configured to unlock a first output of a first transaction transferring an amount of a digital asset from the second party to the first party, the digital asset being different from the token asset; and ii) a first output including the second token, the second token including data representing the second amount of the token asset, the second amount being less than the first amount.

[0215] (Statement 47) A computer-readable storage medium having stored thereon the first transaction described in Statement 46.

[0216] According to another aspect of the technology disclosed herein, a method may be provided that includes actions of some or all of the first, second, and third parties.

[0217] According to another aspect of the technology disclosed herein, there may be provided a system including some or all of the computing devices of the first, second and third parties.

[0218] According to another aspect of the technology disclosed herein, a set of transactions may be provided that includes the first and second transactions.

[0219] Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon review of this disclosure. The scope of the present disclosure is not limited by the described embodiments, but only by the accompanying Statement. < / sigpa>

Claims

1. 1. A computer-implemented method for generating a second transaction on a blockchain, the blockchain including a first transaction, the first transaction including a first token and a first output transferring an amount of a digital asset between a second party and a first party, the first token representing a first amount of a token asset other than the digital asset, and a second transaction for transferring a second token representing a second amount of the token asset from the first party to a third party, the method being performed by the first party; generating the second transaction, the second transaction including: i) a first input configured to unlock the first output of the first transaction; and ii) a first output including the second token, the second token including data representing the second amount of the token asset, the second amount being less than the first amount; sending the second transaction to one, some, or all of the first party, a third party, and / or a blockchain network; The method includes:

2. 2. The method of claim 1, wherein the data representing the second amount of the token asset includes one or more values, each value being used to represent a respective subamount of the first amount of the token asset.

3. The method of claim 2 , wherein each value is generated based on an identifier of the first transaction.

4. The method of claim 2 or claim 3, wherein each value is generated based on a modulus of the first party's public key, and an output of the second transaction includes the modulus.

5. 5. The method of claim 3 or 4, wherein each value is based on a root node of a binary tree structure, the root node being generated based on an identifier of the first transaction and / or a predetermined modulus, the binary tree structure including a root tier including a root node and a sequence of one or more child tiers, each child tier including one or more child node pairs, each pair being a child of a respective node of a previous tier in the binary tree structure, each node representing a respective amount of the token asset, the root node representing the first amount, and each child node pair together representing an amount equal to the amount represented by a respective node of the previous tier.

6. The method of claim 5 , wherein each of the one or more values ​​is a square root of a respective one of the one or more generated nodes.

7. The method of claim 5 or claim 6, wherein the root node is generated by applying a first cryptographic hash function to at least the identifier of the first transaction.

8. 8. The method of claim 7, wherein the root node is generated by applying the first cryptographic hash function to at least the identifier and the modulus of the first transaction.

9. The method of claim 8 , wherein the first token comprises the modulus.

10. The first token represents the first amount A, and the i-th layer of the binary tree structure is i-１ Each node in the i-th layer has a quantity A*2 １-i The method according to any one of claims 5 to 9, wherein

11. 11. A method according to any one of claims 5 to 10, wherein each child node pair includes a first child node and a second child node, each first child node in the i-th tier includes a square root of a respective node in a previous layer, and each second child node in the i-th tier includes a square root of a respective node in a previous layer and a component generated by applying a second cryptographic hash function to at least the identifier of the first transaction.

12. 12. The method of claim 11 when dependent on claim 7, wherein the first and second cryptographic hash functions are different cryptographic hash functions.

13. The method of any one of claims 2 to 12, wherein each said sub-amount is a different sub-amount of the first amount, each representing a different amount of the token asset.

14. The method of any preceding claim, wherein the first output of the second transaction is an unusable transaction output.

15. The method of any preceding claim, wherein the first output of the first transaction comprises a hash of the first token, and the first input of the second transaction comprises the first token.

16. 16. The method of claim 1, wherein the first input of the second transaction includes a first public key of the first party and a digital signature generated based on a first private key corresponding to the first public key.

17. The first transaction is generated by the second party, and the method further comprises: generating a private key corresponding to the second public key of the first party and a shared secret key based on the public key of the second party; generating a first public key of a first party based on the shared secret key and the second public key of a first party; 17. The method of claim 16, comprising:

18. The method of claim 17 , wherein the second party and the third party are the same party.

19. generating a third public key for the first party, the third public key including a modulus; sending the third public key of the first party to the second party; The method according to claim 4, any one of claims 5 to 18 depending on claim 4, comprising:

20. 20. A method according to any preceding claim, wherein the first input of the second transaction is configured to enable the third party to add a second input to the second transaction.

21. a first party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to run on the processing device, the code being configured to perform a method according to any of claims 1 to 20 when executed on the processing device.

22. A computer program embodied on a computer readable storage device and arranged to carry out the method of any of claims 1 to 20 when executed on a first party computing device.

Images