Divisible token

Abstract

A computer-implemented method of generating a secondary transaction for a blockchain.SOLUTION: The blockchain includes a first transaction including a first token and a first output transferring a quantity of digital assets between a second party and a first party. The first token represents a first quantity of token assets other than digital assets, and the second transaction is for transferring a second token representing a second quantity of token assets from the first party to a third party. The method is performed by a 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 a second token. The second token includes data representing a second quantity of token assets, wherein the second quantity is less than the first quantity.SELECTED DRAWING: Figure 6

Description

[Technical Field]

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

[0002] A blockchain is 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, each containing one or more transactions. Each transaction may point to a previous transaction in a sequence that may span one or more blocks. Transactions are submitted to the network so they can be included in new blocks through a process known as "mining." "Mining" involves multiple mining nodes each 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 them. For example, blockchain protocols may allow for 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 for the incorporation of more complex data. 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 in the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes in the network for propagation. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to participate in the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or 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, vol. 576. Springer, Berlin, Heidelberg), has previously been proposed. In this system, a trusted bank can issue electronic cash to its customers. Once issued, the customers have the flexibility to divide the cash into smaller portions. To use the portion, the recipient had to rely on the bank to verify the transaction. After verification, the bank can settle the transaction with legal tender (fiat). Summary of the Invention

[0006] Although Okamoto and Ohta generally solved the problem of double spending, 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, such as company stock, artwork, or real estate. The divisible tokens can also be redeemed for services. For example, a token may represent a total amount (e.g., minutes) of media content available for streaming from a content provider.

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

[0009] According to one aspect disclosed herein, there is provided a method for 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 is executed by the first party and includes 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.

[0010] The first token is immutably stored on the blockchain within the first transaction and serves as a record of the amount of the token asset issued to the first party. For example, the token may be a currency amount (e.g., 100 GBP) (in this example, the currency unit of Great Britain and Northern Ireland). 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; that is, it represents a second, smaller amount (e.g., 50 GBP or 75 GBP) 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, which is less than the first amount. For example, the data may include one or more values, each representing a subamount of the first amount that is added to the second, smaller amount. For example, if the first party wants to transfer 75 pounds to a third party, the second token may include two values ​​representing 50 pounds and 25 pounds, respectively. In this example, the third party still has 25 pounds worth of her original token to use 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 a digital asset that is inherently transferred as part of the blockchain protocol of a 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 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 (i.e., a second or further 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 and includes: 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 described 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 represent 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, or 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, it serves as an immutable record of the transfer of a particular fraction of the divisible token from the first party to the second party. Because the second transaction is signed by the third party (Charlie), Charlie attests to the amount of tokens he redeemed. The second token is a fraction 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, for example something worth a second amount of the second tokens, in exchange for 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 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 being 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. 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 service, content, etc. to the first token. 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 explanation of the drawings]

[0018] To facilitate an understanding of embodiments of the present disclosure, and to show how such embodiments may be put into effect, reference will now be 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. [Figure 2] 1 shows a schematic diagram of some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] Node protocol for the output-based model; a schematic block diagram of the piece of node software that processes transactions. [Figure 5] 1 illustrates a schematic diagram of a binary tree structure. [Figure 6] 1 illustrates a schematic diagram of a system for transferring divisible tokens between parties. [Figure 7] 1 shows an example representation of a first blockchain transaction. [Figure 8] 10 illustrates an exemplary representation of a first token. [Figure 9] 10 shows an example representation of a second blockchain transaction. [Figure 10] 10 illustrates an exemplary representation of a second token. [Figure 11]1 illustrates a schematic representation of a mapping between token quantities and nodes of a binary tree structure. [Figure 12] Schematic representation of a binary tree structure along with the formula for computing the nodes of the tree [Figure 13] 10 shows an example representation of an updated version of a second blockchain transaction. DETAILED DESCRIPTION OF THE INVENTION

[0019] <Example 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 multiple 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 unit 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 memory, i.e., computer-readable storage 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., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0020] The blockchain 150 includes a chain of blocks of data 151, with each 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 for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing 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 take on the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 take on the role of miners 104M, which mine blocks 151. At least some of the nodes 104 take on the role of storage nodes 104S (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 (or each of) inputs includes a pointer referencing 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 was 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" herein refers to something that precedes in the 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 preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or 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 152j may have multiple outputs to divide the input amount among multiple users (one of which may be the original user 103a to provide 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 into one or more outputs of the current transaction.

[0024] These are sometimes called "output-based" transaction protocols, and sometimes called "unspent transaction output (UTXO) type protocols" (where the outputs are called UTXOs). A user's total balance is not defined by a single number stored on the blockchain; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of the user's UTXOs, which are spread 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 an account-based system, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past 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 an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a 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 or she sends the new transaction from his or her computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could also 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 by the blockchain 150 in question and together form the 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 involve checking that a user's cryptographic signature included in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i used by the new transaction. This condition 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 new transaction's input points. In some transaction protocols, the condition may be defined, at least in part, by custom script included in the input and / or output. Alternatively, the condition may be fixed solely in the node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also function as forwarding nodes 104F, applying the same tests according to the same node protocol and forwarding the new transaction 152j to one or more additional nodes 104.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 in another onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to spend or redeem has not yet been spent / redeemable 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 the same transaction output multiple times. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, because there is a defined order of transactions, the account balance has a single, defined state at a time.

[0028] In addition to validation, 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." Mining nodes 104M add new transactions 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 hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. A property of hash functions is that they have unpredictable outputs with respect to their inputs. Therefore, this search can only be performed by brute force and therefore uses a significant amount of processing resources at each node 104M attempting 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 (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The winner's pool of transactions 154 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 their own checks of the winner's solution. The new block 151n is also assigned a block pointer 155 that points to the previously created block 151n-1 in the chain. Proof-of-work helps reduce the risk of double spending because creating a new block 151 requires significant effort, and blocks containing double spends are likely to be rejected by other nodes 104, thus incentivizing mining nodes 104M to avoid including double spends 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 the blocks 151. Because transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this provides an immutable public ledger of transactions.

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

[0031] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of thin air (a regular transaction transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "generation" transaction; it automatically forms part of a new block 151n. This reward motivates miners 104M to participate in proof-of-work competitions. Regular (non-generation) transactions 152 often specify an additional transaction fee for one of their outputs, further rewarding the winning miner 104M who produces the block 151n containing 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 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 node's 104 processing unit to perform one or more respective roles and 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 respective computing device's processing unit. 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 a plurality of parties 103 acting as consumer users. These parties 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 illustrative purposes: a first party 103a and its respective computing device 102a, and a second party 103b and its respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 may 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; however, this is not intended to be limiting, and it will be understood that references herein to Alice or Bob can be interchangeably referred to as the "first party" and the "second party," respectively.

[0035] Each party's 103 computing device 102 includes a respective processing device that includes one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's 103 computing device 102 further includes memory, i.e., computer-readable storage 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 memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on each party's 103 computing device 102 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 actions attributed to a party 103 herein may be performed using software executing on the processing device of each party's 102 computing device. Each party's 103 computing device 102 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may 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, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk, e.g., CD or DVD ROM, or 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 the amounts defined among the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0038] An instance of a 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 enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. 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 may handle different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[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 pointing back to a previously created block 151 in the chain, defining a sequential order for 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 for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 extends 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 rather than to a previous transaction.

[0040] When a given party 103, e.g., Alice, wishes to submit 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. She then sends the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F closest to 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 for being "valid," examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[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 by 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 propagate throughout the P2P network 106.

[0042] Once in pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, miner nodes 104M begin racing to solve the proof-of-work puzzle of the latest version of pool 154 that contains new transaction 152j. (Other miners 104M are still trying to solve the puzzle based on their old view of pool 154, but whoever gets there first defines where the next new block 151 ends and the new pool 154 begins; eventually, someone solves the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once proof-of-work has been done for pool 154 that contains new transaction 152j, it becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152j consists of a pointer to the previous transaction, the order of 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 will be described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting 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 contain 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). A UTXO specifies a quantity 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 indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. 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, suppose Alice 103a wants to create transaction 152j to transfer the amount of the digital asset in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1." It takes the amount of the digital asset locked to Alice and puts it into the output 203 of the preceding transaction 152i in the sequence, transferring at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely 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 submits 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 immediately in the new block 151. Alternatively, Tx0 and Tx1 may be generated and submitted to the network 102, or Tx0 may be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions within a sequence defined by transaction pointers specified within the transaction (e.g., which transactions point to which other transactions). They may equally be replaced by “preceding” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, submitted to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an 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 specifying the quantity of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the quantity 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 subsequent transaction includes the 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 a "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. The 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 for UTXO0 to be redeemed (or, more precisely, for any 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 within Tx0, in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 also contains an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign 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 whether the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating 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, given Alice's public key and the message in question (the unencrypted message), another entity, such as node 104, can authenticate that an encrypted version of the message must have been signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging this as the signature on a plaintext version of the message, allowing the owner of the public key to authenticate 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 awaiting proof-of-work. If it is a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106, thereby propagating it throughout the network. Once Tx1 is validated and included in the blockchain 150, it defines it as having spent UTXO 0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to spend an output already 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 (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what 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 among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split among 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 typically also needs to include a fee for the winning miner, because today, the reward for the generated transaction alone is typically not enough to incentivize mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, while 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 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 input 202 and the total amount specified in output 203 of a given transaction 152 is automatically awarded to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, nothing necessarily precludes that a miner's fee may alternatively or additionally be explicitly specified in a unique one of transaction 152's UTXOs 203.

[0056] Note that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, 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, a given party's 103's assets are typically dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to aggregate the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on any of the storage nodes 104S, for example, the storage node 104S that is closest to 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, [Checksig P 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 script opcode that takes 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 in transactions that are verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating an unspendable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata can include a document that is desired to be stored 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. The SIGHASH flag is a 4-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0060] A lock script is sometimes referred to as a "scriptPubKey," indicating that each transaction contains the public key of the party being locked. An unlock script is sometimes referred to as a "scriptSig," indicating that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions for redeeming a UTXO include authenticating a signature. More generally, a scripting language may be used to define any one or more conditions. Therefore, 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 that described in connection with FIG. 1, except that additional communication functionality is included. Client applications residing on each of Alice's and Bob's computing devices 102a, 102b each include the additional communication functionality. 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 separately from the P2P network. Such communication is sometimes referred to as "off-chain." For example, it may be used to exchange a transaction 152 between Alice and Bob without it being published on the P2P network 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 via 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 should be noted that when Alice and Bob are said to exchange particular pieces of information or data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over the exact same link or the same type of network.

[0063] <Node software> FIG. 4 illustrates example node software 400 that may run on 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 function 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(s)). 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 ), the protocol engine identifies the unlock script and passes it to the script engine 402. The protocol engine 401 further 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 either use it from its own pool of pending transactions 154, or Tx m-1 already in the blockchain 150, then Tx 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 engine 402 .

[0064] The script engine 402 therefore m-1 Lock script, and Tx m 4. For example, although Tx1 and Tx2 are shown in FIG. 4, it can be applied to any pair of transactions, such as Tx0 and Tx1. The script engine 402 executes the two scripts together as described above, which includes placing data on the stack 403 and retrieving data according to the stack-based scripting language (e.g., Script) 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 that the lock script is included in. 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, a "true" result from the script engine 402 is one of the conditions for the validity of the transaction. Typically, there are one or more additional 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 output of Tx does not exceed the total amount pointed to by its input; 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. Tx j is actually verified, the decision engine 404 may then activate 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 and / or the forwarding module 405F adds the Tx j to another node 104 in the P2P network 106. Note, however, that in embodiments, 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 the mining or forwarding of a valid transaction simply because it is valid. Optionally, in embodiments, 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 sufficient mining fees remain.

[0067] Note 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 verification of the signature by 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 relatively 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 Φ(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 N=pq for some prime numbers p and q, and p=3 mod 4 and q=3 mod 4.

[0070] Definition 3 - William Integer An integer N is a William integer if N=pq for some prime numbers p and q, 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, and any:

number

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

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 residue modulo N. Given:

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 - Γ-tree A Γ-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 tree of t levels, where each node has two child nodes (except the lowest level), with the root node at the top of the tree (as shown in Figure 5, or at the bottom if Figure 5 is reversed). Thus, at the ith level 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 = 1. Next, for each parent node Γ parent For , one left child node Γ left and one right child node Γright, where

number

[0086] Divisible Tokens Embodiments of the present disclosure provide 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 may be electronic cash or a tangible asset such as a vehicle, a building, jewelry, art, etc. The asset may 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, reference is made to dividing a token into smaller portions; the token itself is not a physical token. The term piece simply refers to divisions or sub-portions of a token, with smaller pieces of the first token representing smaller amounts of the asset.

[0087] FIG. 6 illustrates an exemplary system 600 for implementing embodiments of the present disclosure. This exemplary system includes three parties: a first party 103a, a second party 103b, and a third party 103c, each of which operates a respective computing device. Each party is a party in 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 through 3. While FIGS. 1 through 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 will be referred to as Alice 103a, the second party as Bob, and the third party as Charlie. Furthermore, where appropriate, reference to a first party (e.g., Alice 103a) will be understood to mean the first party's computer equipment. Alice 103a and Bob 103b may communicate with each other using off-chain techniques, for example, via 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 side channel 301). Although not shown, Bob 103b and Charlie 103c may also communicate via a side channel.

[0089] While three parties are illustrated in this example, it should be noted that 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 computer equipment.

[0090] As described in more detail below, Bob 103b may submit a first transaction Tx1 to the blockchain network 106, Alice 103a may submit a second transaction Tx2 to Charlie, and Charlie may submit an updated second transaction Tx2' to the blockchain network. As described above, once a transaction is submitted 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 Bob's customer. Bob may issue a token to Alice for a sum of, say, 100 pounds. Alice may then use the token to pay for goods or 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 to one or more nodes of the network 106 himself, or transmitting the first transaction to another party that performs the step of submitting it to the network 106. Bob 103b may be, for example, a trusted party such as a government, a bank, or other well-established entity. Alice 103a and Bob 103b each share a unique 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 uses Alice's public key P A , or a key P derived from it A1 In other words, the first transaction is sent from Bob 103b to Alice 103a.

[0093] Bob 103b may send transaction Tx1 to a derived public key from Alice's public key. For example, Alice 103a has an authentication 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 use, for example, a Diffie-Hellman exchange, to derive a shared secret key, S AB Alice 103a and Bob generate a (certified) public key and a shared secret key S AB Bob 103b can generate a derived public key using P A1 Later, if Bob wants to send another token, for example, a second instance of the same first token, or a token worth a different amount of assets, Bob 103b may send it 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 the shared secret key, respectively. For example, the derived public keys 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 separate output. Preferably, the first token is included in an unspendable transaction output. A transaction can be rendered unconfirmed by including an opcode that terminates the execution of that output, i.e., when executed with a later transaction's unlock script. Certain blockchain protocols use the OP_RETURN opcode (or an OP_FALSE opcode followed by an OP_RETURN opcode) to achieve this function. Such an output, for example, is referred to below as the OP_RETURN output, although it is understood that other implementations or protocols may use other mechanisms to include payload data in the form of tokens in a spendable 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) consists 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, and 702c. Input 701 contains an unlock script for unlocking 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" does not refer to a particular order of the outputs, but is used as a label to distinguish between different outputs. The second output 702b includes Alice's public key P A1 That is, the second output 702b contains 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 the 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 (however, 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 The third output 702c can transfer an amount y of the digital asset to Bob 103b.

[0096] As mentioned above, the first transaction Tx1 includes a first token in output 702a. <data1>may be included in unspent outputs. <data1>includes multiple data fields. Each data field contains respective data. The first data field represents a first quantity of the asset, i.e., contains data defining the first amount. For example, the data can represent a number, such as 100. The second data field consists of ciphertext. The ciphertext represents an encrypted identifier for 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 encryption key may be part of the same public key cryptosystem or 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 containing 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 certified by Bob or some other authority such as a bank, government, or certificate authority. If Bob provides Alice's public key P A If Bob 103b determines that Alice 103a is not authenticated, Bob 103b may decide not to issue the first token to Alice 103a, i.e., Bob does not generate the first transaction Tx1 and does not send the first transaction 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 Alice's 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 other tokens. When Alice 103a uses the first token, for example, to pay for a subscription, the number of payments increases by one. Further optional data fields may be included.

[0099] Once the first transaction Tx1 is included in the blockchain 150, Alice 103a can generate a second transaction Tx2. Bob 103b first notifies Alice 103a that the first transaction has been included in the blockchain, or Alice can create a second transaction Tx2 by using her public key P in the unspent transaction output list (UTXO list). A1 Alice 103a may notice that Bob is sending outputs to her derived public key, and so she may be able to monitor 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 pre-defined protocol between the token issuer (Bob) and the person with whom Alice is trying to spend the asset (which could be Bob or Charlie).

[0101] FIG. 9 shows an example of a second transaction Tx2 with 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 of h1, Alice 103a 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 amount of an 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 a 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 be a second token <data2>In other words, the lock script needs a preimage of hash h2, which is the second token <data2>is.

[0104] Figure 10 shows the second token <data2>Here is an example of the expression: The second token is the first token <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 the field representing the remaining amount of tokens to reflect that a second amount of asset is being transferred. As another example, the number of payment fields may also change, 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 submit the transaction to the blockchain network 106. Additionally or alternatively, Alice 103a may submit the transaction to Bob or Charlie 103c. If Alice 103a is using the token with the token issuer (Bob 103b), she may submit the second transaction Tx2 to Bob 103b. If Alice 103a is using the token for an asset provided by another party, i.e., Charlie, she can submit the second transaction Tx2 to 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 Γ represents the total quantity of the first token. At the 1st 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 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 redeemable assets. For example, the smallest denomination of a British pound is 1 cent. However, the first token can be divisible into amounts smaller than 1 penny.

[0107] Figure 11 illustrates how a first token can be split according to this protocol. As shown, root node 1101 in the root layer represents 100 pounds, each child node 1102a, 1102b in the first child layer represents 50 pounds, and each child node 1103a-d in the second child layer represents 25 pounds. Child nodes 1103a-d in the second child layer 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 layer includes two child nodes 1102a, 1102b. In this layer, each child node 1102a, 1102b represents the same subamount ("first subamount") of the first amount. The second layer includes four child nodes 1103a-d. Each node in the second layer represents the same subamount ("second subamount") of the first subamount. The first amount, first subamount, and second subamount are different amounts. Referring to FIG. 11, 100 pounds (first amount) is divided into two lots of 50 pounds (first subamount) in the first child layer and into four lots of 25 pounds (second subamount) in the second child layer. The subamounts represented by each pair of child nodes in a given layer give the subamount (or amount) represented by their parent node in the "higher" layer.

[0108] If the first token, and therefore the root node, represents the first quantity A, then the i-th layer of the tree structure is 2 i-1 It consists of 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, representing a total of £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 later 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 calculated based on a specific component: each child node is based on the root node, and each root node is based on Alice's public key P A The root node may be based on the (RSA) modulus N used to encrypt Tx. The root node may be based on the identifier TxID1 of the first transaction Tx. In this way, 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, the first transaction identifier TxID.

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

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

number

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

[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 in the tree is spent, an X value is revealed. A verifier can calculate the corresponding Γ value for that node and the nodes above it. Compromising any Γ value for a node below that node allows the public to factorize N and thus reveal Alice's identity. Compromising the X value of a node above that node has the same effect.

[0117] Suppose Alice wants to pay Charlie 75 pounds, 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 therefore can be represented by any data. When calculating Ω0, Alice can apply the index (in this case "0"). Depending on the split of the tokens, Alice can calculate Ω i In that case, Alice must calculate a different index (e.g., Ω 01 Apply "01" to

[0119] X 00 is the Γ 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 the Γ such that 010 is one of the square roots of:

number

[0122] As mentioned above, Alice 103a does not need to compute the entire tree if she wants to, but she can compute the entire tree if necessary. She can work her way up from the top and compute the value of each node as needed. However, it is important that she publish all values, because leaking the value of a child's Γ along with the value of X would impair the factorization of N. For example, 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 indices and balances, Charlie103c can determine the starting balance and the value represented by the X value. To save some calculations, the value X of the starting balance and a subamount corresponding to the X value can be added to the second token.

[0124] Once the second transaction, Tx2, is 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 the event of a 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 her 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. Here, 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. However, changes 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, any changes to the inputs, including changes 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 satisfy miners. However, it contains all the information Charlie103c needs to verify Alice's payment, and Alice's signature and the hash function (e.g., any script hash function like SHA256 or double SHA256) provide the authenticity and integrity of all the information.

[0128] Charlie 103c receives 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. Charlie 103c can obtain the transaction directly from Alice 103a or through an intermediate source. The second token also contains the remaining balance of the token, 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 the hash of the first token h1, Charlie determines 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 the first token (recall that the first token in the 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 does not follow the protocol. In that case, Charlie103c does not sign or submit the second transaction to the blockchain.

[0130] Charlie 103c also determines whether the values ​​X representing the subquantities are each based on the identifier TxID1 of the first transaction Tx1. Charlie 103c can also determine whether the value X is based on the (RSA) modulus included in the token. For example, Charlie may 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 can make 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 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 in which each token is represented by the tree structure of Figures 5 and 11, Charlie can determine the amount represented by 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. After verifying the first amount, the balance, and the second amount, Charlie determines whether the sum of the amounts 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 the number of child nodes in the tree. Therefore, to generate a child node, the value must be squared (to a power of 2). Each child node is the square root of its parent node in the tree. Therefore, to generate a parent node, each child node must be squared. 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 to 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 candidate nodes generated from , d1∈{±1,±2}. If the candidate node is a left child node Γ left If , 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 a child node is: then the candidate node should be mapped to the root node by multiplying the candidate node by some value d. The value d also depends on the position of the candidate node in the tree.

number

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

number

[0138] As described above, Charlie 103c verifies the second token and, if satisfied, submits 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 may be a bank and the token may represent electronic cash. When the updated second transaction Tx2' appears on the blockchain, Bob can transfer the second amount of electronic cash to Charlie 103c.

[0139] The following shows an example of the steps taken by Alice 103a, Bob 103b, and Charlie in an exemplary scenario where Alice 103a, Bob 103b, and Charlie 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 has 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 established entity, and Bob also has a public key (e.g., an ECDSA public key) P B 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 may relate to the certificate of the online banking website.

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

[0142] Step 1: Alice 103a generates two RSA prime numbers 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, who verifies Alice's identity and account, i.e., whether she is eligible to be issued a 100 GBP token.

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

[0145] Note that this cryptogram is publicly available on-chain. If Alice103a were to double-spend her token, her RSA private key would be publicly derived. Thus, her identity would be publicly revealed, and Alice103a could be penalized for double-spending.

[0146] Step 4: Alice 103a and Bob 103b 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 the first blockchain transaction to issue £100 tokens to Alice 103a, as shown in Figure 7. The output of the transaction is a colored output, which is Alice's public key P A1 To spend the output, Alice must obtain the hash value h1 and P A1 In this particular example, the transaction includes an OP_RETURN output that colors the output. The data payload contains 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 if the miner the merchant is connecting to is running on a pruned blockchain. All outputs are signed by Bob103b with the trusted public key P B Note that this can be verified by the following: 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 all receive P from Alice. A1 The signature by

[0150] Step 6: Suppose Alice 103a wants to pay £75 to Charlie the merchant. 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 calculates the necessary node values ​​of the tree and their square roots. Alice 103a does not need to calculate the entire tree; she can work her way up and calculate the value of each node as needed. It is important that she does not reveal all the values ​​of the tree, because leaking the children's Γ values ​​along with the X values ​​would undermine the factorization of N. For example, X 00 and Γ 000 is Γ 00 gives two different square roots of

[0153] Next, Alice103a sends the transaction (X) to Charlie via a blockchain transaction template, along with the previous OP_RETURN payload data1. 00 ,X 010 ,N). Note that Alice 103a does not need to uncover the Γ-tree. The transaction is shown in Figure 9, and the data2 payload can be represented by Figure 10.

[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 indices and balances, we can calculate the value represented by the starting balance and 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 can hold Alice 103a accountable if she double-spends or violates 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 the event of a dispute.

[0156] Alice103a uses SIGHASH_SINGLE (0x03) and SIGHASH_ANYONECANPAY (0x80) for her signatures. 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 results 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 outpoint in other ways, but if the protocol is not followed, any token value represented by this outpoint 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 also 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 settlement: Bob103b uses public key P Ai or can be notified by Charlie 103c that a payment is coming from Alice 103a. Since TxID2' is recorded on the blockchain, Charlie has no urgency to contact Bob 103b. Alice 103a cannot double the payment to Charlie because the corresponding outpoint has been used. The payment can be made 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 colorize the output with TxID2' in step 8 and use his 75 pounds as a divisible token. The next recipient, say Dave the lumberman, would have to verify all the information going back to TxID1.

[0165] The mechanism of dividing 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 divide 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, there may be provided a method, apparatus or program according to any one or more of the following:

[0167] (Statement 1) A computer-implemented method for generating a second transaction on a blockchain, the blockchain 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; 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 being used to represent a respective subamount 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 layer including a root node and a sequence of one or more child layers, each child layer including one or more child node pairs, each pair being a child of a respective node in a previous layer 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 layer.

[0173] (Statement 6) The method according to Statement 5, wherein each of the one or more values ​​is the 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, the 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 one 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 layer includes the square root of the respective node in the previous layer, and each second child node in the i-th layer includes the square root of the 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 dependent on Statement 7, wherein the first and second cryptographic hash functions are different cryptographic hash functions.

[0182] (Statement 13) The method according to 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 one 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 described in 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 the first party; The method described in Statement 16, including: (Statement 18) The method of 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 for 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 executed 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; submitting the updated second transaction to the blockchain network for inclusion in the blockchain; A method comprising:

[0190] (Statement 22) The method described in Statement 21, wherein the first token includes a modulus of the first party's public key, and the determining step includes: 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 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 layer including a root node and a sequence of one or more child layers, each child layer including one or more child node pairs, each pair being a child of a respective node in a previous layer 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 layer.

[0192] (Statement 24) The method of Statement 23, including determining the second quantity of the second token based on respective quantities 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 one 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 one 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) The 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, comprising:

[0198] (Statement 30) 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, 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 being 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 the 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 of any one of claims 30 to 31, including:

[0201] (Statement 33) The method according to Statement 31 or 32, comprising the 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 second party's first public key to be unlocked.

[0203] (Statement 35) A method according to any one 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 one of Statements 30 to 35, comprising: 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 the 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, 21. A computing device, wherein 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, 29. A computing device, wherein 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-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, 38. A computing device, wherein 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 the input of the second transaction 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) the first amount of the token asset; and b) a cryptographic identifier of the first party, the cryptographic identifier being generated by encrypting the first party's identifier with a second public key of the first party, the second public key including a modulus; and c) the first token including the modulus.

[0213] (Statement 45) A computer-readable storage medium storing 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 storing the first transaction described in Statement 46.

[0216] According to another aspect of the technology disclosed herein, there may be provided a method including some or all of the actions 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 computer 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 after reading the disclosure herein. 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 updating 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 first amount of the token asset; determining whether the second token is a valid token 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; submitting the updated second transaction to a blockchain network for inclusion in the blockchain; A method comprising:

2. 2. The method of claim 1, wherein the first token includes a modulus of the first party's public key, and wherein 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.

3. 2. The method of claim 1, wherein the determining step includes: 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 a predetermined modulus; the tree structure including a root layer including a root node and a sequence of one or more child layers, each child layer including one or more child node pairs, each pair being a child of a respective node in a previous layer 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 each node in the previous layer.

4. 4. The method of claim 3, further comprising determining the second quantity of the second token based on a respective quantity represented by each node corresponding to the one or more values.

5. 2. The method of claim 1, wherein the first transaction includes a hash of the first token, and wherein a) determining whether the first token in the second transaction is identical to the first token in the first transaction includes 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.

6. 2. The method of claim 1, wherein the determining step comprises 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.

7. 2. The method of claim 1, wherein the second transaction includes a hash of the second token, and wherein 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.

8. The method of claim 1 , wherein the obtaining step includes receiving the second transaction from the first party.

9. 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 the input of the second transaction to include a first public key of the first party in order to be unlocked; submitting the first transaction to the blockchain network for inclusion in the blockchain; 10. The method of claim 1, comprising:

10. A computer device comprising: 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 one of claims 1 to 9 when run on the processing device.

11. A computer program embodied on a computer readable storage device and arranged to perform the method according to any of claims 1 to 9 when run on a computing device.

Images