How to use blockchain

Abstract

Contributions to the work by contributors at each level in the defined hierarchical structure are recorded in one or more blockchain transactions. One or more lower-level contributors each provide one or more lower-level contributions to a higher-level contributor, and the higher-level contributor provides a higher-level contribution in response to the one or more lower-level contributions. A high-level contributor transaction includes one or more inputs, including one or more pointers to one or more usable outputs of one or more lower-level contributor transactions, and one or more transaction signatures. The transaction includes, along with the one or more pointers, a contribution commitment that expresses a relationship between the high-level contributor and the lower-level contributor within the defined hierarchical structure. The one or more transaction signatures attest to the relationship.

Description

[Technical field]

[0001] This disclosure describes specific new second-tier applications of blockchain, i.e., secondary functions added to the blockchain. [Background technology]

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

[0003] Traditionally, transactions in a blockchain are used to transfer digital assets, i.e. data that acts as a store of value. However, blockchains can also be used to overlay additional functionality onto a blockchain. For example, blockchain protocols 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 more complex data to be incorporated. For example, this may be used to store electronic documents or even audio or video data within the blockchain.

[0004] Each node in the network can have one, two, or all three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions across 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 of the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or mined into blocks. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) remains stored as an immutable public record at each node in the P2P network.

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

[0006] In the “output-based” model (sometimes called the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. A usable output includes an element (the “unspent transaction output”), sometimes called the UTXO, that specifies an amount of digital assets. The output may further include a locking script that specifies a condition for redeeming the output. Each input includes a pointer to such an output in a preceding transaction, and may further include an unlocking script for unlocking the pointed-to output’s locking script. Thus, consider a pair of transactions, which we call the first and second transactions (or “target” transactions). The first transaction includes at least one output that includes a locking script that specifies an amount of digital assets and defines one or more conditions for unlocking the output. The second, target, transaction includes at least one input that includes a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second, target transaction is sent to the P2P network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction, and another is that the output of the first transaction has not already been redeemed by another, previous valid transaction. A node that finds the target transaction invalid according to any of these conditions will not propagate it and will not include it for mining into a block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount transferred not by referencing the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing absolute account balances. The current state of every account is stored and constantly updated by miners, separate from the blockchain. The state is modified by executing smart contracts, which are included in transactions and executed when the transaction is validated by nodes in the blockchain network. Summary of the Invention [Means for solving the problem]

[0009] It is desirable to take advantage of the blockchain to provide an immutable record of a work where multiple contributions are made by different contributors. The technical challenge in this context is to adequately record the potentially complex history of contributions by contributors in a potentially complex hierarchical structure.

[0010] The present disclosure provides what may be referred to herein as a "collaborative attestation protocol." In such a protocol, a collection of blockchain transactions is advantageously constructed to capture the hierarchical relationships between contributions in terms of the usage relationships between those transactions. This is an efficient way of recording transactions because it leverages much of the structure already present in transactions, thereby reducing the amount of additional data that needs to be included in the transactions (e.g., as unusable outputs or "dummy" operands in multi-operand opcodes) to fully record the hierarchical structure of contributions in a cryptographically robust manner.

[0011] A first aspect provides a computer-implemented method for recording, in one or more blockchain transactions, contributions to a work by contributors having respective levels in a defined hierarchical structure. In a defined hierarchical structure, one or more lower contributors each provide one or more lower contributions to a higher contributor, and the higher contributor provides a higher contribution in response to the one or more lower contributions, the method comprising: creating or modifying, at a computing device of the higher contributor, a top contributor transaction to provide evidence of the top contribution, the generated or modified top contributor transaction including: one or more inputs, the one or more inputs being one or more pointers to one or more usable outputs of one or more lower contributor transactions, the one or more lower contributor transactions including one or more lower contribution commitments providing evidence of the one or more lower contributions; and one or more transaction signatures of the higher contributor that satisfy one or more signature challenges of the one or more usable outputs, the top contributor transaction including a top contribution commitment computed from the higher contribution, the one or more pointers and the contribution commitment representing a relationship between the higher contributor and the one or more lower contributors in the defined hierarchical structure, and the one or more transaction signatures attesting to that relationship.

[0012] The contribution commitment (which may be, for example, a contribution hash) and the transaction pointer(s) represent the contributions and their hierarchical relationships in the form of a tree data structure (for example, in the form of a hash tree, described in more detail below). The method uses transactions as conduits and their "embedded" transactions to immutably timestamp the passing of information through the hierarchical structure, i.e., by utilizing the standard transaction signing properties of the blockchain. [Brief description of the drawings]

[0013] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates generally some examples of transactions that may be recorded on a blockchain. [Diagram 3] Here is an example of a classic binary hash tree. [Figure 4] Here is an example of a binary Merkle tree with assigned node indices. [Diagram 5] Here is an example of an authentication path for a given block of data and a given classical hash tree. [Figure 6] Here is an example of a generalized hash tree. [Figure 7] Here is an example of a generalized Merkle tree with index tuples assigned to the nodes. [Figure 8] The second example shows a branch of a generalized hash tree and how the node values ​​are calculated recursively. [Figure 9] The modified generalized hash tree shows that a new leaf node has been added. [Figure 10] We show how Merkle proofs can be performed for generalized hash trees. [Figure 11] We compare the Merkle proof operation on classical hash trees with the Merkle proof operation on generalized hash trees. [Figure 12A] Here is a third example of a generalized hash tree. [Figure 12B] Here is a third example of a generalized hash tree. [Figure 13] 12A and 12B show how the generalized hash tree of FIG. 12A and 12B can be encoded in a set of blockchain transactions. [Figure 14]We provide an example of an off-chain system where the generalized hash tree may be stored off-chain, either temporarily or permanently. [Figure 15] 4 shows a fourth example of a generalized hash tree for representing a piece of digital content with discrete segments. [Figure 16] Shows the subtree for a given segment. [Figure 17] 1 shows a modified generalized hash tree representing a re-edited piece of digital content. [Figure 18A] 1 illustrates an exemplary hierarchical structure of contributors. [Figure 18B] An exemplary hierarchy of contributions represented as a "generalized hash tree" is shown. [Figure 19A] 1 illustrates method steps for generating a set of blockchain transactions to implement a generalized hash tree, along with a schematic representation of the transactions generated at each step. [Figure 19B] 1 illustrates method steps for generating a set of blockchain transactions to implement a generalized hash tree, along with a schematic representation of the transactions generated at each step. [Figure 20] 1 illustrates an exemplary branch of a contributor hierarchy. [Figure 21] We show a set of contributions recorded in a classical binary hash tree, which does not fully capture the hierarchical relationships between these contributions. [Figure 22] FIG. 22 shows the nodes of a hash tree 1820 representing newspapers, labeled according to node index. [Figure 23] It provides a further example of hierarchical relationships between contributors, separating on-chain data from data exchanged off-chain. [Figure 24] It provides a further example of hierarchical relationships between contributors, separating on-chain data from data exchanged off-chain. [Diagram 25] 1 illustrates a schematic diagram of the relationship between a set of transactions and a hierarchy of contributions. [Figure 26] Shows the mapping between the contributor hierarchy and the corresponding transaction chain. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured 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 ones of the nodes 104 belonging to different peers. Each node 104 includes a processing device including one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors, and / or field programmable gate arrays (FPGAs). Each node also includes a memory, i.e., 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, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disk drives.

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

[0016] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 assume the role of miners 104M, which mine blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (sometimes also referred to as "full copy" nodes), each of which stores in its respective memory a respective copy of the same blockchain 150. 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.

[0017] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "used" in the current transaction 152j. In general, the preceding transaction can be any transaction in the pool 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" in this specification refers to what precedes in the logical sequence linked by the pointer, not necessarily to the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion below regarding orphaned transactions). The preceding transaction 152i can similarly be referred to as the preceding transaction or the previous transaction.

[0018] The input of the current transaction 152j also includes the signature of the user 103a to which the output of the previous 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 previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amount among multiple users (one of which may be the original user 103a to provide change). In some cases, a transaction may have multiple inputs and may collect amounts from multiple outputs of one or more previous transactions together and redistribute them into one or more outputs of the current transaction.

[0019] The above is sometimes called an "output-based" transaction protocol, or sometimes called an unspent transaction output (UTXO) type protocol. A user's total balance is not defined in any one number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are spread across many different transactions 152 in the blockchain 151.

[0020] An alternative type of transaction protocol is sometimes called an "account-based" protocol, as part of the account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, not by referencing back to the UTXO of a preceding transaction in the sequence 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 the running transaction tally (also called "position") of the account. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed with the transaction. This data field may point to a preceding transaction, for example if a previous transaction ID is included in the data field.

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

[0022] In the output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has already been validly redeemed by the input of 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 is trying to spend or redeem has not already been spent / redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This protects against double-spending, where a user tries to spend the same transaction output multiple times. On the other hand, the account-based model protects against double-spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance has a single defined state at any point in time.

[0023] In addition to validity checking, at least some of the nodes 104M compete to be the first to generate a block of transactions, in a process known as mining, which is backed by a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has some predefined number of leading zeros. A property of a hash function is that it has an output that is unpredictable with respect to the input. Thus, this search can only be performed by brute force, thus consuming a significant amount of processing resources at each node 104M trying to solve the puzzle.

[0024] The first miner node 104M that solves the puzzle announces this to the network 106 and provides its solution as a proof. The proof can be easily checked by other nodes 104 in the network (once the solution to the hash is given, it is easy to check that the hash output matches the conditions). The pool 154 of transactions for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each such node. A block pointer 155 that points back to the previously generated block 151n-1 in the chain is also assigned to the new block 151n. Proof of work helps to reduce the risk of double-spends. Since it takes a lot of effort to create a new block 151, and a block containing double-spends is likely to be rejected by other nodes 104, there is no incentive for a mining node 104M to allow its block to contain double-spends. Once created, blocks 151 cannot be modified because they are recognized and maintained according to the same protocol at each of the storage nodes 104S in the P2P network 106. Block pointers 155 also impose a sequential order on the blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

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

[0026] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nothing (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generating" transaction. It automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. Regular (non-generating) transactions 152 often also specify an additional transaction fee in one of their outputs, further rewarding the winning miner 104M who generated the block 151n in which the transaction was included.

[0027] 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 even an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. In principle, however, any given node 104 may take the form of a user terminal or a group of user terminals networked together.

[0028] The memory of each node 104 stores software configured to run on the processing unit of the node 104 to perform its role(s) and process transactions 152 according to the node protocol. It will be understood that any operations attributed to the node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented at the application layer, in one or more applications, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof. Additionally, the term "blockchain" as used herein is a general term referring to this type of technology in general, and is not limited to any particular specific blockchain, protocol, or service.

[0029] Also connected to the network 101 are computer equipment 102 of a number of parties 103 in the role of consuming users. These act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions for the other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and its respective computer equipment 102a, and a second party 103b and its respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 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, but this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be substituted with "first party" and "second party," respectively.

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

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

[0032] 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 in the outputs of the various 152 transactions belonging to that party scattered throughout the blockchain 150.

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

[0034] An instance of a client application or software 105 on each computer facility 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 may 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, indeed, to inspect the transactions of other parties in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides credit for transactions, in part, through its public visibility). The wallet functionality on each computer facility 102 is configured to formulate and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate the transactions 152 according to the node protocol and, in the case of the forwarding node 104F, to forward the transactions 152 for propagation throughout the network 106. The transaction protocol and the node protocol 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 the transaction protocol may allow different subtypes of transactions within it). The same node protocol is used by all nodes 104 in the network 106 (although different subtypes of transactions may be handled differently according to rules defined for the subtypes, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

[0035] 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 that points back to a previously created block 151 in the chain to define a sequential order to the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the creation transaction) includes a pointer that points back to a previous transaction to define an order for sequences of transactions (sequences of transactions 152 are allowed to diverge). The chain of blocks 151 goes back to a creation block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to a genesis block 153, not a predecessor transaction.

[0036] When a given party 103, say Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in Alice's client application 105) according to the relevant transaction protocol. Alice then transmits the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F that is closest 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 includes first checking whether the newly received transaction 152j meets certain conditions to be "valid". Examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity checking may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol, or may be defined by a combination of scripts and the node protocol.

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

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

[0039] Different nodes 104 may initially receive different instances of a given transaction and thus have conflicting views of which instance is "valid" until one instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept this and discard (treat as invalid) the unmined instance it originally accepted.

[0040] 1.2 UTXO-based model FIG. 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of the blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation for all possible embodiments.

[0041] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). The UTXO may also include, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also include a header 201, which may include indicators of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include the ID of the transaction. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0042] Suppose Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes an amount of the digital asset locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are simply 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 can point back to any preceding (i.e., prior) transaction that still has unspent outputs 203 locked to Alice.

[0043] The predecessor transaction Tx0 may already be validated and included in the blockchain 150 at the time Alice creates her new transaction Tx1, or at least by the time Alice sends it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be generated together and sent to the network 102, or even Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers (such as which transaction points to which other transaction) specified in the transaction. The terms may be equivalently replaced with "predecessor" and "successor" or "predecessor" and "descendant", "parent" and "child", etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a predecessor transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. Orphans may be discarded or buffered for some time to await their parent, depending on the node protocol and / or miner behavior.

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

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

[0046] In the illustrated example, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that for UTXO0 to be redeemed (or more precisely, for a subsequent transaction that tries to redeem UTXO0 to be valid), Alice’s signature Sig P A [Checksig P A ] is the public key P from Alice’s public-private key pair.A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in embodiments is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0, in order to identify it among any other possible outputs of Tx0. The input 202 of Tx1 also includes an unlock script that includes Alice's cryptographic signature, created by applying Alice's private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0047] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which runs the lock script and the unlock script together to check if the unlock script meets the conditions defined in the lock script (which may include one or more criteria). In embodiments, this involves concatenating the two scripts: <Sig P A > <P A >||[Checksig P A ] Here, '||' represents concatenation, '<...>' means to put data on the stack, and '[...]' is a function contained in the unlock script (a stack-based language in this example). Equivalently, rather than concatenating the scripts, they may be executed sequentially using a common stack. Either way, when executed together, the scripts will combine Alice's public key P A, to authenticate that the lock script in the input of Tx1 contains Alice's signature, signing the expected portion of the data. In order to perform this authentication, the expected portion of the data itself (the "message") must also be included in Tx0. In embodiments, the signed data includes the entirety of Tx0 (thus there is no need to include a separate element that specifies the signed portion of the data in plaintext, since the signed portion of the data is already implicitly present).

[0048] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the message in plaintext (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the plaintext version of the message with it as the signature, thereby allowing any holder of the public key to authenticate the signature. Thus, any reference herein to signing a particular piece of data or transaction, etc., can, in embodiments, mean signing a hash of that piece of data or transaction.

[0049] If the unlock script of 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 that it adds it to the pool 154 of transactions waiting for proof-of-work. If it is a forwarding node 104F, it forwards the transaction Tx1 to one or more other nodes 104 in the network 106 for it to be propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as spent. Note that Tx1 can only be valid if it uses unspent transaction outputs 203. If it tries to use an output that has already been spent by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Thus, node 104 also needs to check whether the referenced UTXO 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.

[0050] 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 ground of invalidity in most transaction models. Therefore, such a transaction will not be propagated or mined into a block 151.

[0051] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. It is not possible to "leave" some of the amount defined in the UTXO spent while another amount is spent. However, the amount from the UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. So, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change in the second output of Tx1 or to pay another party.

[0052] In practice, Alice also typically needs to include a fee for the winning miner, because today, the reward for generating transactions 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 nodes 104M, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the miner protocol does not force the miner 104M to accept the transaction 152 if it does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input(s) 202 of a given transaction 152 and the total amount specified in the output(s) 203 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 in this document necessarily precludes that miner fees may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

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

[0054] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ] and write [Checksig P A ]=OP_DUP OP_HASH160 <H(P A)>OP_EQUALVERIFY can mean OP_CHECKSIG. "OP_..." refers to a specific opcode in the Script 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, all occurrences of the signature ('sig') are removed from the script, but additional requirements such as hash puzzles remain for transactions to be verified by the 'sig' input. As another example, OP_RETURN is a Script language opcode to store metadata within the transaction, thereby generating an unspendable output of the transaction that can record the metadata in an immutable manner in the blockchain 150. For example, the metadata can include a document that is desired to be stored in the blockchain.

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

[0056] A lock script is sometimes called a "scriptPubKey", referring to the fact that each transaction contains the public key of the party being locked. An unlock script is sometimes called a "scriptSig", referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain150 that the condition for a UTXO to be redeemed includes authenticating the signature. More generally, one or more conditions may be defined using a scripting language. Thus, the more general terms "lock script" and "unlock script" are sometimes preferred.

[0057] Contributor Hierarchy Figure 18A shows a schematic block diagram of what is referred to herein as an "external hierarchy" of contributors (the contributor hierarchy). Each contributor in the hierarchy is a person or other entity that makes some defined contribution that ultimately forms the basis of the final "work."

[0058] A core objective of this disclosure is to represent such a hierarchical structure in a collection of blockchain transactions that can be immutably recorded on the blockchain 150.

[0059] Please note that the terms "author" and "contributor" are used interchangeably in this description.

[0060] In the exemplary external hierarchical structure of Figure 18A, there are two distinct branches. In the first branch, shown on the left, a first group of "sub-author" CAs are said to be at level 4 in the hierarchical structure. The first group of sub-author CAs consists of five sub-authors, denoted by references C-A0 through C-A4, respectively. Each is uniquely identified by a public key, denoted P-A0 through P-A4, respectively. Each makes a separate individual contribution, embodied as a data block, denoted D-A0 through D-A4, respectively.

[0061] Please note that the term "data block" is used in the context of this application to refer to a collection or portion of data that captures the contributions of an individual contributor, such as a document, file or other data block. This is distinct from a block 151 of a blockchain 150. The terms "data block" and "data object" are used interchangeably herein.

[0062] The first group of subordinate authors CA is supervised by a "senior author" who is at level 3 in the hierarchical structure. The senior author supervising the first subordinate author group CA may be called the first level 3 senior author and is denoted by reference C-C0. He (she / it) is uniquely identified by the public key P-C0 and makes a contribution D-C0 in response to the contributions C-A0 to C-A4 of the subordinate authors he supervises. The first level 3 senior author C-C0 is supervised by the first level 2 senior author C-E0. The level 2 senior author C-E0 is uniquely identified by the public key P-E0 and makes his own contribution D-E0 in response to the contributions of the first level 3 senior author C-C0.

[0063] In the hierarchical branch shown on the right, a second group of subordinate authors CB (in this example consisting of three subordinate authors C-B0 to C-B2) are associated with unique public keys referenced P-B0 to P-B2, respectively, and make individual contributions D-B0 to D-B2.

[0064] A second group of subordinate authors CB is overseen by a second level 3 superior author C-D0, who is identified by public key P-D0 and makes his own contribution D-D0 in response to the contributions D-B0 to D-B2 of the subordinate authors C-B0 to C-B2 whom he oversees.

[0065] The second level 3 senior author CD is overseen by two level 2 senior authors, referred to as the second level 2 senior author C-F0 and the third level 2 senior author C-F1.

[0066] The second and third level-2 top authors, C-F0, C-F1, are identified by public keys denoted by references P-F0 and P-F1, respectively, and make their own individual contributions, denoted by references D-F0 and D-F1, respectively, in response to a contribution D-D0 of the first level-3 top author C-D0, which they jointly oversee.

[0067] The Lead Editor C-G0 at level 1 of the hierarchy has final responsibility for the final work (his contribution), denoted by reference D, and is responsible for overseeing all three senior authors C-E0, C-F0 and C-F1 at level 2. The Lead Editor is identified by a public key P-G0.

[0068] Although not shown, at the top of the hierarchy (level 0) is a copyright authority to which the final work D is submitted.

[0069] FIG. 18B shows an example of a data structure that may be used to provide evidence of the individual contributions made by various contributors, as well as the hierarchical relationships among those contributions that arise because of the hierarchical relationships among the contributors themselves. The data structure is in the form of what is referred to herein as a “generalized hash tree” 1820. Generalized hash trees are described in more detail below. For the time being, suffice it to say that generalized hash trees have some properties in common with “classical” hash trees, but are less constrained and can be constructed to represent hierarchical relationships in ways not possible with classical hash trees. A generalized hash tree 1820 is formed of a number of nodes at each level in the tree and directional edges between those nodes, where each node is either a hash of an underlined block of data (leaf nodes represented as open circles) or a hash of the concatenation of the values ​​of its “child nodes” (non-leaf nodes represented as filled circles). In short, in contrast to classical hash trees, each non-leaf node can have any number of children, such that different non-leaf nodes may have different numbers of children; furthermore, non-leaf nodes can appear at any level in the hierarchy, such that a non-leaf node may have children that are a combination of leaf and non-leaf nodes.

[0070] For reasons discussed in more detail below, generalized hash trees provide a novel and useful way of expressing hierarchical relationships of the kind shown in FIG. 18A. However, before describing the underlying principles of generalized hash trees in more detail, an overview of a protocol is provided by which a set 1920 of blockchain transactions 152 (shown in FIGS. 19A and 19B, described below) may be constructed to embody a generalized hash tree of the kind shown in FIG. 18B on a blockchain 150. That is, a protocol for constructing blockchain transactions in such a way that they fully encode not only the values ​​of the nodes (referenced H2-A0 through RH), but also the hierarchical relationships between those nodes. This protocol may be referred to herein as a “collaborative attestation protocol.” Some general principles and considerations underpinning collaborative attestation protocols are discussed below. First, a specific example of a method implemented according to the protocol is described to provide context.

[0071] Before describing the set of blockchain transactions 1920, the structure of the generalized hash tree 1820 will be described with reference to the contributor hierarchy of Figure 18 A. Following the example of Figure 18A, each contribution is represented by a leaf node at a level in the generalized hash tree 1820 that corresponds to the level of the contributor in the external hierarchy (i.e., a contribution by any author at level n is represented by a leaf node at level n in the generalized hash tree).

[0072] Thus, the contributions of the first group of subordinate authors CA are represented by five leaf nodes at level 4 in the hierarchical structure of the generalized hash tree 1820. These nodes have respective values ​​and are represented by references H2-A0 through H2-A4, respectively. Note that in FIG. 18B, some of the references have been omitted to avoid overcrowding. In this example, the value of each non-leaf node is the double hash of the underlying contribution to which it corresponds. Thus, for example, the value H2-A1 of the leaf node corresponding to contribution D-A1 is the double hash of contribution D-A1, the value H2-A4 of the leaf node representing contribution D-A4 is the double hash of that contribution, and so on.

[0073] Similarly, for the second group of subordinate authors, CB, each contribution is represented by a leaf node at level 4 in the hierarchical structure of the generalized hash tree 1820, whose value is obtained by double-hashing that contribution. For example, the value H2-B2 of the node corresponding to contribution D-B2 is the double-hash of that contribution.

[0074] At level 3 of the generalized hash tree 1800, the overall contribution of each group of subordinate authors CA and CB is represented by respective non-leaf nodes IH-A and IH-B. The value of non-leaf node IH-A representing the overall contribution of the first group of subordinate authors CA is a single hash of the concatenation of all the values ​​of the leaf nodes representing the contributions of the first group of subordinate authors CA, i.e., a single hash of the concatenation of the leaf node values ​​H2-A0 through H2-A4 representing the individual contributions by the first group of subordinate authors CA. Similarly, the value of non-leaf node IH-B representing the overall contribution of the second group of subordinate authors CB is a single hash of the concatenation of the leaf node values ​​H-B0 through H-B2 representing its individual contributions D-B0 through D-B2.

[0075] Furthermore, the contributions of each level 3 top author C-C0, C-D0 are represented by level 3 leaf nodes in the generalized hash tree 1820, denoted by reference characters H2-C0 and H2-D0, respectively, each of which is a double hash of that top author's individual contributions D-C0, D-D0.

[0076] At level 2 of the generalized hash tree 1820, the overall contribution of the first group of subordinate authors, CA, together with the contribution of the first level 2 senior author C-C0 who oversees that group, is represented by a single non-leaf node with value IH-C. That value is the concatenation of the value IH-A, representing the overall contribution of the first group of subordinate authors, CA, and the value H2-C0 of the level 2 leaf node representing the contribution of the first level 3 senior author C-C0.

[0077] The overall contribution of a second group of junior authors, CB, together with the contribution of the second level 3 senior author C-D0 who oversees that group, is represented by a second non-leaf node at level 2, with a similarly calculated value IH-D.

[0078] Because the contributor hierarchy has three level 2 top authors, C-E0, C-F0, and C-F1, each with separate contributions D-E0, D-F0, and D-F1, the generalized hash tree 1820 contains three level 2 leaf nodes representing each of those contributions D-E0, D-F0, and D-F1. The values ​​H2-E0, H2-F0, and H2-F1 of each of these leaf nodes are computed as the double hash of the contribution represented by that node.

[0079] At level 1 of the generalized hash tree, there are two non-leaf nodes with values ​​denoted by references IH-E and IH-F, respectively. The non-leaf node with value IH-E represents the overall contribution of the first group of subordinate authors, CA, together with the contribution D-C0 of the first level-3 top author C-C0 who supervises him, and the contribution D-E0 of the first level-2 top author C-E0 who supervises him. Again, its value IH-E is calculated as a hash of the concatenation of the value IH-C (the overall contribution of the first group of subordinate authors, CA, plus the contribution of its direct supervisor C-C0) and the value of the leaf node H2-E0, which represents the contribution D-E0 of the first level-2 top author C-E0.

[0080] The other level 2 non-leaf node has the value IH-F calculated as the concatenation of the non-leaf node's value IH-D (representing the contribution of the second lower-level author group CB and the second level 2 top author C-D0 who directly supervises it) with the two values ​​H2-F0, H2-F1 of the two leaf nodes representing the contributions D-F0, D-F1 of the second and third level 2 top authors who supervise the second level 2 top author H2-D0.

[0081] The leaf node at level 1 represents the lead editor's contribution C-G0, which is the final work D that the lead editor created in response to the senior author's contributions D-E0, D-F0, and D-F1 at level 2. The value of that node H2-G0 is calculated as the double hash of the final work D.

[0082] Finally, at level 0 of the generalized hash tree, the root node has a value RH (the root hash) that is calculated as the single hash of the concatenation of the values ​​IH-E, IH-F of the non-leaf nodes at level 1 and the value H2-G0 of the leaf nodes at level 1.

[0083] 19A and 19B, an example of a method implemented in accordance with a collaborative authentication protocol is described that creates a set of blockchain transactions 1920 that embodies the generalized hash tree 1820 of FIG.

[0084] The steps of the method (protocol) are shown in Figures 19A and 19B in a flowchart running horizontally from left to right at the top of the page. Under each step of the flowchart is shown generally a corresponding subset of one or more transactions from the set of transactions 1920. These are the transactions that were created in that step. Each step except the first creates at least one spending transaction that has a particular spending relationship with the transaction created in the previous step. It is these spending relationships that represent the hierarchical relationships between the nodes in the generalized hash tree of Figure 18B. The values ​​of the nodes themselves are encoded in the output of the transactions 1920, as will be described in more detail below.

[0085] Starting with FIG. 19A, in step 1900, each subordinate author of each subordinate author group CA, CB creates an initial transaction with at least one usable output locked to his public key. In step 1900, the transactions created by the first group of subordinate authors CA are denoted TX-A0 to TX-A4, respectively, and each has at least one usable output locked to the public key P-A0, ..., P-A4 of the subordinate author who created it (i.e., each output is locked to a different subordinate author of the first group of subordinate authors CA). Alternatively, one or more of these transactions could be created by any other party. Alternatively, parts of all these transactions could be combined into a single transaction. What is important is that, to set up the next step of the method, there are five separate usable outputs (in at least one and up to five transactions), each of which is locked to the public key of a different subordinate author of the first group of subordinate authors CA. For example, by setting up a multi-signature (or a similar script with many signatures) where the ordering of the keys used to sign preserves the ordering of sub-authors, it is possible to capture the structure of the tree while maintaining a one-to-one identifiable map between the relationships between authors and their content.

[0086] The transactions created by the second group of sub-authors CB are denoted with references TX-B0 to TX-B2, each having at least one usable output locked to the public keys P-B0, ..., P-B2 of different sub-authors of the second group of sub-authors CB. The discussion in the previous paragraphs regarding the alternative ways of constructing the initial transactions applies equally.

[0087] In step 1902, each sub-author group CA, CB creates a single usage transaction (i.e., one usage transaction per sub-author group) that consumes all of the outputs of the initial transactions created by the individual members of that group in step 1900. That transaction is sometimes referred to as the first group transaction TX-A.

[0088] Thus, for a first group CA of subordinate authors that have created among themselves five initial transactions TX-A0 to TX-A4, in step 1902, the group CA as a whole creates a single usage transaction, denoted by the reference TX-A, with (at least) five inputs that each use (i.e. point to) a different one of the available outputs of said five initial transactions TX-A0 to TX-A4.

[0089] Recall that each of the initial transactions TX-A0 through TX-A4 identifies a different subordinate author of the first group of subordinate authors GA by virtue of the transaction's usable output being locked to its public key (P-A0 through P-A4, respectively). The first group transaction TX-A, which uses all five of the outputs of the initial transactions TX-A0 through TX-A4, captures the fact that the five subordinate authors belong to the same group. Using the terminology of this disclosure, those authors may be referred to as "sibling" contributors, and their contributions may be referred to as sibling contributions. The first group use transaction TX-A has at least one usable output. It is locked to the public key P-C0 of the first level 3 superior author C-C0, who oversees the first group of subordinate authors CA. This captures the hierarchical relationship between that subordinate author group CA and its "direct" overseer C-C0 within the collection of blockchain transactions 1920.

[0090] The first group transaction TX-A also serves as a proof of each sub-author’s contribution. That proof is provided by a “discretionary signature” from each sub-author. The discretionary signatures of sub-authors TX-A0 through TX-A4 are denoted by references DS-A0 through DS-A4, respectively. Discretionary signatures are described in more detail below. For the moment, suffice it to say that a discretionary signature is ignored for the purposes of validating the transaction in which it appears, i.e., miners ignore discretionary signatures for the purposes of validating the transaction, and that a discretionary signature is generated by applying a signature function to a single hash of that author’s contribution and the private key corresponding to that author’s public key. Thus, the discretionary signature DS-A0 of sub-author TX-A0 is computed by applying a signature generation function to a single hash of that author’s contribution D-A0 and the private key counterpart of his public key P-A0. This is similarly true for the remaining sub-authors.

[0091] Returning to the spendable output of the first group transaction TX-A, which is locked to the public key P-C0 of the overseer C-C0, the lock script for that output also requires receipt proofs for each of the sub-authors’ contributions D-A0 through D-A4. In our example, this is a “double-hash puzzle”, i.e. the unlock script contains a double hash of each contribution, where the double hash of contribution D-A0 is represented as H2-A0, the double hash of contribution D-A1 is represented as H2-A1, etc. This lock script can only be redeemed by a lock script containing a valid transaction signature, and the unlock script must also contain a single hash of each of the sub-authors’ contributions in order to solve the double-hash puzzle for each contribution.

[0092] The single hash of contribution D-A0 is denoted as H-A0, the single hash of contribution D-A1 is denoted as H-A1, etc. These are shown to be included in the input of the first "level 3" usage transaction TX-C, which was created by the direct supervisor of the first junior author group C-C0 (i.e., the first level 3 senior author C-C0).

[0093] The first level 3 use transaction TX-C is created in step 1904. Only after the direct overseer C-C0 receives all of the contributions D-A0 to D-A4 from the overseeing subordinate author CA can he compute the single hash value H-A0 to H-A4 (and thus make his own contribution D-C0 in response). These thus serve as proof of the direct overseer C-C0's receipt of those contributions in the first level 3 use transaction TX-C. Furthermore, the input of the first level 3 use transaction TX-C includes a valid transaction signature that signs the output (singular or output) of that transaction TX-C, using the private key counterpart of the public key P-C0 of the overseeing author C-C0 (specified in the usable output of the first group transaction TX-A).

[0094] Turning to the output of the first level-3 spending transaction TX-C, there is at least one usable output locked to the public key P-E0 of the first level-2 author C-E0 who supervises the first level-3 top author C-C0. The usable output also contains a double hash puzzle on the contribution of the first level-3 top author C-C0, denoted by reference H2-C0. Thus, the output can only be used by the first level-2 supervising author C-E0 only if it has received the latter's contribution D-C0 from the first level-3 top author C-C0, so that the former can provide a single hash H-C0 of its contribution D-C0 as proof of receipt. In addition, the output or outputs of the first level-3 transaction TX-C contain a hash value IH-A of the non-leaf node shown at level 3 in Figure 18B, which represents the overall contribution of all the lower authors CA of the first group. This may be referred to below as the "summary hash", and has the effect of explicitly (directly) encoding that non-leaf node in the set of transactions.

[0095] Finally, the first level-2 transaction TX-C contains the first level-3 top author's proof of his own contribution D-C0 in the form of discretionary signature DS-C0. As before, this is generated by applying a signing function to the private key counterpart of his contribution D-C0 and public key P-C0.

[0096] Returning briefly to step 1902, a second single-group use transaction TX-B is created in a similar manner by a second subordinate author group CB, that is, in this case there are three subordinate authors who created three initial transactions TX-B0 to TX-B2, so that the second group use transaction TX-B has three inputs, each using a different one of the initial transactions.

[0097] Although not explicitly shown in Figure 19A, each of the five inputs of the first group spend transaction TX-A and each of the three inputs of the second group spend transaction TX-B contain a valid transaction signature generated using the private key counterpart of the public key specified in the output of the initial transaction they spend. So, for example, the first input of the first group spend transaction TX-A contains a transaction signature that uses the private key counterpart of the public key P-A0 in the output of the initial transaction TX-A0 to sign the output of that transaction TX-A, etc.

[0098] The second group usage transaction TX-B similarly includes a discretionary signature for each subordinate author in the second group CB (generated in the same manner and denoted by references DS-B0 to DS-B2), at least one usable output locked to the public key of the second level 3 senior author C-D0, i.e., the subordinate author's direct supervisor in the second group CB, and a double hash puzzle for each of the contributions D-B0 to D-B2 of the second subordinate author group CB, denoted by references H2-B0 to H2-B2.

[0099] Returning to step 1904, the direct overseer C-D0 of the second subordinate author group CB generates a second level-3 transaction TX-D having at least one input that uses a usable output of the second group transaction TX-B, and thus includes a valid transaction signature generated by signing the output(s) of the second level-2 transaction TX-D using the private key counterpart of the public key P-D0 specified in the usable output of the second group transaction TX-B, and further includes a solution to the double-hash puzzle in the form of each of the single hashes of the second subordinate author group CB's contributions D-B0, ..., D-B2, denoted by reference characters H-B0 H-B2, respectively.

[0100] In contrast to the first level-3 use transaction TX-C, the second level-3 use transaction TX-D has at least two usable outputs. This reflects the fact that the second level-3 top author C-D0 is overseen by not one but two top authors C-F0, C-F1. The first of these usable outputs is locked to the public key P-F0 of the second level-2 supervising author C-F0, and the second usable output is locked to the public key P-F1 of the third level-2 supervising author C-F1. Each of those usable outputs contains a double-hash puzzle H2-D0 on the contribution D-D0 of the second level-2 top author C-D0, which must be solved to unlock that output. Instead of having two usable outputs, transaction TX-D can have a single usable output locked to the public keys of both P-F0 and P-F1. This can be seen, for example, in the use of the 2-of-2 CHECKMULTISIG opcode with operands P-F0 and P-F1, together with the double-hash puzzle H2-D0.

[0101] Finally, the second level-3 transaction TX-D includes in one or more outputs a hash value IH-B of a non-leaf node at level 3 in the generalized hash tree 1820 of FIG. 18B, which represents the aggregate contribution (a summary hash using the terminology above) of the second lower-level author group CB, and also a proof of the contribution of the second level-3 higher-level author in the form of a discretionary signature DS-D0 generated as described above.

[0102] The remaining steps of the method are shown in Figure 19B.

[0103] Up until now, there have been two separate "branches" of transactions, reflecting the two branches in the contributor hierarchy. However, in the next step of the method, step 1906, these two branches are "merged" to reflect the fact that all three of the top level 1 authors, C-E0, C-F0, and C-F1, are overseen by the same author, the lead editor C-G0. That is, using the terminology above, all three of the top level 1 authors are "siblings" in the hierarchy whose "parent" is the lead editor C-G0. Thus, in step 1906, a single level 2 usage transaction, TX-EF, is created by all three of these authors. In this example, the level 2 usage transaction, TX-EF, has three inputs: one that uses the available output of the first level 3 transaction, TX-C, and the other two that use the two available outputs of the second level 3 usage transaction, TX-D. The first input includes a valid transaction signature TS-E0 generated using the private key counterpart of the public key P-E0 specified in the output of the first level-2 transaction TX-C, and further includes a receipt of the contribution D-C0 of the first level-2 author C-C0 in the form of a single hash H-C0 of said contribution. The second and third inputs include valid transaction signatures TS-F0 and TS-F1 generated using the private key counterparts for the public keys P-F0 and P-F1, respectively, and each includes a receipt of the contribution D-D0 of the second level-3 author in the form of its single hash H-D0. If TX-D has a single usable output with two (2-of-2) CHECKMULTISIG operands, then the level-2 transaction TX-EF has a single second input containing the two valid transaction signatures TS-F0 and TS-F1 and the receipt H-D0 in place of the second and third inputs.

[0104] Level 2 transaction TX-EF has one or more outputs, including at least one usable output locked to the public key P-G0 of level 1 lead editor C-G0, which further requires receipt proofs in the form of double-hash puzzles H2-E0, H2-F0, and H2-F1 for each of the three contributions of the three level 2 top authors.

[0105] Additionally, the one or more outputs include hash values ​​IH-C and IH-D (summary hashes) of the non-leaf nodes at level 2 of the generalized hash tree of FIG. 18B, and for each of the level 2 authors C-E0, C-F0, and C-F1, a proof of the contribution of that author in the form of a respective discretionary signature DS-E0, DS-F0, and DS-F1 generated as described above. As step 1908, lead editor C-G0 creates a level 1 transaction TX-G, which effectively consumes the output of the level 2 transaction TX-EF and thus must include a valid transaction signature TS-G0 and three receipt proofs in the form of single hash values ​​H-E0, H-F0, and H-F1 of the level 2 author contributions D-E0, D-F0, and D-F1. Additionally, the one or more outputs include hash values ​​of the level 3 leaf nodes IH-E and IH-F, and a proof of the lead editor's contribution in the form of a discretionary signature DS-D. The lead editor's contribution is the final work D, which is the contribution for which the discretionary signature DS-D is generated.

[0106] Level 1 transaction TX-G has a spendable output locked to the copyright authority's private key, denoted P*.

[0107] In step 1910, the Copyright Authority creates a final transaction TX*, which consumes the spendable output of the level-1 transaction TX-G. It therefore contains a valid transaction signature TS*, generated by signing the output of the final transaction TX* using the private key counterpart to the public key P* specified in the level-1 transaction TX-G. Further details of the role of the Copyright Authority in one example are described below.

[0108] Note that the double hash value of each leaf node, commonly denoted by a code of the form H2-xx, is encoded by a double hash puzzle in the associated spendable output, and that this puzzle must be solved in order to spend that output. Furthermore, this value may be replicated elsewhere in the transaction's outputs, as described below.

[0109] In the above, the same private key used to generate the transaction signature (which is also referred to herein as a non-discretionary signature) is used to generate the discretionary signature, but this is not required. In fact, the discretionary signature can be generated using any private key, and indeed any signature algorithm, which may or may not be the same as the signature algorithm used to generate the transaction signature. For example, the transaction signature may be generated using ECDSA, and the discretionary signature may or may not be generated using ECDSA.

[0110] Further details of an exemplary implementation of the collaborative authentication protocol are provided below. This exemplary implementation utilizes what is referred to herein as a "generalized hash tree." The principles of generalized hash trees are first described to provide relevant context.

[0111] 2. Hash Tree The concept of a hash tree as a data structure was introduced by Ralph Merkle in 1979. Since then, hash trees have been widely used for applications including representing sets of transactions in blocks of a blockchain and recording state changes in version control systems such as Git version control.

[0112] The terms "hash tree" and "Merkle tree" are commonly used to refer to the same type of data structure. Where it is deemed useful to make a distinction between the underlying data structure and the selected mathematical formulation, the following discussion may use the term hash tree to refer to the underlying data structure, and the term Merkle tree to refer to the hash tree, in combination with an indexing scheme for indexing the nodes of the hash tree, and a set of nodal formulas for constructing the hash tree according to that indexing system.

[0113] A Merkle tree is generally treated as a binary data structure containing nodes and edges. Nodes are represented as hash digests (hash values), and edges are generated by applying a one-way function (commonly a cryptographic hash function) to pairs of connected nodes to generate parent nodes. This process is repeated recursively until a single root hash value (the root node) is reached.

[0114] Merkle trees have been implemented as binary trees, ternary trees, or more commonly as k-ary trees, where k is a common branching factor used throughout the tree. The fact that the branching factor is reliably consistent throughout Merkle trees is a widely accepted feature of such trees. Another common feature is that data blocks are only inserted at the lowest level of the tree (i.e., the level furthest from the root). Data structures with these constraints are sometimes referred to herein as "classical" hash (or Merkle) trees.

[0115] However, this disclosure has recognized applications where it is advantageous to have greater flexibility in constructing Merkle trees than is possible with these common features. Thus, a highly generalized treatment of Merkle trees is provided, resulting in protocols for constructing and manipulating what are referred to herein as "generalized" hash trees. These generalized structures inherit many of the properties of classical Merkle trees, while gaining additional flexibility by removing the constraints of both having a consistent branching factor and only inserting leaf nodes at the base layer.

[0116] The term "schema" may be used here to refer to the set of constraints imposed on a data structure. For a classical hash tree, these constraints are summarized above and described in more detail below.

[0117] This disclosure provides a novel schema for constructing a generalized hash tree, the details of which are described below.

[0118] This disclosure also provides a novel indexing scheme for assigning indexes to nodes of a generalized hash tree. A hash tree indexed according to this indexing scheme may be referred to as a generalized Merkle tree.

[0119] Embodiments of the present disclosure are described in detail below. First, a more detailed description of classical hash trees is provided below as a context for the described embodiments.

[0120] 2.1 Classical Hash Tree A common way to represent large amounts of data in an efficient and less resource-intensive way is to store it in a structure known as a hash tree, where hash is taken to mean the digest of a one-way cryptographic hash function such as SHA-256.

[0121] A typical hash function takes an input of arbitrary size and produces an integer in some range. For example, the SHA-256 hash function gives a 256-bit number as its output hash digest (hash value).

[0122] In general, a hash tree is a tree-like data structure that contains "internal" and "leaf" nodes connected by a set of directional edges. Each leaf node represents a cryptographic hash of a portion of data (a data block) that is "stored" in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes). A child node of a "parent" node is any node that is directly connected to the parent node by a directional edge. The root node of a hash tree can be used to compactly represent a large set of data and can be used to prove that any of the said pieces of data corresponding to the leaf nodes are in fact part of the set. The root node is the single node to which all other nodes are directly or indirectly connected.

[0123] In accordance with terminology used in the art, this disclosure may refer to data being "stored" in a hash tree. However, due to the one-way nature of hash functions, it is recognized that the data is not recoverable from the hash tree itself (indeed, this is one of the advantages of hash trees). Rather, the hash tree can be used to verify data blocks in the manner described below. Thus, when this disclosure refers to data being stored or included in a hash tree or the like, it will be understood that this means that the data is represented in the hash tree in the manner described below, and does not mean that the data is recoverable from the hash tree.

[0124] Many applications use binary hash trees, where each non-leaf node has exactly two child nodes and the leaf nodes are the hashes of blocks of data. For example, the Bitcoin blockchain uses a binary hash tree implementation to compactly store all transactions for a block. The root hash is stored in the block header to represent the full set of transactions contained in the block.

[0125] Figure 3 shows a simple binary hash tree, where leaf nodes are represented as open circles, non-leaf nodes are represented as filled circles, and edges are represented as line segments between pairs of nodes. Each node is represented as a hash value that is calculated as follows:

[0126] The structure of a binary hash tree is shown in Figure 3, where the arrows represent the application of a hash function, the open circles represent leaf nodes, and the closed circles are used for both internal nodes and the root. This hash tree stores a set of eight parts D1…D8 of data by hashing each part and concatenating the resulting digest pairwise with H(D1)||H(D2), …, H(D7)||H(D8), where the “||” operator represents the concatenation of two strings of data. The concatenated result is then hashed, and the process is repeated until a single 256-bit hash digest remains (the Merkle root) as a representation of the entire data set.

[0127] As an example, nodes denoted by reference numerals 300 and 301 are leaf nodes representing data blocks D3 and D4, respectively. Thus, the hash values ​​of nodes 301 and 302 are H(D3) and H(D4), respectively. Nodes 300 and 301 are called "sibling nodes" because they have a common parent node denoted by reference numeral 302. The hash value of parent node 302 is H(H(D3)||H(D4)). Next, node 302 is shown to be a sibling node of node denoted by reference numeral 304 because these nodes have a common parent node 306, which has a hash value equal to the hash of the concatenation of the hash values ​​of its child nodes 302, 304.

[0128] 2.2 Merkle Tree Merkle trees are the original implementation of hash trees proposed by Ralph Merkle in 1979. [Non-Patent Document 1] RC Merkle, Stanford University, (1979), Secrecy, Authentication, and Public Key Systems (Merkle thesis).

[0129] A Merkle tree is typically interpreted as a binary hash tree.

[0130] In a Merkle tree, each node in the tree is given a pair of indices (i,j), denoted as N(i,j), where the indices i,j are simply numerical labels associated with a particular position in the tree.

[0131] An important feature of Merkle trees is that the construction of each node is governed by the following formula (these formulas have been adapted and simplified from Merkle's paper):

number

[0132] A binary Merkle tree constructed based on these formulas is shown in Figure 4. The case i=j corresponds to a leaf node, which is simply a node that holds the data D i We can see that the hash of the i-th block of i≠j corresponds to an internal or root node, which is generated by recursively hashing and concatenating its children in the tree until that particular node or root is reached.

[0133] For example, node N(1,4) is constructed from four data blocks D1, ..., D4 as follows:

number

[0134] A binary tree is shown as an example, but it is possible to build a ternary tree, a quad tree, or a K-ary Merkle tree. It is possible, where K is the branching order of the tree, also called the branching factor.

[0135] In general, the core properties and paradigms common to all Merkle tree implementations can be summarized as follows: 1. Common branch order K - All non-leaf nodes have a common branch order. In the case of a binary Merkle tree, every internal node and the Merkle root has exactly two children. 2. Leaf node position - All leaf nodes are uniformly located at the bottom of the tree. This means that a data block can only be injected into the tree at the same base layer.

[0136] These properties are artifacts of Merkle trees being designed to store lists of data blocks in an optimally efficient manner. However, this design, while it serves e.g. well for cryptographic signature schemes and storing blockchain transactions, is subject to constraints that make it suboptimal for other uses. As a consequence of property 1, to store N data blocks in a Merkle tree with branching factor K, the tree must have a branching factor of K M ≥ N leaf nodes. This is beneficial in that the depth of the tree grows logarithmically with respect to the total storage requirements. However, this also means that M >N, the Merkle tree contains an additional N'=K M This also means that Merkle trees must be "padded" with -N leaf nodes, which means that Merkle trees often contain extra data that is of no interest to users of the tree.

[0137] Furthermore, property 2 means that it is not possible to add or inject blocks of data at any level of the tree other than its base, making it very difficult to reflect any hierarchy or structure about the dataset within the Merkle tree itself.

[0138] Merkle Proof The main function of a Merkle tree in most applications is to store some block of data D i Let D∈{D1,…,D N The purpose of this paper is to make it easy to prove that a given data block is an element of the set of . i Given a block, this can be treated as an "existence proof" of that block in the set.

[0139] The mechanism for such proofs is known as Merkle proofs, which prove that for a given block of data D i and deriving a set of hashes known as a "Merckle path" for a Merkle root R. A Merkle path for a block of data is simply the minimal list of hashes needed to reconstruct the root R by repeated hashing and concatenation, and may be referred to as the "authentication path" for the block of data.

[0140] method Given a Merkle root R and a data block D1 to be “validated”—“validated” in this context means that the data block D1 is a part of the set D∈{D1,…,D N} (i.e., the set of data blocks from which the hash tree is built) -- data block D1 is verified as follows: Data block D1 is considered as an example. This proof can be performed to determine, for any given data block, whether it corresponds to one of the data blocks used to build the hash tree.

[0141] Referring to FIG. 5, to verify data block D1, a Merkle proof is performed as follows: i) Obtain a Merkle root R from a trusted source. ii) Obtain a Merkle path Γ from the source, where Γ is a set of hashes: Γ={N(2,2),N(3,4),N(5,8)} It is. iii) Compute the Merkle proof using D1 and Γ as follows: a. Hash the data block: N(1,1)=H(D1) ("Reconstructed Leaf Hash" 502) get. Concatenate with bN(2,2) and hash: N(1,2)=H(N(1,1)||N(2,2)) get. Concatenate with cN(3,4) and hash: We get N(1,4)=H(N(1,2)||N(3,4)). Concatenate this with dN(5,8) and hash it to reconstruct the root: We obtain N(1,8)=H(N(1,4)||N(5,8)), R'=N(1,8) (the "reconstructed root hash") e. Compare the calculated root R' with the root R obtained in (1): If I.R'=R, then the existence of the tree, and therefore D1, in the dataset D is established. II. If R' ≠ R, then the proof fails and D1 is not established as an element of D.

[0142] This is an efficient mechanism for providing proof of existence of some data as part of a dataset represented by a Merkle tree and its root. For example, if the data corresponds to a blockchain transaction and the root is publicly available as part of the block header, it is possible to quickly prove that the transaction was included in that block.

[0143] The process of verifying existence as part of an exemplary Merkle tree is shown in Figure 5. This shows that performing a Merkle proof for a given block and root is effectively a traversal of the Merkle tree "upwards", using only the minimum number of hash values ​​required.

[0144] 2.1.2 Tree structures in graph theory A hash tree or Merkle tree may be interpreted in the context of graph theory. A hash tree contains vertices or nodes of data (hash values) and edges connecting the nodes formed by the hash of multiple linked vertices. More specifically, in graph theory, a hash tree is considered to have the following important properties: Directed - Edges between nodes are formed by computing a one-way hash function that can only be run in one direction. This means that all edges in a hash tree are directed, which means that the tree is. Acyclic – There are no cyclic paths in a hash tree structure. Graph-hash trees can be classified as graphs because they contain vertices and edges connecting the vertices.

[0145] The combination of all three of these properties means that a hash tree or Merkle tree meets the definition of a directed acyclic graph (DAG).

[0146] A directed graph is called weakly connected if replacing its directed edges with undirected edges forms a connected graph. A hash tree meets this criterion, so it is also a weakly connected DAG.

[0147] A "rooted tree" is defined as a tree in which one vertex or node is identified as the root of the tree, and if the rooted tree has an underlying directed graph, it is called a directed rooted tree. Furthermore, in a directed rooted tree, all edges either point away from the designated root (arborescent) or point towards the designated root (antiarborescent).

[0148] This disclosure recognizes a hash tree or Merkle tree as an example of the latter, i.e., an anti-arborescent directed rooted tree, whereby all of its edges are constructed by hashing the vertices "towards" the root.

[0149] 3. Generalized Hash Tree Protocol The described embodiments provide a generalized hash tree data structure that is explicitly defined to have the following properties: Hierarchical position of leaf nodes - Leaf nodes can be placed at any level of the tree below the root hash. This allows you to inject data at different levels of the hash tree that reflect the external hierarchy of the data. Any number of children - Each node can have any number of children (or "in-degree"), which may include any number of interior child nodes and any number of leaf child nodes. Variable branching factor - the branching factor for interior nodes, which gives the ratio of the number of children (in-degree) to the number of parents (out-degree), does not have to be common throughout the tree.

[0150] The combination of these properties allows the construction of hash trees that can represent a data set with a second layer of hierarchy overlaid on it, while retaining the core functionality of the tree, namely the ability to efficiently verify a given block of data using the same Merkle proof principles described above. These core features are that the tree must be able to represent the entire data set at a single hash value, the root (i.e., all nodes must be directly or indirectly connected to a common root node), and that it must be possible to perform a Merkle existence proof on any single block of data in the set, regardless of its position in the hierarchical structure.

[0151] An example of a generalized hash tree structure is shown in Figure 6. This example shows 14 data blocks D1-D2 that are inserted at various levels into the hash tree. 14 This contrasts with traditional Merkle tree structures where all of this data injection happens at the bottom level of the tree.

[0152] Generalized Hash Tree Rules A hash tree that achieves the desired properties can be constructed according to the following set of rules. Using the terminology above, this set of rules constitutes the "schema" according to which any generalized hash tree may be constructed: 1. Node - A node can have at most one parent and any number of children. Nodes are generally either leaf or non-leaf nodes, but can be divided into three general categories: A root node is defined by having no parent. b. An intermediate node is defined by having at least one parent and at least one child. c. A leaf node is defined by having no children. Note that (a) and (b) are both examples of non-leaf nodes, while (c) is a leaf node.

[0153] 2. Edges - Edges are created by hashing nodes connected with their siblings in a particular order. Edges between parents and children are created by hashing all of the children of a parent connected in order. Given a parent P and four children C1, C2, C3, and C4, we can create the following edges:

number

[0154] 3. Any Number of Children - There is no limit to the number of children any non-leaf node may have. Leaf nodes, by definition, have no children (see rule 1).

[0155] 4. Leaf Node Location - There is no restriction on how deep a leaf node can be placed in the hash tree. Hence, a leaf node can exist at any level of the tree.

[0156] To provide additional robustness against "second preimage attacks", additional rules may be introduced into the schema.

[0157] 5. Leaf nodes are distinguishable from non-leaf nodes - All leaf nodes are explicitly distinguishable from non-leaf nodes, for example by prepending a predefined prefix (e.g., 0x00) to the hash value of each leaf node.

[0158] A second preimage attack refers to the situation where an attacker manages to discover a preimage of a hash value (i.e., the data block that hashes to that value) without knowing the original preimage from which the hash value was calculated.

[0159] Applying the above terminology, a generalized Merkle tree has additional rules related to indexing and node expressions, which can be formulated as follows: 6. Indexing System - All nodes must be uniquely labeled according to a common indexing system (see 3.1.1).

[0160] 7. Golden Rule - When labeling a set of sibling nodes, non-leaf siblings are labeled before leaf siblings (see 3.1.2).

[0161] 8. Node Expressions - All nodes must conform to the node expressions of the generalized hash tree. These expressions rely on the structure provided by the indexing system, allowing the hash value of every node in the tree to be built recursively from its children (see 3.3).

[0162] NOTE: Rules 5-8 are optional with respect to generalized hash trees; that is, only rules 1-4 define the basic properties of generalized hash trees. Rule 5 is an optional implementation feature that provides additional security, and rules 6-8 define a particularly convenient set of node expressions for building generalized hash trees, and the indexing schemes that those node expressions employ (note that, while convenient, other indexing schemes and formulations of node expressions are nevertheless feasible).

[0163] 3.1.1 Indexing Systems Figure 7 shows the generalized hash tree of Figure 6, where all nodes are given alphabetical references A through U.

[0164] To create a generalized hash tree, such as the example shown in Figure 5 (see 3.2), the indexing and notation system described above allows each node to be easily identified and its position in the hash tree clearly indicated.

[0165] The basic notation used to represent nodes in a generalized hash tree is

number

[0166] The term "index tuple" refers to a node

number

[0167] A subscript index follows a path down the tree from the root node to the node in question. This path can be categorized into three types of subscript indexes: Root Index - The null index, '0', is always the first subscripted index, meaning that each node in the tree is connected to the root by a finite number of edges. The root node is labeled N0. Intermediate Indices - A node at level m always has m-2 intermediate indices (null if m≦2). These indices represent the path of nodes from the root to the parent of the node in question. These indices are denoted i0,…,i m-2 It is written as follows.

[0168] Sibling Index - The final subscript index of a node indicates its position with respect to its siblings.

[0169] Each node in a generalized hash tree has exactly m+1 indices: one root index (0), m-2 intermediate indices (i0,…,i m-2 ), and one sibling index (j).

[0170] Also note that all indices are non-negative integers, starting from zero and increasing.

[0171] For ease of explanation, when discussing a blockchain-based implementation of the Generalized Hash Tree method, the internal nodes are sometimes referred to as "intermediate nodes." Hence, these two terms are considered equivalent and interchangeable.

[0172] Note that because the root index is always zero, the root index does not need to be explicitly encoded when the index is computed (i.e., the root index may be implicit, in that it is not actually stored as a value when the index tuple is computed).

[0173] golden rule The indexes are assigned according to the above indexing system in accordance with the Golden Rule (GR), which is stated as follows: When determining the sibling index j for the GR-n sibling nodes, values ​​j=0, …, j=n-1 are assigned as follows: 1. From left to right, and 2. Ensure that intermediate siblings are allocated before leaf siblings.

[0174] Nodes are named from top to bottom and left to right: top to bottom locates the branching paths and thus the parent of a node, and right to left locates the child of said parent relative to its siblings.

[0175] Hashing As shown in the node formula, the process of hashing has two implications in generalized hash trees. Any data block D in the tree, at any level, must be hashed by H to form a leaf node. 2 (D) is double-hashed (its value is the "double-hash" value). However, whenever multiple leaves and / or interior nodes are combined to form a new interior node in the tree, they are concatenated and hashed only once, i.e., H(Leaf1||Leaf2) (resulting in a "single-hash" value).

[0176] A double hash provides the benefit that a single hash value (i.e., obtained by applying a hash function only once to a data block, referred to as single hashing) can be revealed to provide proof of possession or receipt of the underlying data block, which can be verified with respect to a generalized hash tree, without revealing the data block itself. This is beneficial when hash trees are used to represent sensitive data. More generally, the term "multiple hash" refers to a hash value obtained by hashing a data block more than once (i.e., hashing the data block and then hashing the result, at least with the same or different hash functions).

[0177] Alternatively, for non-sensitive data, a single hash may be sufficient (i.e., the hash value of each leaf node may be a single hash of the underlying data block). The generalized hash tree and method are not limited to a single hash algorithm or function, but merely require that a cryptographically secure function be used.

[0178] Generalized Hash Tree Indexing Figure 7 shows an example of the generalized hash tree structure of Figure 6, with the indexing convention adopted: Root Node − There is only one root node in a hash tree, which in this case is labeled A. For example, A is labeled N0. Intermediate Nodes - Nodes B, C, E, G, J, L are all intermediate nodes and act as hash summaries of the subtree below them. For example, B is N 0,0 is labeled as For example, K is labeled N0,0,0,1. etc. Leaf Nodes − Nodes D, F, H, I, K, M, N, O, P, Q, R, S, T, U are all leaf nodes and contain the double hash of the data block. For example, F is N 0,0,1 is labeled. For example, P is N 0,0,0,0,2 is labeled. For example, U is N 0,1,0,0,2 is labeled. etc.

[0179] A complete list of labels for all nodes in Figure 7 is shown in Table 1. [Table 1]

[0180] This table is a complete representation of the hash tree shown in Figure 6. Such a tabular representation can be used to materialize the generated hash tree data structure, for example in an off-chain system (see below).

[0181] Node Expression A notation for a node that can have any number of children, n

number

[0182] Function G α is defined as follows to compute the concatenated sum over all elements α, or at least the elements corresponding to α in the range 0≦α≦n-1 (note that Σ denotes concatenation, not summation, over the defined range):

number

number

number

[0183] Since the node whose value is being calculated has m+1 indices, its children must necessarily have exactly m+1 indices, so that the first m+1 indices of the children are the same as the parent's indexes. The dummy index α used for the summation therefore represents the additional sibling index (the m+2th index) of each child of the node in question.

[0184] Recursion This principle of adding an additional index at each incremental increase in the level of a node allows the value of a node to be expressed using a concise recursive expression.

[0185] The Greek letters (α,β,γ,…,ω) are used to represent the "dummy" (sibling) indices that represent this recursion, to avoid confusion with the Latin letters (i,j) used to represent the original m+1 indices of the node to be computed.

[0186] To see how this recursion works with the formula above, consider a node with many generations of descendants.

number

[0187] Then the formula for the node's value can be written as:

number

[0188] Note that the upper bound on the sum changes for each offspring generation, reflecting the fact that different offspring may have different numbers of offspring.

[0189] For example, the dummy index α ranges from 0≦α≦n-1 to indicate that the node whose value is to be computed has n children, each of which may themselves have a different number of children (second generations with respect to the node), and the dummy index β ranges from 0≦β≦n'-1 to reflect this.

[0190] In summary, the expression for the value of a node can be written in a recursive manner that expresses how the value of a node is constructed not only from its children, but in fact all of its descendants:

number

[0191] Leaf and non-leaf nodes As outlined in Section 3.1, a generalized hash tree may contain leaf nodes (which have no children) and non-leaf child nodes (which have at least one child).

[0192] These two classes of nodes are fundamentally different: a leaf node represents the "end" of a particular tree branch, usually some data D, while a non-leaf node does not end a branch and may have many descendant generations.

[0193] This difference is reflected in the node expressions to ensure that leaf and non-leaf nodes are treated differently.

[0194] A leaf node with n=0 children

number

number

number

[0195] Division of the sum In Section 3.1.2, we established that the Golden Rule (GR) is that for a given set of sibling nodes, non-leaf nodes are labeled before leaf nodes.

[0196] The reason for this is to ensure that the recursive formula for a node consistently sums non-leaf children that must be expanded to their own children before their leaf children.

[0197] Conceptually, this aspect of GR allows the formula for the value of a node to be calculated by splitting the "sum" (or rather concatenation) into two "sums" over different limits, as follows:

number

[0198] The upper bound of the left sum represents the concatenation of all non-leaf children before the right sum concatenates all leaf children, which is the intended result of GR as previously formulated.

[0199] Node Expression In summary, a pair of concise expressions for the value of any given node in a generalized hash tree can be written as follows:

number

number

[0200] Calculating the node hash value Figure 8 shows the branches of a generalized hash tree and how a node (level m) is computed from its descendants.

[0201] Example nodes whose values ​​are calculated

number

[0202] Black circles are used to represent non-leaf nodes and white circles are used to represent leaf nodes.

[0203] In the steps shown below, the node values ​​are calculated using recursive node expressions. 1. Write the nodes using connected sums:

number

number

number

number

number

number

number

number

[0204] Generalized Hash Tree Extensions A key property of generalized hash trees is that new data can be added to the tree at any time after its initial creation.

[0205] For example, if a generalized hash tree is used to represent a stable version of a document at a point in time, then at any point in the tree, a new data leaf H 2 (D new ), it is easy to make additional changes at some later point.

[0206] As an example, FIG. 9 shows an additional data packet D new 9 shows a generalized hash tree extended by 902. The nodes of the original tree that need to be updated are shown as checkered circles, denoted by reference numerals 902 and 904, respectively, with node 904 being the root node.

[0207] Depending on where and at what level in the tree new data is inserted, certain nodes will have their unique hash value changed and must be recalculated, allowing changes to propagate upwards from any position in the tree, reflecting the hierarchical structure of the changes after the fact.

[0208] For the avoidance of doubt, in the context of blockchain, references to changes or modifications of a hash tree committed to the blockchain do not imply any modification of data immutably recorded in the blockchain. Rather, a set of rules can be constructed to interpret different versions of a hash tree stored in the blockchain (e.g., a simple rule may be that the latest version is interpreted as overwriting some previous version). For example, a new transaction can be written to the blockchain, thus extending the hash tree, and the latest "version" of the data can be interpreted according to its recency as it appeared on the blockchain. Versioning can be resolved both between blocks (i.e., which transaction was in the latest block mined) and within blocks (i.e., which transaction appeared "highest" / "lowest" if in the same block).

[0209] Calculating the Merkle Existence Proof An important advantage of generalized hash trees is that proofs of existence can be computed using Merkle tree proofs (see 2.1.1) with a level of efficiency comparable to that of classical Merkle trees.

[0210] Figure 10 shows a schematic of how a Merkle proof is performed for a given (arbitrary) block of data. As in Figure 5, the nodes that belong to the authentication path for that block of data are enclosed in a dotted line.

[0211] The reconstructed root hash 1004 is calculated by double-hashing (comparable to root hash 502 in FIG. 5) the data block D3 to be verified (in this case), and the reconstructed root hash 1004 is calculated by applying successive concatenation and hash operations to the reconstructed root hash 1002 and the hash values ​​of the nodes of the authentication path according to the edge structure of the tree to calculate the reconstructed root hash 1004 (comparable to R' in FIG. 5), which can be compared with the hash value of the root node to verify the data block D3.

[0212] Figure 10 illustrates the fact that to perform a Merkle proof for a generalized hash tree, the same principles apply as for classical binary or non-binary Merkle trees: the Merkle path is still only the minimal set of hashes needed to reach the root node and compare the reconstructed root hash 1004 with its known value.

[0213] In the example shown in Figure 10, a Merkle proof (authentication path) is calculated for a block of data D3 whose hash (which, as mentioned before, is preferably a double hash of block D3, at least for sensitive data) value is given by node P. To verify that this data block is an element of the data set represented by the tree, the hash values ​​of nodes N, O, Q, R, K, F, C, D are needed in order.

[0214] A reconstructed hash value for node J is calculated by concatenating and hashing the reconstructed root hash 102 for node P with its siblings. This process is repeated until the root node A is reached, which should equal the expected Merkle root hash value (i.e., the hash value of the root node).

[0215] Several interesting properties emerge when examining Merkle existence proofs used with generalized hash trees, compared to proofs using classical Merkle trees.

[0216] Property 1: Number of hashes required See Section 2.1.1 above, and consider such a binary classical tree of depth M, representing N blocks of data. To perform a Merkle existence proof on any one of these data blocks, we always need M=log2N hash values ​​for the proof to be successful.

[0217] However, for the proposed generalized trees, this is not the case: the number of hash values ​​needed to compute an existence proof varies with (i) the depth of the node, and (ii) the number of siblings of the node. This means that while a Merkle proof may require more hash values ​​(and potentially more computation) than a classical binary tree, it may also require fewer hash values ​​(and potentially less computation).

[0218] For example, consider the hash tree in Figure 10. This hash tree stores 14 data blocks, so its binary counterpart has N=16 leaf nodes (2 null or duplicate values), and a Merkle existence proof for any of the data blocks requires exactly 4 hash values.

[0219] However, the hash tree in Figure 10 is such that proving the existence of nodes C and D requires only two values ​​(fewer than a binary tree), but eight for nodes N, O, P, Q, or R.

[0220] Figure 11 shows a comparison of the varying number of hashes required for a proof in generalized and classical Merkle tree construction. This demonstrates the contrast in the number of hashes required between generalized and classical Merkle tree construction.

[0221] Feature 2: Dual purpose certification In a classical Merkle tree, all leaf nodes are at the bottom of the tree (m=M), so every Merkle proof requires the same number of hash calculations.

[0222] In other words, the number of "concatenate and hash" operations performed as part of a Merkle proof will be the same for each data leaf: for a tree of depth m=M, with the root node at m=0, each Merkle existence proof requires exactly M such operations.

[0223] These operations are represented by arrows in Figure 11. Each arrow represents an operation that concatenates a node with all its siblings and hashes them to obtain the result.

[0224] The number of these operations (arrows) is a function only of the depth of the leaf node at which the Merkle existence proof is being performed, so in a classical Merkle tree, every proof requires M operations, i.e. all leaf nodes are at the bottom of the tree.

[0225] However, generalized Merkle trees are specified so that leaf nodes can exist at any level in the tree, which means that the number of operations involved in a Merkle proof can in practice range from 1 up to M.

[0226] This difference is clear in Figure 11, where every Merkle proof in the tree on the left (classical) requires exactly m = M = 4 operations, while in the tree on the right (generalized) the number of operations varies from 4 for the lowest level data packet to just 1 for data packet D8.

[0227] The very fact that the number of operations for a Merkle proof changes in the case of generalized hash trees means that these Merkle proofs can now be thought of as dual purpose: Purpose 1: Merkle proofs of existence, which allow one to show that a data packet is an element of a larger dataset, without possessing the complete dataset. Objective 2: Merkle existence proofs, which allow one to show that a data packet exists at a particular level in a hierarchical structure of data that belongs to a set.

[0228] Only the first of these objectives applies to standard Merkle existence proofs implemented using classical Merkle trees, while both apply to Merkle proofs performed on generalized hash trees.

[0229] This is because Merkle proofs for generalized hash trees not only achieve the same set membership proof as the classical case, but the number of operations used in performing the proof reveals the height (level) to which the data is included in the hash tree.

[0230] If the data leaves form a hierarchical structure, then a Merkle proof can be used to show that a datum was inserted into the tree at a given level m, i.e., if the proof involves exactly m "concatenate and hash" operations, and thus both its set membership and its hierarchical position within that set.

[0231] 4. Exemplary Blockchain Encoding 12A shows a schematic block diagram of a data structure in the form of a generalized hash tree (interchangeably referred to herein as a generalized Merkle tree). The generalized hash tree is designated by reference numeral 1200 and is shown to include a number of nodes and edges constructed in a manner that takes advantage of the additional flexibility afforded by the generalized hash tree schema. It will be understood that this is merely an illustrative example and that the generalized hash tree can take any form that meets the above requirements.

[0232] Each node in the generalized hash tree 1200 has a level, represented by a circle, defined by the number of edges connecting it to a common root node, N0. As in all generalized hash trees, there is a single common root node, N0, to which all other nodes are directly or indirectly connected. The root node, N0, is the only node in the generalized hash tree with a level of zero.

[0233] The example in Figure 12A shows three level 1 nodes, i.e., three nodes that are directly connected to the root node N0 by a single directional edge from that node to the root node N0. Of these three level 1 nodes, two are shown to be non-leaf nodes and the third is shown to be a leaf node (a non-leaf node is any node that has at least one other node directly connected to it by a directional edge, which other node is referred to as the child node of that leaf node; a non-leaf node is any node that has no children in this sense).

[0234] A node that is indirectly connected to a parent node (i.e., a node that is connected to the parent node through one or more other nodes, and thus by two or more directional edges) may be referred to as a grandchild node of the parent node. Each such parent node may be referred to as an ancestor of its child or grandchild.

[0235] In the following description, commas from each index tuple are omitted unless necessary for disambiguation. Thus, for example, N 001 The notation N 0,0,1 is equivalent to

[0236] According to the indexing system described above, the two non-leaf nodes at level 1 are N 00 and N 01 The non-leaf nodes at level 1 are denoted by N 02 As shown in the figure.

[0237] Node N 00 is N 000 and N 001 In this example, these child nodes N 000 and N 001 are both leaf nodes with no children of their own. They are at level 2 in the generalized hash tree, and at level 1, 00 (Node N 000 and N 001 , and two directional edges (from that node to parent node N 00 and the edge to parent node N 00 It is connected to the root node N0 via a directional edge from to the root node N0.

[0238] Node N 01 At level 2, N 010 , N 011 and N 012 One of these children is itself a non-leaf node, and according to the indexing scheme above, has the lowest sibling index 0 (i.e., the non-leaf child is the node N 010 ). This node then becomes level 3 in the hash tree 1200, 0100 and N 0101Each of these level 3 child nodes has a parent node N. 010 and its own parent node N 01 , and is indirectly connected to the root node N0 via a total of three directional edges.

[0239] Node N 01 The remaining child nodes of, i.e., node N 011 and N 012 is a leaf node that has no children of its own.

[0240] Each leaf node is represented by an open circle, and each non-leaf node, including the root node N0, is represented by a filled circle. The hash value of each leaf node is a double hash of a data block, such as a document, file, etc. In general, the data block can be of any shape and simply refers to a preimage that is double hashed to obtain the leaf node's hash value. Each directional edge is represented by a solid arrow from the child node to the parent node.

[0241] Notation D i is the node N i Here, i denotes the index tuple of that non-leaf node. According to the above scheme, the length of the index tuple increases with the level of the node. So, for example, for node N, 0100 The data block hashed to calculate the hash value of D 0100 A leaf node N is denoted by 001 The data block is hashed to obtain the hash value of D 001Each such data block is represented in Figure 12A by a circle with a dotted outline (note: this is not a node of the generalized hash tree according to the definition used herein), and dotted arrows are used to represent the relationship between the data block and the corresponding leaf node (note: this is not an edge of the data structure according to the definition used herein). The double-hash relationship between a data block and a non-leaf node is expressed by the operator H 2 As shown by:

[0242] According to the above scheme, the hash value of each non-leaf node is a single hash of its preimage, which is the concatenated string formed by concatenating the hash values ​​of all its child nodes. So, for example, for node N 00 The hash value of is its child node, i.e., node N 000 and N 001 This is denoted in Figure 12A as H(...||...), noting that the concatenation goes over all possible child nodes.

[0243] The generalized hash tree scheme is flexible enough to allow a parent node to have a single child node, in which case the hash value of the parent node is the hash of the hash value of the single child node.

[0244] In the example of FIG. 12A, node N 00 Both of the children of node N are leaf nodes. However, the generalized hash tree schema also allows for non-leaf nodes whose children are a mixture of leaf and non-leaf nodes. 01 falls into this category, and its hash value is 010 and its leaf child node N 011 and N 012 It is the hash of the concatenation of the hash value of

[0245] Non-leaf child node N 010The hash value of its child node N 0100 and N 0101 (In this example, both are leaf nodes, so the corresponding data block D 0100 and D. 0101 (derived as a double hash of For a given leaf or non-leaf node N i The test value of is here H i However, elsewhere in this disclosure, the notation E i Note that is sometimes used to represent the hash value itself; the meaning should be clear in context.

[0246] Node N 0100 and N 0101 is node N 01 and N 01 A grandchild of node N. 000 and N 001 is the grandchild of the root node N0 only.

[0247] 12B and 13 show how the generalized hash tree 1200 of FIG. 12A may be implemented in a sequence of blockchain transactions.

[0248] Figure 12B shows the same generalized hash tree 1200, marked to indicate the levels of its constituent nodes. The data blocks are omitted from Figure 12B (and in any case, as noted above, they are not part of the generalized hash tree 1200, and the data blocks themselves are not stored in the blockchain in this example).

[0249] 13 illustrates a series of blockchain transactions that may be used to encode and store a generalized hash tree 1200 in a blockchain. In this example encoding, transaction Tx0 (the root transaction) is used to represent the root node N0.

[0250] In addition to the root transaction Tx0, one transaction is used to represent each set of sibling nodes, i.e., in this example, all nodes with the same parent node are grouped together in one transaction.

[0251] So, in this example, there are three child nodes of the root node N0, namely, N 00 , N 01 , and N 02 are encoded in a single transaction Tx1, which we call the level 1 transaction (reflecting the fact that these nodes are at level 1 in the tree).

[0252] There are two level 2 transactions, denoted by reference characters Tx2a and Tx2b, respectively. The first level 2 transaction, Tx2a, is 00 child node of, i.e., node N 000 and N 001 Similarly, the second level 2 transaction Tx2b is encoded by node N 01 3 child nodes of node N 011 , N 010 , and N 012 Encode the following.

[0253] A single level 3 transaction, Tx3, is 010 child of, i.e., node N 0100 and N 0101 Encode the following.

[0254] For each transaction Tx0-Tx3, the hash value of one or more nodes encoded by the transaction is included in one or more outputs of the transaction, i.e., each node hash value is directly encoded in the output of the transaction, and in the case of a transaction representing multiple nodes, the hash values ​​of those nodes may be explicitly included in the same or different outputs of the transaction.

[0255] In one implementation, the hash value is included in the unusable outputs of transactions Tx0 through Tx3, for example using OP_DROP or OP_RETURN.

[0256] As another example, the hash value may be included as a dummy operand in a check multi-signature operand (CHECKMULTISIG).

[0257] Each of the transactions Tx0 through Tx3 has at least one usable output (which may or may not include any node hash value). The directional edges of the generalized hash tree 1200 are encoded as usage relationships between transactions.

[0258] We start with a level 3 transaction Tx3, which has available output that is consumed by a second level 2 transaction Tx2b. That is, the input of the second level 2 transaction Tx2b contains a pointer to the output of the level 3 transaction Tx3, denoted by reference P2b. This pointer P2b not only encodes the consumption relationship between the second level 2 transaction Tx2b and the level 3 transaction Tx3, but also the consumption relationship between the level 2 non-leaf node N 010 (encoded in transaction Tx2b) and its two child nodes N 0100 and N 0101 We also encode two directional edges from,(both encoded in transaction Tx3).

[0259] A level-1 transaction Tx1 has at least two inputs, one of which consumes the output of a first level-1 transaction Tx2a and the other of which consumes the consumable output of a second level-2 transaction Tx2b. This captures the relationship between the level-1 nodes encoded in the level-1 transaction Tx1 and the level-2 nodes encoded in the level-2 transactions Tx2a and Tx2b. Tx2a consumes the consumable output of a level-1 node N. 00 The second level 2 transaction encodes all the children of node N of level 1. 01 Encode all child nodes of .

[0260] Finally, the root transaction Tx0 encodes the hash value of the root node, and the root transaction Tx0 has at least one input that uses a usable output of the level-1 transaction Tx1.

[0261] Depending on the implementation, the mathematical properties of cryptographic hash functions can be exploited to some extent to encode the structure of the hash tree. For example, for a transaction that contains multiple summary hashes, it is always possible to resolve each summary hash to a subset of the known set of nodes one level down, since there is only one subset of nodes whose concatenated hash is equal to the summary hash. Thus, even if a transaction contains multiple summary hashes, it is not essential to explicitly map those summary hashes to their respective subsets of child nodes at the next level down, since that information is already captured in their mathematical properties and can therefore be unambiguously inferred from the data. Relying on the mathematical properties of hash values ​​can be more memory efficient, since it reduces the amount of redundant data in the transaction.

[0262] However, as an alternative, some degree of redundant data may be introduced, which may be somewhat less memory efficient, but on the other hand may allow the hash tree to be reconstructed / interpreted using fewer computational resources (i.e. more computationally efficient). For example, the input script may decide that the nodes going into each summary hash should be marked with an appropriate (arbitrary) marker (e.g., OP_0 or any other arbitrary marker, e.g., <data>push), and may be further modified so that the ordering of the separated sets of nodes (i.e., left to right as they are drawn) corresponds to the ordering of the summary hashes.

[0263] For example, the summary hash H 00 and H 01 For Tx* the input unlock script may be read as follows:

number

[0264] 5. On-chain and off-chain representations The set of transactions Tx0-Tx3 in Figure 13 is an “on-chain” encoding, in that the transactions are submitted to a blockchain transaction node and may be mined into one or more blocks 151 at some point thereafter.

[0265] In this example, the indexes computed according to the above indexing scheme are not explicitly encoded in the blockchain transactions Tx0-Tx3; rather, the hierarchical relationships between the nodes of data structure 1200 are encoded as usage relationships between these transactions (which are then captured as pointers between these transactions). The indexing scheme may be implemented off-chain as part of the initial off-chain representation of data structure 1200, either before committing it to the blockchain or to reconstruct it off-chain after committing it.

[0266] FIG. 14 illustrates a highly schematic block diagram of an off-chain system 1400, which is shown to include one or more computers 1402 having access to an electronic storage device 1404 (off-chain storage) of the off-chain system 1400. Each computer includes one or more computer processors, such as a general purpose processor (CPU, GPU / accelerator processor, etc.), and / or programmable or non-programmable special purpose processors, such as FPGAs, ASICs, etc., for performing the described functions of the off-chain system 1400. The off-chain system 1404 is operable to communicate with at least one node of the blockchain network 101 to submit one or more of the transactions Tx0-Tx3 to the blockchain network 101 for recording the generalized hash tree data structure 1200 in the blockchain 150 for committing it to the blockchain 150, and / or to retrieve one or more of the transactions TX0-Tx3 therefrom for reconstructing the generalized hash tree data structure 1200 in the off-chain storage 1404.

[0267] In either case, a version of the generalized hash tree 1200 is maintained, at least temporarily, in off-chain storage 1404. To implement the above operations - either building a node tree according to the node's formula or validating a received data tree using Merkle proofs - each node of said version of the generalized hash tree 1200 in off-chain storage 1404 may be assigned an index tuple computed according to the above indexing scheme (rules 6-8 above).

[0268] 15, a version of the generalized hash tree 1200 stored in an off-chain storage 1400 (the off-chain version) is denoted by reference numeral 1200′. As shown, each of its nodes is associated with an explicitly computed index tuple 1402.

[0269] Alternatively or additionally, each index tuple may be explicitly encoded in the blockchain transactions TX0-TX3 themselves. This is by no means essential, but it may aid in interpreting the transaction data. For example, if all indexes are explicitly encoded, a processing entity may be able to figure out how all the data fits in the tree without knowing the "rules" in advance.

[0270] Collaborative Authentication Protocol Further details of the collaborative authentication protocol are now provided.

[0271] Introduction The intellectual property (IP) industry plays a key role in determining intangible assets, which account for approximately one-third of the value of consumer products. In 2017 alone, the number of patent and trademark applications filed worldwide was estimated at 3.2 million and 12.4 million, respectively, marking an eighth consecutive year of increase. This means that intellectual property (IP) can be an extremely valuable asset to individuals and organizations, and as such should be managed well.

[0272] The main considerations when creating an IP management system broadly fall into the following categories: 1. Assignment of rights to inventors and authors; 2. Invention disclosure; 3. Intellectual Property Licensing.

[0273] Assignment of authorship Traditionally, the assignment of authorship of a new creative work can be a complex procedure. Generally, the right to be named an inventor is automatically attributed to the original conceived person of a new idea. However, how this information is recorded and how it translates into the ultimate ownership of the IP is much less clear. For example, in large companies, the effective assignment of rights and authorship for new technologies and inventions is often done internally and according to the terms set out in the employment contract, i.e., "works made for hire". Especially in IP-productive businesses, this can lead to internal disputes over the status of named inventors and the chronological order of conception of a new work by different contributors, even if the intellectual property rights of "works made for hire" can belong solely to the employer.

[0274] Assignment of IP inventorship may also involve a third-party notary public, who authenticates and certifies signatures and authority, allowing inventors and creators to assert rights and authorship over their intellectual property. Despite serving a critical function in the industry, these notaries operate through cumbersome and expensive procedures.

[0275] The historical solution would be for inventors to adopt thorough "inventor's notes" or equivalent documents. However, these can exacerbate disputes if poorly implemented, and are typically mutable and tamper-evident if compromised.

[0276] It is desirable to develop a more efficient, cost-effective, and characteristically uncontroversial system for assigning authorship and ownership rights to intellectual property, especially when the technology to be protected is a complex work with multiple contributing authors.

[0277] Disclosure of the Invention The point at which an invention or other form of intellectual property is publicly disclosed has a bearing on whether it can be protected under intellectual property law. In most jurisdictions, when it comes to competing patent applications, the current paradigm is that the "first to file" application claims priority for the successful grant of a patent.

[0278] This means that inventors are given an incentive to document their inventions in sufficient detail and to file a patent application at the earliest opportunity. This process naturally creates a delay between the initial conception of a novel idea and its filing as a patent application.

[0279] The interim period between conception and filing poses risks to the inventor since a competitor may conceive and file an equivalent invention during this period, so it is advantageous for an inventor to have a mechanism for providing proof of the existence of his or her work prior to the final filing date.

[0280] Alternative blockchain-based solutions for IP management primarily aim to solve the isolated problem of providing immutable proof of existence, but these solutions generally fail to also establish and reflect a hierarchy of ownership and authorship of the IP itself.

[0281] Embodiments of the present application provide a new blockchain-based method for managing intellectual property that simultaneously addresses these issues by providing an intelligent structure for the works being protected.

[0282] Intellectual Property on the Blockchain The embodiments herein provide a method for using a public blockchain as both an IP registry and a timestamp ledger of events in an inventive process that can be used for a variety of protected works. By utilizing the properties of the blockchain, a technical solution to the above-mentioned problems is provided.

[0283] Articles of intellectual property are encrypted, hashed, and stored on the blockchain as a means of proving their existence. The storage mechanism also uses a hash tree implementation that reflects its authorship and assigns rights to the inventor.

[0284] Preliminary Matters The collaborative authentication protocol utilizes the generalized hash tree whose principle is described above.

[0285] In addition, the following preliminary matters are relevant to the described embodiments.

[0286] Elliptic Curve Digital Signatures A digital signature is a mathematical scheme that provides the following for a message being sent: · Authentication - The message was signed by a specific party · Non - repudiation - The signer cannot deny having signed the message · Integrity - The message has not been altered during transmission.

[0287] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a cryptographic digital signature scheme used by Bitcoin to ensure that funds can be used only by the legitimate owner. The parameters required for an ECDSA signature include the following: E - Elliptic curve function G - Base point on the elliptic curve of order n, where n·G = O n - Large prime number

[0288] Key Pair Generation Algorithm Secret key x from which the public key P is generated Select a random number x such that 0 < x < n P = x·G

[0289] Signature Algorithm When a message m, a random number k, and a private key x are given, generate a signature using the pair (r, s). k - Select a random number 0 < k < n Calculate r = k·G s = k -1 Calculate (m + xr) mod n Here, k -1 is the multiplicative inverse of k mod n, and k -1 k ≡ 1 mod n holds.

[0290] Verification Algorithm Given a signature (r, s), a message m, and a public key y, verify the signature s -1 is the multiplicative inverse of s mod q, and s -1 s ≡ 1 mod n holds v = s -1 m·G + s -1 Calculate r·y If v = r, the signature is valid.

[0291] Storage of Data on the Blockchain As the adoption of blockchain technology progresses, along with the scaling infrastructure that supports it, there is a growing interest in inserting a large amount of data onto the blockchain. Through the use of various fields of blockchain transactions, it is actually possible to store data on the blockchain. Storing data on the blockchain can generally be done in at least one of two ways: using the unusable OP_RETURN opcode or using the OP_DROP statement.

[0292] Use of OP_RETURN Transaction outputs marked with the OP_RETURN opcode are known as provably unusable outputs because OP_RETURN causes the script execution to fail. Therefore, arbitrary data can be stored after such an opcode in the following types of locking scripts: OP_RETURN <d> Miners and validators are never required to execute the script that follows the OP_RETURN opcode, meaning this method of storing data has the advantage that it does not have to meet the formatting requirements that normally apply to data stored as part of a script.

[0293] Using OP_DROP Another method that can be used to store data in a blockchain transaction is to use the OP_DROP opcode, which can be used in a lock or unlock script of the following form: OP_PUSHDATA OP_DROP This is usually more simply expressed by replacing the OP_PUSHDATA opcode with the data element to be pushed onto the stack, enclosed in angle brackets, as in: <d>OP_DROP Note, however, that data stored in such scripts is subject to script-level checks built into the script execution and transaction validation.

[0294] Using multi-signing scripts In Bitcoin, it is possible to construct a transaction locking script that can be unlocked by providing any m-of-n signatures corresponding to m-of-n specific public keys. The locking script condition for such a multi-signature transaction is written as follows: [CheckMultisig m-of-n]=OP_m <p1>… <P n > OP_n OP_CHECKMULTISIG

[0295] This multi-signature lock script uses public keys P1, …, P n A multi-signature lock script can be used to embed data by replacing a subset of p with other data (herein called "dummy operands"). A multi-signature lock script can, for example, be used to embed n-1 data elements (as dummy operands) with only one valid public key P (the function operand). This can be written diagrammatically as follows: [CheckMultisig 1-of-n]=OP_1 <d1>… <D n-1 > OP_n OP_CHECKMULTISIG

[0296] This form of locking script may be used in any blockchain-based implementation of a copyright assignment hash tree (or, more generally, any hash tree representing hierarchical contributions to a final work, such as a generalized hash tree 1820) as a means of providing a double hash and discretionary signature of the author's contributions within a transaction locking script.

[0297] Collaborative attestation protocol A generalized hash tree is used to implement a collaborative authentication protocol following the same or similar principles as in the example described above with reference to Figures 19A and 19B. This protocol can be applied generally to documenting and authenticating parts of a collaborative work or process. As an example, consider the specific application of creating a "copyright assignment" hash tree that can be stored on a blockchain. It will be understood that this specification applies equally to any form of hash tree representing a collaborative work or process. The end goal is to be able to reflect the hierarchical structure involved in the assignment of intellectual property rights in an immutably stored hash tree representing a copyright or other form of work.

[0298] the purpose The objective of the described embodiment is to establish a mapping between copyright works and a generalized hash tree structure, such that the hierarchical structure of rights is also reflected in the hash tree itself. It is then a matter of implementation to store the hash tree in an immutable manner on the blockchain. To achieve this, the following properties are noted for the described copyright assignment hash tree: 1. It has all the properties of a generalized hash tree: i. Data can exist at any level. ii. The number of data contributions inserted at a level can be arbitrary. iii. The data leaves form a single anti-arborescent directed tree structure. iv. Merkle proofs can be performed on any piece of inserted data. 2. Reflect a hierarchy of authority, ownership, or organizational structure. 3. The formation of a copyright work, including all its individual components, can be traced.

[0299] Conditions (2) and (3) are subtly different, since (2) ensures that it is possible to trace the chain of authority of rights to a copyrighted work, while (3) ensures that it is possible to trace the formation of the work itself.

[0300] Each individual contribution to the final copyrighted work is recorded in a way that makes it viewable as a separate component of the final work, which is accomplished by including the individual contributions as leaf nodes in a tree.

[0301] From the tree structure it is also possible to trace how the component parts of a work fit together: for example, if two sections of a white paper are written and included as leaf nodes, the tree provides a subsequent record of how these sections later combine to form the final document.

[0302] This is accomplished in two ways: non-leaf / intermediate nodes are used to directly represent the history of components of the copyright work, and leaf nodes that appear at higher levels are used to represent editorial changes to the final work.

[0303] example Two sections D of a white paper written by two separate but equal-rank authors, Alice and Bob (e.g., researchers) 1,1 and D. 1,2 Consider these two. They are H 2 (D 0,0 ), H 2 (D 0,1 ) at level m=5.

[0304] Their parent nodes at m=4 have the value H(H 2 (D 0,0 )||H 2 (D 0,1 We represent simple histories as intermediate nodes with ||, where the operator || denotes concatenation.

[0305] However, an editorial change from line manager Carol also appears at the same level m=4, with a value of H 2 (D0), where D0 is the set of any changes E 0,0 , E 0,1 represents the updated state of the combined work that encodes the original work's new state, O0, and any original contribution from Carol to the new state of the copyright work. This is shown in Figure 20.

[0306] Figure 20 shows how data is added to the hash tree and the relationships track both the organizational hierarchy and the formation of the final document or copyright work.

[0307] We then describe a specific exemplary form of a copyright assignment tree, focusing on the meaning of the data stored as nodes in the hash tree.

[0308] Hierarchy of Authority (HoA) In the creation of a copyright work, a non-trivial hierarchy is often involved. There may be an inventor who creates the original content, an editor who modifies the original content and may also provide original content, an advisor who may need to approve certain parts of the document, and an owner who will typically have ultimate rights to the work, to name just a few of the possible actors involved. All such parties are examples of the term "contributor" as used herein. In general, a contributor may be a human being (such as Alice and Bob) operating an appropriate computing device, or, in the case of computer-generated contributions, a contributor may be a computer, an application, etc.

[0309] Ideally, all contributors to the final work should be represented in an indicative hierarchy of authority, which will often be complex. For example, there may be multiple editors at one level of the hierarchy, making it necessary to distinguish between editors who simply modify the previous work and those who add their own original content. A generalized hash tree structure can accommodate these needs.

[0310] In general, contributors can be divided into three different classes of actors: Junior Authors - Contributors who can provide only original content. These would typically be inventors. In Figure 18B, these are members of the first and second junior author groups CA, CB. Senior Author - A contributor who may provide editorial and / or original content that builds on the work of the lower authors. These may typically be editors or advisors. In the example of Figure 18B, this encompasses both level 3 and level 2 contributors C-C0, C-D0, C-E0, C-F0, C-F1. Executive author(s) - These are contributors who may provide editorial and / or original content that builds on the work of lower-level authors, higher-level authors, or both. Also, the root author typically has final approval rights over the copyright work. These may be executives or owners, such as Lead Editor C-G0 in Figure 18B.

[0311] Note that it is possible for the same actor to be involved in an organizational hierarchy of authority as multiple types of contributor, but the described implementation ignores such scenarios for simplicity. However, the generalized hash tree is a flexible enough structure to accommodate these cases. For example, a junior author may also be involved in an editing role for subsequent versions of his or her original work. In this case, it is expected that the same actor will appear at multiple levels in both the organizational HoA and the hash tree that represents it.

[0312] A blockchain-based implementation of the generalized hash tree in Figure 18B would be suitable for capturing, for example, the rights hierarchy for a newspaper, whose organizational hierarchy might be that shown in Figure 18A.

[0313] In this use case, the junior authors CA, CB are journalists, all of whom contribute raw original content D-A0, …, D-B2. The senior authors C-C0, …, CF-1 contain multiple editorial tiers, where some editors (level 3 editors C-C0, C-D0) may have simple editorial authority over the journalists, while higher ranking senior editors (level 2 editors C-E0, C-F0, C-F1) may provide additional original content. Finally, a single executive author C-G0 represents the editor-in-chief (EIC) who has the final authority to approve the newspaper document – ​​the final work D – for publication. Note that all authors may have data associated with them.

[0314] As mentioned above, each author in Figure 18A has a unique public key that they can use to create digital signatures and transact using the blockchain. In the following discussion, the mathematical notation shown in Table 2 will be used to represent the public keys shown in Figure 18, which is consistent with the indexing scheme for the generalized hash tree described above. [Table 2] Table 2: Classes and public keys belonging to each actor in the newspaper's HoA (contributor hierarchy)

[0315] Note that the hierarchical structure is not a binary tree in order to illustrate the utility of the Generalized Hash Tree invention, and that many more complex organizational structures could be used in place of this example.

[0316] copyright assignment hash tree Having established the organizational hierarchy that should be reflected in the formation of copyright works, a hash tree can be used to achieve this goal.

[0317] Figure 21 illustrates how a classical binary Merkle tree can be used to represent the hierarchical structure of a newspaper organization.

[0318] Figure 21 shows a typical binary Merkle tree used to store the components (contributions) of a newspaper document.

[0319] Several problems become apparent with this hash tree structure. The fact that all data blocks are inserted at the same bottom layer of the tree means that there is no hierarchy of permissions, rights, or ownership encoded in the tree; at best, the blocks can be ordered according to their permissions from left to right at this bottom layer. This means that the tree structure alone does not capture the complete hierarchy. In general, it is not possible to determine a contributor's actual level in the hierarchy from their position in the sequence alone. All that can be inferred by moving from left to right is that the level of permissions generally increases.

[0320] However, it is possible to completely encode the hierarchy within the structure of the tree by invoking general hash tree construction. This also provides a much more intuitive representation of the newspapers for which a hash tree can be created. This is the already mentioned generalized hash tree 1820 in Figure 18B, which reflects the desired authority hierarchy.

[0321] Figure 22 shows the node indices {0, i0, i1, …, i m-2 22 shows how the generalized hash tree 1820 follows a general hash tree structure. Recall that all indices are non-negative integers going up from the value 0. That is, FIG. 22 shows the nodes of a hash tree 1820 representing newspapers, labeled according to their node index.

[0322] The problems identified with traditional Merkle tree approaches are rectified here as a clear hierarchy of authority is embedded within the hash tree, whereby leaf nodes can reside at any level within the tree.

[0323] As before, open circles indicate leaf nodes and solid circles indicate non-leaf nodes - this helps to show that the leaf nodes, which reflect the newspaper's organizational hierarchy, now appear at different levels rather than all at the bottom.

[0324] The newspaper organization's HoA persists in a generalized hash tree because each leaf node represents the contribution or effect of a distinct actor.

[0325] The generalized hash tree above uses the above rules, and each node is associated with a specific hash value that can be computed using the node's expression: in particular, each leaf node (white) is the double hash of some block of data being inserted, and each non-leaf node (black) is simply the hash of the concatenation of all its children.

[0326] This tree follows the complete indexing rule, and each node is

number

[0327] Author Role The various actors in the copyright allocation hierarchy were identified as falling into one of three categories of authors: junior, senior, and executive. Each category of author plays a slightly different role in shaping copyright works, and therefore each category is responsible for contributing different data to the hash tree.

[0328] Junior Author A junior author is a contributor who is at the "bottom" of the hierarchy of authority. More precisely, this means that there are no actors directly below them in the organizational structure.

[0329] The original content generated by the subordinate author is generally denoted by the mathematical notation D (in the figures, by a reference designation of the form D-xx) and for present purposes can be referred to as a file (or, more generally, the term data block). This file does not contain the content of other authors, so that contributions made by different subordinate authors can be distinguished. For example, a public key P 0,0,0 Authors with original content D 0,0,0,j where j is determined by the position of the leaf node representing the subordinate author in question relative to that author's siblings.

[0330] The key feature of sub-authorship is that the content created by the sub-author is submitted to a direct superior. It makes sense for this process to happen off-block (off-chain). The following table summarizes the types of data that may be relevant to sub-authorship: [Table 3] Table 3: Data associated with junior authors

[0331] The double hash of the subordinate author's content can be used as an on-block representation of the content, which crucially allows the superior author to provide proof of receipt of the original content on-block, without revealing the content itself.

[0332] While it is entirely possible to simply use a single hash and publish the content data on-chain, using a double hash is advantageous for copyrighted works, since it is desirable to prove that something existed at some point in time by putting a hash on-chain without making a full disclosure, e.g. before filing a patent application.

[0333] A signature of the hash of the original content is included at the time of transaction submission as proof that the subordinate author knows the preimage of the double hash.

[0334] Note that this signature is considered discretionary because it is not used as part of the blockchain protocol and simply indicates that the subordinate author has attested to the original creation of the work. An example of such a digital signature is ECDSA, but this disclosure is not limited thereto because it is a discretionary signature and any signature algorithm can be used for discretionary signatures.

[0335] Let the mathematical notation σ(P,m) denote a discretionary signature (commonly denoted in diagrams with a reference of the form DS-xx), and Sig(P,m) denote a non-discretionary signature on message m by the owner of public key P (called a transaction signature above and commonly denoted with a reference of the form S-xx). Non-discretionary signatures are the signatures that are used to spend UTXOs and are verified by miners as part of the blockchain protocol.

[0336] If the blockchain protocol, i.e., the protocol according to which the operation of the P2P network 101 follows, specifies the use of ECDSA, then the transaction system must be ECDSA. More generally, however, each transaction signature is calculated according to whatever blockchain protocol is applied (which may or may not be ECDSA). In any case, as mentioned above, the same or a different signature algorithm may be used to calculate the discretionary signature.

[0337] Top Authors A top author is an author at the "mid" (middle) level in the hierarchy of authority. The key characteristic of a top author is that they have at least one actor directly below them and at least one actor directly above them in the HoA of the organizational structure.

[0338] As mentioned above, a senior author can have multiple functions: editorial, advisory, administrative, etc. In each case, the senior author is expected to receive content from its subordinates and process it in some way. The senior author can then (a) edit the content he or she receives, (b) add new, original content of his or her own to the work, or (c) do both.

[0339] However, higher-level authors usually bear more responsibility than lower-level authors. The updated state of the copyright work is reflected in its contributions and propagated up the chain, providing both a double hash of all contributions and a signature of that single hash.

[0340] The contribution of a top author can be understood using the following table of data related to the top author, where n denotes the number of direct subordinates of the top author and ε is the number of non-leaf hashes directly below the author in the hash tree. [Table 4] Table 4: Data related to the top authors

[0341] A superior author with n direct subordinates receives content D from each of his / her subordinates. 0,0,0,ε ,…,D 0,1,1,ε+(n-1) Received D 0,0,0,ε ,…,D 0,1,1,ε+(n-1) The number of non-leaf siblings, ε, is used to properly offset the data used in the sum to ensure that the hash tree is consistent with the HoA.

[0342] An edit document E can be created that represents changes made to any received content D, and these edit documents may be null fields if the senior author does not have edit rights or does not want to make the changes.

[0343] Senior authors may also add their own original content, designated by an O. When a compilation is based on the work of subordinates, this original content is entirely the isolated work of their senior authors and may be used by them to demonstrate their own personal additions to the copyright work.

[0344] The total contributions of the senior authors, taking into account both the editorial document and its original content, are combined to reflect the updated state of the copyright work as conveyed to the senior authors.

[0345] A dummy operator (circled +) and its inverse (circled -) are defined, and a modification state or version of a copyright work may be expressed as follows:

number

number

[0346] As with subordinate authors, a double hash of the superior author's contributions, along with a single hash signature, is used to represent the new state of the document on-block (on-chain), allowing the next superior in the hierarchy to perform an attestation of receipt of the new document version and make changes as necessary.

[0347] A senior author is expected to propagate his or her contributions to those above him or her in the hierarchy of authority. Although it may not be necessary, it is reasonable to expect that a senior author will also propagate the original content of each subordinate upwards, so that the next author in the hierarchy can independently verify that the copyright work has been propagated correctly up the hierarchy.

[0348] The final data that the intermediary author must provide is a summary hash, which provides the full history of branches leading up to the point where the intermediary author includes his or her participation in the creation of the copyright work. A summary hash can be understood by reference to a general hash tree 1820.

[0349] Summary Hash Recall that all author contributions are represented as leaf nodes in the hash tree. This means that whenever an author adds content to a document, it also needs to reflect the document's history. This history corresponds to the internal node(s) in the hash tree that are siblings of the higher-level author. Note that lower-level authors, by definition, are not expected to have a document history.

[0350] Simply put, whenever there is a top author represented as a leaf node (open circle) in the hash tree, there will be at least one non-leaf node (filled circle) as a sibling. This means that the top author should provide the hash values ​​corresponding to each of his or her non-leaf node siblings in the generalized hash tree.

[0351] For example, node N 0,0,0,0 and N 0,0,0,1 Consider a generalized hash tree 1820, where N 0,0,0,1 represents a top author as a leaf node in the tree. This author has one sibling node, namely, N 0,0,0,0 and the hash value is given by:

number

[0352] Using the summary hash associated with the top author ensures that the top author provides all the information necessary to traverse the hash tree upwards, which is essential to providing a Merkle existence proof.

[0353] Note that a single top author may have many non-leaf sibling nodes, so it may be necessary to provide multiple summary hashes corresponding to multiple connected branches of the hash tree.

[0354] Executive Author An executive (root) author is an author who is at the top of the authority hierarchy, i.e., has no direct superior (e.g., EIC C-G0). The key characteristics of an executive author are that they can receive content from subordinates, have authority to edit existing content, add original content, and have final authority to approve copyright works prior to publication, etc.

[0355] The root author will also likely be responsible for transmitting the final version of the copyright work to a copyright agency or similar legal authority that deals with intellectual property, such as a patent attorney or notary public.

[0356] An executive author will have access to at least the contributions of his or her immediate subordinates, but in reality, it is expected that an executive author will have access to the original content of all subordinate and superior authors throughout the authority hierarchy. Data related to an executive author is similar to that of superior authors, except that the executive author provides and signs the final version of the copyright work rather than an unfinished version. [Table 5] Table 5: Data related to executive authors

[0357] Just as the EIC C-G0 of a newspaper is responsible for summarizing and signing off on both the sports and finance sections, in most cases the executive author is responsible for merging the connecting branches, so the executive author must provide multiple summary hashes, as shown in the table above.

[0358] It should also be noted that the executive author's contribution is the final version of the document, both denoted by the mathematical notation D0 (reference D in Figures 18B-19B). However, this is not the root of the hash tree. The root of the hash tree itself is still obtained by concatenating the double hash of this final document with all the summary hashes at the m=1 level.

[0359] For example, in the copyright assignment hash tree of Figure 12, the root hash H0 of the tree, which is simply the hash value of node N0, is given by

number

[0360] Finally, it should be noted that, as with senior authors, it is possible for a given authority hierarchy to have multiple executive authors (e.g., a board rather than an EIC), in which case it is reasonable for all executive authors to be consistent in providing the same final version of the copyright work.

[0361] technique The next section expands on the description of a method for implementing the generalized hash tree structure 1820 described above with reference to Figures 19A and 19B. The concepts and techniques utilized in this implementation are now described in further detail.

[0362] Double hash As mentioned above, we double-hash the original content data for each contributing author. 2 (D) may be advantageous. This means that the recipient of the data, i.e., the author's immediate superior, may obtain the H without disclosing D itself. 2 This is because one can prove that one has received D by providing a single hash H(D) that is a preimage of (D).

[0363] This is especially desirable when disclosing components of a final copyright work on the blockchain, because 2 The value of (D) can later be put into a transaction to prove the existence of D, and a superior can demonstrate that the document has come up to him by including the value H(D) in the transaction. No sensitive copyright material is revealed in either transaction.

[0364] The hash value H(D) (generally denoted by a reference number in the form H-xx in the figures) revealed by the superior is referred to herein as the receipt proof.

[0365] As explained below, the double hash value of a component of a copyright work can be used as a virtually unique identifier for that component. This provides a high degree of granularity in how components of a copyright work are distributed and licensed. This is illustrated in the converter use case (streaming digital content).

[0366] hash puzzle lock script Hash puzzles can be written as lock scripts in Script. [Hash Puzzle H(X)]=OP_HASH160 H(X) OP_EQUALVERIFY It can only be solved and unlocked given the input X. To implement the proof of receipt, a modification of the hash puzzle forces the solver to reveal the preimage just before the double hash. The proof of receipt can be written in Script as follows: [Receipt D1,…,D n ]=[Hash Puzzle H 2 (D1)]…[Hash Puzzle H 2 (D n )] =OP_HASH160H 2 (D1) OP_EQUALVERIFY … OP_HASH160 H 2 (D n ) OP_EQUALVERIFY This means that all data D1,…,D n This locking script condition can be used to implement and record the copyright assignment hash tree on the blockchain.

[0367] It should be understood that OP_HASH160 is just one example of a suitable hash function -- in general, any cryptographically secure hash function can be used (another example is OP_SHA256).

[0368] Using discretionary signatures As mentioned above, discretionary signatures are signatures that are not used by the blockchain consensus algorithm. In the UTXO model, it is not the signature that is consumed as input to the OP_CHECKSIG operation in the script.

[0369] Discretionary signatures are denoted as σ(P,m), and non-discretionary signatures consumed by OP_CHECKSIG are denoted as Sig(P,m), where P is the signer's public key and m is the message (part of the transaction) being signed. For non-discretionary signatures, m is always the transaction, while for discretionary signatures, m can be any message.

[0370] Discretionary signatures can be used as a secondary means by which authors consent to the use of their work. For example, an author could directly attest to their contribution as σ(P,H(D)), in addition to giving a signature Sig(P,Tx) as part of a transaction consenting to the use of their content by a superior.

[0371] Note that discretionary signatures can be any digital signature type, but non-discretionary signatures must necessarily be ECDSA signatures (assuming they are mandated by the blockchain protocol). More generally, non-discretionary signatures must be applied in accordance with whatever blockchain protocol is applied, whereas discretionary signatures can be applied independently of the blockchain protocol (the only requirement is that they be included in a way that does not invalidate the transaction).

[0372] Communication Channels A distinction is made between how different components of data are stored and transferred. A distinction is drawn between data that is transferred on-block as part of a transaction, and data that is transferred off-block via some other, preferably secure, communication channel (a "side channel").

[0373] It is important to store the copyright assignment hash tree on the blockchain for the following reasons: Private - If the hash tree is generated before it is desirable to publicly detail the invention, e.g. before filing a patent application, it is wise to store only the hash values ​​of the data, and not the raw data itself. Proof of Receipt - The raw data can be sent off-block, e.g. to a superior, and a hash puzzle on the double hash of the data can be used on-block to prove that the data was received by the superior, revealing only a single hash of the data (see 1) on-block.

[0374] 23 and 24 show how the processes of sending data off-block and on-block occur in parallel within a desired hierarchy of rights of an enterprise framework or other external hierarchy.

[0375] Here, the raw data held off-block is represented by D values, and their hash and double hash are stored on-block. The meaning of the other on-block data shown here was explained above.

[0376] Figure 23 shows the main data flows for the branches of the authority hierarchy, where P0 represents the executive author and P 0,0 is the senior author, and P 0,0,0 , P 0,0,1 Both are junior authors.

[0377] FIG. 24 shows the main data flows for another authority hierarchy branch, where P0 represents the executive author and P 0,1 is the senior author, and P 0,1,0 , P 0,1,1 Both are junior authors.

[0378] Implementation using blockchain To implement a copyright assignment hash tree on the blockchain, nodes (hash values) are stored in transactions 152 to reflect both the structure of the hash tree itself and the order of operations to create the copyright work, as determined by HoA.

[0379] The existing public key infrastructure that governs ownership of digital assets in the blockchain 150 is used to represent the chain of authority, and the structure of transactions is used to represent the connections (directional edges) between nodes in the hash tree. Due to the properties of the blockchain 150, this is a means of realizing a generalized hash tree that allows the order of operations encoded in the hash tree to be immutably timestamped on the public ledger.

[0380] In the implementation described above, transactions 152 are used to represent edges of a hash tree, meaning that the transaction directly represents the process of concatenating and hashing a set of siblings to produce a parent node.

[0381] A set of transactions in a hash tree structure {Tx * ,Tx0,Tx 0,0 ,Tx 0,0,0 ,Tx 0,1 ,Tx 0,1,0 } is shown diagrammatically in FIG.

[0382] Figure 25 shows the copyright assignment tree mapped to a set of blockchain transactions 1920, which represent the edges between nodes. This is the same set of transactions shown in Figures 19A and 19B, but Figure 25 uses a mathematical notation to represent the transactions (also used below). This mathematical notation maps to the reference symbols used in Figures 19A and 19B as follows: Tx 0,0,0 -TX-A Tx 0,1,0 -TX-B Tx 0,0 -TX-C Tx 0,1 -TX-D Tx 0,0 -TX-EF Tx0-TX-G ·Tx*-TX*

[0383] Note that each transaction contains hash tree nodes from two different tree levels: for any given transaction, the "lower" edges are part of the transaction inputs and the "higher" edges are part of the outputs, as described above in the examples of Figures 19A and 19B.

[0384] The mapping of hash tree nodes to blockchain transactions uses the convention that transaction inputs contain a non-discretionary signature from the author, and outputs represent proofs of existence of content created by the author, and these outputs are locked such that only the author's direct ancestor(s) can unlock the UTXO and continue adding to the hash tree.

[0385] The relationship between the transactions shown here and the newspaper HoA is shown in FIG.

[0386] Figure 26 shows the mapping between a hierarchy of authority (HoA) and the corresponding chain of transactions.

[0387] Authors at any given level include in their output their discretionary signature and a double hash of their content, thus effectively conveying their original work up the hierarchy and consenting to its use by those above them.

[0388] The intent here is to represent the organizational authority hierarchy on the blockchain 150 and store the representation of each component of the copyright work as a unique hash value.

[0389] For the purposes of this implementation, a transaction effectively provides the details of a branch of a hash tree. A branch is defined as a collection of similar edges. If you have a parent node with four children, then the collection of these four edges is called a branch. Recall that these edges are considered similar because they were each created by concatenating all four of their children and hashing the result.

[0390] For example, transaction Tx 0,0,0 This transaction is a branch of documentation, and the top author is P 0,0,0 is represented by the destination (recipient) of the output, and the subordinate author P 0,0,0,0 ,…,P 0,0,0,4 is represented by the input signature. The recipient's top author P 0,0,0 The signature from transaction Tx 0,0,0 is needed to use the output of

[0391] This paradigm is common to all transactions except for the final transaction Tx*, i.e. the transaction between the executive author and the copyright agency. This transaction differs in that the output can be unlocked by a copyright agency that is external to the hierarchy of rights, e.g. an IP registry or a patent attorney.

[0392] This final transaction contains a hashed representation of both the final version of the copyright work, D, and the root hash of the content allocation hash tree, H0.

[0393] In the case of a copyrighted newspaper, there is only one root author P0. The final version of the newspaper is 0,2 This is the leaf node N 0,2 (See 4.1.3 for details.)

[0394] Node N corresponds to the executive author 0,2 The hash value H 0,2 =H 2 (D 0,2 ) and the node N0 that corresponds to the root hash H0.

[0395] Transactions and Data We now describe possible forms of transactions 1920 that embody the hash tree 1820. These transactions completely represent the copyright assignment hash tree 1820 for the newspaper hierarchy.

[0396] The hash tree is implemented using some of the techniques described herein, and it should be noted that this is merely an illustration of how these techniques may be useful in applying intellectual property stored on the blockchain, but the method is not limited to only these techniques.

[0397] From lower author to higher author Consider a transaction from five lower-level authors (sports journalists) to a higher-level author (sports editor), which is shown in Figure 12.

[0398] This transaction, shown below as transaction 1, contains five inputs, one to provide a separate signature from each subordinate author, and two outputs.

[0399] The first output is an unspendable OP_RETURN output that contains (i) a double hash of each leaf author's contribution, and (ii) an arbitrary signature over the single hash of each author's contribution. This double hash allows a senior author to whom the transaction is paid to later provide a proof of receipt (in the form of a single hash, without revealing the underlying contribution).

[0400] The second output is a spendable UTXO that contains two lock script components: the first is a simple signature checking script that is unlocked when presented with a signature from a public key belonging to the senior author.

[0401] The second part is a Proof of Receipt script, as shown in Section 4.1.4, which is unlocked when provided with a hash of each subordinate author's contribution, which is then passed off-block to the associated superior author. [Table 6] Transaction 1: An example of a bottom-to-top transaction using OP_RETURN. This is the TxID from Figure 26. 0,0,0 Corresponds to.

[0402] This same transaction could alternatively be created using a multi-signature UTXO, where the OP_RETURN output is replaced with the following lock script component: [Table 7]

[0403] This lock script is used to store the contributions of subordinate authors rather than the unusable OP_RETURN output. This lock script is stored in the public key P 0,0,0 This is solved by providing the signature of the top author using , and thus works the same as the signature check in the previous diagram. An alternative form of lower-author to top-author transaction is shown below as transaction 2. [Table 8] Transaction 2: An example of a bottom-to-top transaction using a multi-signature lock script. This is the TxID from Figure 16. 0,0,0 Corresponds to.

[0404] Using OP_RETURN, the "current" author's hash value can be added directly. Using multi-signing, the hash value is hidden in the script, and the script is hashed, so that the next transaction immediately up in the tree only reveals the committed hash of the content data.

[0405] The following description continues to use the multi-signature format for the rest of the transactions in this implementation, but OP_RETURN is still a valid method. More generally, the data in question can be included in the transaction in any way that does not invalidate the transaction (preferably in the signed output).

[0406] Top Author to Top Author Top author P 0,0,0 From the top author P with higher ranking 0,0 Transaction TxID to 0,0 Both actors are top authors, and both are represented by leaf nodes in the copyright assignment hash tree 1820, albeit at different levels. This transaction is in principle similar to the bottom-to-top transaction just described. The main difference here is that, rather than the previous situation where five bottom authors paid one top author, one actor makes a transaction to one other actor.

[0407] This difference is reflected in the number of inputs (now just one) and the number of data elements stored in the output script. The transaction itself is shown below as transaction 3. [Table 9] Transaction 3: An example of a top-to-top transaction using a multi-signature lock script. This is the TxID from Figure prev 16. 0,0 Corresponds to.

[0408] The input script is the top author P 0,0,0 Previous TxID sent to 0,0,0 This satisfies the locking burden of 5 hashed data elements required to satisfy the receipt proof use condition, and the author signature Sig(P 0,0,0 ,Tx).

[0409] The output scripts contain the same types of locking conditions; one multi-signature script and one acknowledgement script. The main difference here is that the multi-signature script contains only the double hash of this single contribution and the discretionary signature of the lower-ranked top author. However, this locking script is not generated by the summary hash H 0,0,0,0 also contains a hash of the concatenation of all subeditors' previous contributions. The script is written as follows: [Table 10] This script is 0,0 The receipt can be unlocked when a signature from a higher-ranked senior editor, who is the owner of the contribution, is given to the higher-ranked senior author by sending a hash of the contributions of the lower-ranked authors, H(D 0,0,0,1 Note that we only ask you to provide

[0410] Top to Executive Authors Top Sports Editor P 0,0 and both senior financial editors P 0,1 ,P 0,2 Consider a transaction TxID0 sent from to be paid to an Executive Editor (EIC) P0. Recall that all top editors are top authors, and that the EIC is the only executive author. Again, all of these actors are represented by leaf nodes in the copyright assignment hash tree.

[0411] This transaction, shown below as transaction 4, has three inputs because there are three top authors at the same level in the hash tree, and one output because there is only one executive author EIC.

[0412] The input script has the same format as the top-to-top transaction shown above. However, since both financial editors have the same subfinancial editor, both are just hashes of the subeditor's contributions. <H(D 3 0,2,1,2 D 0,1,0,1 )> is also provided as input. [Table 11] Transaction 4: An example of a top-to-executive transaction using a multi-signature lock script. This corresponds to TxID0 from Figure 16.

[0413] The output script used here requires a receipt of the top author's contribution provided by the EIC, and a signature by the EIC using P0. The multi-signature script shown below uses both summary hashes for this level of the tree, H 0,0,0 and H 0,1,0 Also includes. [Table 12]

[0414] Executive Author to Copyright Agency Consider a transaction TxID* sent from an EIC P0 to a copyright authority (CA) P*. This transaction has the special properties that it was created by an executive author and contains the following: (i) a unique representation H of the final version or state of the copyright work D; 2 (D) (ii) A root hash H0=N0 for the copyright assignment tree.

[0415] This transaction, shown below as transaction 5, also includes an input signature from the executive author(s) to indicate that the highest authority in the hierarchy of rights agrees to disclose the final state D to a third-party CA by sending it off-block. [Table 13] Transaction 5: An example Executive to Copyright Authority transaction. This corresponds to TxID0 from Figure 16.

[0416] This transaction contains one input and one output: the input contains a single hash of the top author's contribution to the copyright work as proof of receipt, and also contains the required signature from the EIC's public key P0.

[0417] The output of this transaction has two locking components. The first is a simple hash puzzle that requires the Copyright Authority to provide a value of H0 (denoted by reference H-RH in Figure 19B). The value of H0 serves both as a simple declaration of the root of the hash tree and as proof that the Copyright Authority received the correct, expected version of the final copyright work and its corresponding hash tree representation. It can be written as follows: [Hash Puzzle H(H0)]=OP_HASH160 H 2 (H0) OP_EQUALVERIFY It is emphasized that OP_HASH160 is used as an illustrative example and is only one of many hash functions that may be used to construct a promising hash puzzle. The term hash puzzle does not imply a specific hash function; any hash function that has the necessary cryptographic properties can be used to construct a hash puzzle.

[0418] The second component is a multi-signature script, which contains the EIC's contribution, a signature of that contribution, and the associated digest hash of both, and can be written as follows: [Table 14] Once the copyright organization satisfies these locking conditions in a subsequent transaction, the process of implementing the copyright assignment tree on the blockchain is complete.

[0419] summary In summary, the above-described embodiments provide: A generalized hash tree capable of storing copyrighted works while also reflecting the hierarchy of authorities representing the ownership of rights; A blockchain-based implementation for storing generalized hash trees on a public blockchain.

[0420] These two aspects are used in tandem to address the problem of assignment of rights to IP and subsequent disclosure identified in the introduction of this paper.

[0421] The above system leverages the properties of blockchain and related cryptographic primitives to generate a variety of valuable functions that support content management systems, particularly as they relate to documenting ownership and chronology of the collaborative creation of content. Through the system outlined in the WP, the following is made possible:

[0422] A unique content identifier H 2 (D): Generate a unique identifier for any piece of content. This unique identifier is stored in the 2 (Content). This identifier for the content can be made available to external systems that need to retrieve or reference the content of interest. (As an example, think of the ISBN identifier for books, which provides a similar function.)

[0423] "Proof of Work" and "Proof of When": In this context, this means that actors [H 2 (Content),σ(H(Content))] This means that an actor can prove that they created a particular piece of content by referencing an existing transaction on the blockchain that contains a unique identifier. This transaction on the (immutable) blockchain in a particular block shows that the content itself can be proven to have been created at least since a particular time. The signature of the double hash preimage shows that the private key holder knew the content at or before that time.

[0424] Proof of Inclusion: The system is underpinned by a conceptual mapping to a hash tree and the storage of the applicable hashes in blockchain transactions, allowing stakeholders to attest to the inclusion of a particular piece of content in the final version of that content (H 2 (Content). This is the case when the final version is a function of multiple contributed content, and different content may be produced by multiple participants.

[0425] The storage of this hash tree data on the blockchain, enforced by appropriate participants providing digital signatures to approve content, data, and processes, makes proofs of inclusion particularly strong and gives the blockchain its transparency and immutability, as well as the properties of digital signatures as they relate to refutation.

[0426] Proof of Transfer: By signing the input of a transaction-as-edge, it acts as an entity (child) granting its parent entity permission to edit or consume the content that the child created. This signature of the transaction input ensures that the child entity can use the content being passed (its identifier H 2 It also serves as an expression of agreement that the (Content) is correct.

[0427] Proof of Receipt: When an entity consumes the output of a transaction as an edge (which involves the entity providing its signature and the hash of the child's output), this certifies that it received the raw content from its child node, and that the raw content is consistent (a perfect match) with what the child node says the raw content should be.

[0428] Proof of Chronology: By having transactions as edges represent the transfer of content from child nodes to parent nodes. This enforces a time-ordered documentation of participant contributions, since any stakeholder can trace the progressive composition starting from a leaf node through the hierarchy to the final (root node) output. Note that parent nodes consume transaction outputs from their children, which indicates the sequence of contributions.

[0429] IP Disclosure: Disclosure of the IP is accomplished using the public blockchain 150. The public blockchain 150 acts as a secure timestamp server to record events, so that publication of a hash value in the copyright assignment hash tree acts as a non-enabling representation of the invention at a given timestamp. The immutable properties of a public proof-of-work (PoW) blockchain, combined with the irreversibility of hash functions, means that placing a hash value of a copyright work (or its components) is a secure way to timestamp the moment of conception and subsequent development of a novel work. At a later date, the complete work can be published elsewhere (e.g., by filing a patent) and its hash can be verified against the timestamped on-chain values.

[0430] This method thus allows the resolution of disputes regarding priority or entitlement to an inventive concept and can be used in several ways in legal proceedings over IP disputes.

[0431] Moreover, if third-party services were to implement these methods at scale, a public blockchain could be used as a general-purpose IP registry that could contain time-stamped events in legal proceedings, such as when a filing is filed or when IP protection is granted.

[0432] 6. Use Case: Movie Streaming The use of a generalized hash tree structure to represent the creation of a copyright work, combined with a blockchain to immutably timestamp the sequence of operations, can be applied to scenarios involving the creation of many different types of works. One such example is the creation of a movie, which typically involves many actors, such as directors, producers, screenwriters, actors, set designers, editors, etc. The example described considers a movie, but the description applies equally to other forms of digital content that are composed of discrete segments.

[0433] Generalized Hash Trees for Movies Highly complex hash trees can be created to represent the creative process in its entirety, detailing how each element of the final film was created.

[0434] However, for this example, a simplified scenario can be considered. Let us assume that the film production process is divided into three acts of equal length. Each act is divided into five chunks of equal length, resulting in a total of 15 chunks of video data D1, ..., D 15 , each with its associated double hash value H 2 (D i ). Then, movies can be represented using a simple general hash tree, as shown in Figure 15.

[0435] Figure 15 shows the generalized hash tree structure applied to a movie, divided into 15 data segments.

[0436] As discussed in Section 6.3 below, the double hash value associated with each chunk of the film can be used as a unique packet ID, and each packet can have its Merkle root R as a unique identifier for the entire film. M By using the hash tree, we can quickly verify the root of the hash tree. M The ID acts similar to an ISBN or barcode as a unique identifier for a product.

[0437] However, the root R M is R M It is much more valuable as a unique product identifier than a traditional bar code because it also allows the individual components of the film to be easily verified if there is a trusted source for it.

[0438] Furthermore, each segment of the film D1, ..., D 15 It is possible to associate each segment with the root of another, distinct generalized hash subtree. In this way, the individual components of each segment can be tracked on the blockchain using the copyright transfer implementation described in Section 4.

[0439] An example of such a generalized hash subtree for the first movie segment D1 is shown in Figure 16. In both Figures 15 and 16, the data segment for D1 is shown in green for consistency, but the two trees themselves are separate instances of a copyright transfer hash tree.

[0440] Figure 16 shows the generalized hash subtree for the first movie segment D1. The data that is ultimately combined to produce segment D1 is shown in lowercase.

[0441] Streaming Movies In the case of a movie, which is represented by a hash tree of the kind shown in Figure 15, one example of a practical use is a scenario where the generalized hash tree can be used as a strong data integrity check when a consumer (Alice) is streaming a movie from a streaming service provider (Bob).

[0442] When Alice wants to stream a movie, she first accesses the Merkle root M This Merkle root is used as the public, unique identifier for the movie file. In addition, Alice also obtains a unique packet ID H 2 (D1), …, H 2 (D 15 ) and the associated Merkle paths Γ1, …, Γ 15 All this information is publicly available on the blockchain150 (see Section 4) and is assumed to be certified by a standards body such as the British Board of Film Classification in the UK

[14] . The data that Alice wants to stream, and the data that she has in advance, are shown in Table 6 below. [Table 15]

[0443] This means that Alice now has enough information to verify whether the data packets sent by Bob as the streaming service provider are legitimate, without needing to look at them herself: if Alice receives a packet that does not double hash to the packet ID or any packet ID, she can ignore the data as erroneous and abort the viewing.

[0444] When combined with a pay-per-second framework, this would provide Alice with an extremely low-risk way to stream content on a peer-to-peer basis.

[0445] With the right granularity in segment sizes, Alice can enforce that a unique packet ID is always checked before viewing a segment, thus protecting her from accidentally seeing nasty or unexpected content. This can be as strict as a frame-by-frame pre-check of the packet ID.

[0446] Movie version update Having a fixed, unique product identity (the root of the Merkle tree) is particularly useful for applications in the creation of movies, which often have multiple different versions: for example, movies often have to be slightly modified for each country in which they are shown, in order to comply with local regulations.

[0447] These small modifications may be difficult to distinguish for a human user like Alice, but due to the high-entropy properties of cryptographic hash functions, they will always be easily detectable in a hash digest of the movie data.

[0448] Consider the same movie as above, with 15 segments, each with a unique packet ID. All the IDs are stored in a Merkle tree root R. M is inseparably linked to the film's unique product identity.

[0449] It is feasible that the director could revisit this film in a few years' time and make some minor editorial changes for a special "director's cut" version of the film. The effect of the director's new changes to the film is shown in Figure 17.

[0450] Figure 17 shows the modified generalized hash tree representing a new "director's cut" version of a movie. The director's changes relative to the original are reflected in the data segment D. 16 The new generalized hash tree necessarily has a new root R' M ≠R M This means that "director's cut" versions can be easily distinguished from the original version by adopting the convention of using the root of the hash tree as a unique product identifier for the entire film.

[0451] With this new identifier, Alice can verify that she is seeing the expected version of the movie before even seeing a single frame. If Alice receives a data packet for the director's cut but tries to verify it against the product ID of the original movie, even the first segment will fail and Alice can ask Bob for the original version instead.

[0452] The checks could also serve as a tool to ensure users of peer-to-peer streaming services don't inadvertently stream versions of movies that are banned in their home countries.

[0453] It will be understood that the above-described embodiments have been described by way of example only.

[0454] More generally, there may be provided a method, apparatus or program according to any one or more of the following statements.

[0455] statement 1 1. A computer-implemented method for recording in one or more blockchain transactions contributions to a work by contributors having respective levels in a defined hierarchical structure, in which one or more lower-level contributors provide one or more lower-level contributions, respectively, to a higher-level contributor, the higher-level contributor providing a higher-level contribution in response to the one or more lower-level contributions, the method comprising: generating or modifying, at a computing device of the higher level contributor, a higher level contributor transaction to provide evidence of the higher level contribution, the generated or modified higher level contributor transaction comprising: one or more inputs, the one or more inputs comprising: one or more pointers to one or more available outputs of one or more lower-level contributor transactions, the one or more lower-level contributor transactions including one or more lower-level contribution commitments providing evidence of the one or more lower-level contributions; one or more transaction signatures of the higher-level contributors that satisfy one or more signature challenges of the one or more usable outputs; the higher-level contributor transaction includes a higher-level contribution commitment computed from the higher-level contribution, the one or more pointers and the contribution commitments representing a relationship between the higher-level contributor and the one or more lower-level contributors within the defined hierarchical structure, and the one or more transaction signatures attest to that relationship. method. The phrase "one or more lower level contributor transactions including first and second lower level contribution hashes" includes cases where the first and second lower level contribution hashes are included in the same lower level contributor transaction and cases where they are included in different lower level contributor transactions. In the above examples, the contribution commitment takes the form of a contribution hash (e.g., a single or double hash of the contribution to which it provides evidence). More generally, a contribution commitment may or may not be hash-based, and may, for example, include the raw data of the contribution (which may be all or part of the contribution itself) or some other processed form of the data of the contribution suitable to serve as evidence of the contribution. Exemplary embodiments are described below. statement 2 The method of statement 1, wherein the one or more lower level contributors include first and second lower level contributors, the one or more lower level contributions include first and second lower level contributions of the first and second lower level contributors, respectively, and the one or more lower level contribution commitments include first and second lower level contribution commitments evidencing the first and second lower level contributions, respectively. statement 3 3. The method of claim 1 or 2, wherein the higher level contributor transaction includes one or more receipts of the one or more lower level contributions. statement 4 The method of claims 2 and 3, wherein the one or more receipts include: a first receipt of the first lower level contribution, and a second receipt of the second lower level contribution. statement 5 The method of claim 3 or 4, wherein the one or more receipt proofs are included in the one or more inputs and respectively satisfy first and second receipt proof challenges of the one or more usable outputs of the one or more lower-level contributor transactions. statement 6 6. The method of any one of statements 1 to 5, wherein the higher level contributor transaction includes a receipt challenge for the higher level contribution. statement 7 7. The method of any one of statements 1 to 6, wherein the high-level contributor transaction includes a transaction signing challenge for a receiving entity. statement 8 8. The method of claim 7, wherein the receiving entity is a higher level contributor in the hierarchical structure, the higher level contributor being an intermediate contributor between the lower level contributor and the higher level contributor. statement 9 9. The method of any one of statements 1-8, wherein the higher level contributor transaction includes a discretionary signature generated by applying a signing function to the higher level contributor's private key and proof of the higher level contribution, the proof of the higher level contribution being the higher level contribution or a hash or other function thereof, and the proof of the higher level contribution is not included in the higher level contributor transaction. statement 10 10. The method of any one of claims 1 to 9, wherein the contribution commitment is a contribution hash. statement 11 11. The method of claims 9 and 10, wherein the higher level contribution hash is a hash of the proof of the higher level contribution. statement 12 the proof of the higher level contribution is the higher level contribution and the higher level contribution hash is a single hash of the higher level contribution; or the proof of the higher level contribution is a single hash of the higher level contribution, and the higher level contribution hash is a double hash of the higher level contribution. 12. The method according to claim 11. The term "double hash" does not necessarily mean that the same hash function is applied twice. In general, a double hash of some data can be mathematically represented as H1(H2(D)), where H1 and H2 may be the same hash function (H1=H2) or different hash functions (H1≠H2). statement 13 13. The method of any one of statements 6 to 12, wherein the receipt challenge, the transaction signing challenge for the receiving entity, and / or the discretionary signature are included in one or more outputs of the higher level contributor transaction. statement 14 The method of statement 13 when citing statements 6, 7, and 9, wherein at least the receipt challenge and the transaction signing challenge are included in an output of the one or more outputs that are consumable independently of the discretionary signature. statement 15 The output or outputs: a summary hash computed by hashing a concatenated string including a single hash or multiple hashes of the first lower level contribution and a single hash or multiple hashes of the second lower level contribution, the usable output being consumable independently of the summary hash. 15. The method according to any one of claims 1 to 14. statement 16 1. A computer-implemented method for recording in one or more blockchain transactions contributions to a work by contributors having respective levels in a defined hierarchical structure, in which first and second lower level contributors provide first and second lower level contributions, respectively, to a mid-level contributor, which mid-level contributors provide mid-level contributions to a higher level contributor in response to the first and second lower level contributions, the method comprising: generating or modifying a blockchain transaction at a computing device of the intermediate level contributor, the generated or modified blockchain transaction comprising: a first receipt of said first lower level contribution; a second receipt of the second lower level contribution; and The mid-level contributor's transaction signature and one or more inputs including; an acknowledgement challenge for said intermediate level contribution; a transaction signing challenge for the higher-level contributor; and Discretionary Signature and one or more outputs including the discretionary signature is generated by applying a signing function to the private key of the intermediary-level contributor and the intermediary-level contribution or a hash thereof; at least the receipt challenge and the transaction signature challenge are included in an output of the one or more outputs that is usable independently of the discretionary signature; method. statement 17 The output or outputs: a summary hash computed by hashing a concatenated string including a single hash or multiple hashes of the first lower-level contribution and a single hash or multiple hashes of the second lower-level contribution, the usable output being usable independently of the summary hash. 17. The method according to claim 16. statement 18 18. The method of claim 16 or 17, wherein a second intermediate level contributor provides a second intermediate level contribution to the higher level contributor; The one or more inputs of the blockchain transaction further include: a third receipt of a third lower level contribution; a transaction signature of the second intermediary level contributor; The one or more outputs may further include: an acknowledgement challenge for the second intermediate level contribution; and Includes a second discretionary signature, the challenge for at least the second intermediate level of contribution is included in the usable output of the one or more outputs or another usable output of the one or more outputs; the second discretionary signature is generated by applying a signing function to a single or multiple hash of the second interim level contribution and to the private key or another private key of the interim level contributor. method. Statement 19 20. The method of claim 18, wherein the one or more outputs include a second summary hash, the second summary hash being computed by hashing a pre-image, the pre-image including a single hash or multiple hashes of the third lower level contributions. statement 20 The one or more inputs of the blockchain transaction further include: a fourth receipt of a fourth lower level contribution; the pre-image hashed to compute the second summary hash is in the form of a second concatenated string including the single hash or multiple hashes of the third lower level contribution and the single hash or multiple hashes of the fourth lower level contribution. 19. The method of claim 19. statement 21 21. The method of any one of statements 1 to 20, wherein the discretionary signature is included in one or more non-usable outputs of the blockchain transaction. statement 22 22. The method of claim 21 when citing statement 17, wherein the one or more unusable outputs include the summary hash. statement 23 23. The method of claim 21 or 22, wherein the one or more unusable outputs also include a hash or multiple hashes of the first lower level contribution and a hash or multiple hashes of the second lower level contribution. statement 24 21. The method of any one of statements 16 to 20, wherein the discretionary signature is included in the available output, the transaction signature challenge is a function operand of a multi-signature check opcode, and the discretionary signature is a dummy operand of the multi-signature check opcode. statement 25 25. The method of claim 24 when citing statement 17, wherein the digest hash is included in the available output as a dummy operand of the multi-signature check opcode. statement 26 26. The method of claim 24 or 25, wherein a single hash or multiple hashes of the first lower level contribution and a single hash or multiple hashes of the second lower level contribution are also included as dummy operands of the multi-signature check opcode. statement 27 27. The method of any one of statements 1 to 26, comprising a step of sending the blockchain transaction to a node of a blockchain network where it is processed for recording in the blockchain. statement 28 27. The method of any one of statements 1 to 26, comprising sending the blockchain transaction to an off-chain system for processing. statement 29 The higher-level contributor generates a second blockchain transaction to spend the spendable output, the second blockchain transaction: A receipt of said intermediate level contribution; The higher-level contributor's transaction signature and one or more inputs including; a further receipt challenge for the higher level contribution of said higher level contributor; a transaction signing challenge for the recipient of said higher level contribution; Further discretionary signing and one or more outputs including the further discretionary signature is generated by applying a private key of the higher-level contributor and a single or multiple hashes of the higher-level contribution and a signing function. 29. The method according to any one of claims 1 to 28. statement 30 30. The method of claim 29, wherein the one or more outputs of the second blockchain transaction include a further summary hash calculated by hashing a further concatenated string, the further concatenated string including the summary hash and a single hash or multiple hashes of the contributions of the higher level contributors. statement 31 The method of claim 29 or 30, wherein the higher level contribution is in the form of a final work that is responsive to all contributions received from all contributors in the hierarchical structure, and the further proof of receipt challenge is satisfied by proof of receipt of the final work. statement 32 A further aspect of the present application provides a blockchain transaction embodied in a transitory or non-transitory medium, the blockchain transaction providing evidence of a contribution of a higher level contributor in a defined contribution hierarchy, the blockchain transaction comprising: a first receipt of the first lower level contribution; A second receipt of the second lower level contribution; and The mid-level contributor's transaction signature and one or more inputs including; Proof of receipt challenge for mid-level contributions; A transaction signing challenge for the receiving entity, and a discretionary signature verifiable based on a private key of the higher-level contributor and a proof of the intermediate-level contribution, the proof of the higher-level contribution being the higher-level contribution or a hash thereof, and the blockchain transaction not including the proof of the higher-level contribution. and one or more outputs including At least the receipt challenge and the transaction signature challenge are included in an output of the one or more outputs that is usable independently of the discretionary signature.

[0456] According to another aspect disclosed herein, a method may be provided that includes action of a first party, a second party, any third parties that may be involved, and / or any one or more nodes of the network of nodes.

[0457] According to another aspect disclosed herein, a system may be provided having a first party computing device, a second party computing device, if any, a third party computing device, and / or one or more nodes of a network of nodes.

[0458] Other variations or uses of the disclosed techniques may be apparent to those of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the claims appended hereto. < / d> < / d> < / data>

Claims

1. 1. A computer-implemented method for recording in one or more blockchain transactions contributions to a work by contributors having respective levels in a defined hierarchical structure, in which one or more lower-level contributors provide one or more lower-level contributions, respectively, to a higher-level contributor, the higher-level contributor providing a higher-level contribution in response to the one or more lower-level contributions, the method comprising: generating or modifying, at a computing device of the higher level contributor, a higher level contributor transaction to provide evidence of the higher level contribution, the generated or modified higher level contributor transaction comprising: one or more inputs, the one or more inputs comprising: one or more pointers to one or more available outputs of one or more lower-level contributor transactions, the one or more lower-level contributor transactions including one or more lower-level contribution commitments providing evidence of the one or more lower-level contributions; one or more transaction signatures of the higher-level contributors that satisfy one or more signature challenges of the one or more usable outputs; the higher-level contributor transaction includes a higher-level contribution commitment computed from the higher-level contribution, the one or more pointers and the contribution commitments representing a relationship between the higher-level contributor and the one or more lower-level contributors within the defined hierarchical structure, and the one or more transaction signatures attest to that relationship. method.

2. 2. The method of claim 1, wherein the one or more lower level contributors include first and second lower level contributors, the one or more lower level contributions include first and second lower level contributions of the first and second lower level contributors, respectively, and the one or more lower level contribution commitments include first and second lower level contribution commitments evidencing the first and second lower level contributions, respectively.

3. 3. The method of claim 1 or 2, wherein the higher level contributor transaction includes one or more receipts of the one or more lower level contributions.

4. The method of claim 3 when relying on claim 2, wherein the one or more receipt confirmations include: a first receipt confirmation of the first lower level contribution, and a second receipt confirmation of the second lower level contribution.

5. 5. The method of claim 3 or 4, wherein the one or more receipt proofs are included in the one or more inputs and respectively satisfy one or more receipt proof challenges of the one or more usable outputs of the one or more lower-level contributor transactions.

6. The method of claim 1 , wherein the higher level contributor transaction includes an acknowledgement challenge for the higher level contribution.

7. The method of claim 1 , wherein the high-level contributor transaction includes a transaction signature challenge for a receiving entity.

8. 8. The method of claim 7, wherein the receiving entity is a higher level contributor in the hierarchical structure, the higher level contributor being an intermediate contributor between the lower level contributor and the higher level contributor.

9. 9. The method of claim 1, wherein the higher level contributor transaction includes a discretionary signature generated by applying a signing function to a private key of the higher level contributor and a proof of the higher level contribution, the proof of the higher level contribution being the higher level contribution or a hash or other function thereof, and the proof of the higher level contribution is not included in the higher level contributor transaction.

10. The method of claim 1 , wherein the contribution commitment is a contribution hash.

11. The method of claims 9 and 10, wherein the higher level contribution hash is a hash of the proof of the higher level contribution.

12. the proof of the higher level contribution is the higher level contribution and the higher level contribution hash is a single hash of the higher level contribution; or the proof of the higher level contribution is a single hash of the higher level contribution, and the higher level contribution hash is a double hash of the higher level contribution. The method of claim 11.

13. 13. The method of claim 6, wherein the receipt challenge, the transaction signing challenge for the receiving entity, and / or the discretionary signature are included in one or more outputs of the higher level contributor transaction.

14. 14. The method of claim 13 when relying on claims 6, 7 and 9, wherein at least the receipt challenge and the transaction signing challenge are included in an output of the one or more outputs that are consumable independently of the discretionary signature.

15. The one or more outputs: a summary hash computed by hashing a concatenated string including a single hash or multiple hashes of the first lower level contribution and a single hash or multiple hashes of the second lower level contribution, the usable output being consumable independently of the summary hash.

15. The method according to any one of claims 1 to 14.

16. 1. A computer-implemented method for recording in one or more blockchain transactions contributions to a work by contributors having respective levels in a defined hierarchical structure, in which first and second lower level contributors provide first and second lower level contributions, respectively, to a mid-level contributor, which mid-level contributors provide mid-level contributions to a higher level contributor in response to the first and second lower level contributions, the method comprising: At a computing device of the mid-level contributor, generating or modifying a blockchain transaction, the generated or modified blockchain transaction comprising: a first receipt of said first lower level contribution; a second receipt of the second lower level contribution; and The mid-level contributor's transaction signature and one or more inputs including: an acknowledgement challenge for said intermediate level contribution; a transaction signing challenge for the higher-level contributor; and Discretionary Signature and one or more outputs including the discretionary signature is generated by applying a signing function to the private key of the intermediary-level contributor and the intermediary-level contribution or a hash thereof; at least the receipt challenge and the transaction signature challenge are included in an output of the one or more outputs that is usable independently of the discretionary signature; method.

17. The one or more outputs: a summary hash computed by hashing a concatenated string including a single hash or multiple hashes of the first lower-level contribution and a single hash or multiple hashes of the second lower-level contribution, the usable output being usable independently of the summary hash.

17. The method of claim 16.

18. 18. A method according to claim 16 or 17, comprising the step of: a second intermediate level contributor providing a second intermediate level contribution to the higher level contributor; The one or more inputs of the blockchain transaction may further include: a third receipt of a third lower level contribution; a transaction signature of the second intermediary level contributor; The one or more outputs may further include: an acknowledgement challenge for the second intermediate level contribution; and Includes a second discretionary signature, the challenge for at least the second intermediate level of contribution is included in the usable output of the one or more outputs or another usable output of the one or more outputs; the second discretionary signature is generated by applying a signing function to a single or multiple hash of the second interim level contribution and to the private key or another private key of the interim level contributor. method.

19. 20. The method of claim 18, wherein the one or more outputs include a second summary hash, the second summary hash being computed by hashing a pre-image, the pre-image including a single hash or multiple hashes of the third lower level contributions.

20. The one or more inputs of the blockchain transaction further include: a fourth receipt of a fourth lower level contribution; the pre-image hashed to compute the second summary hash is in the form of a second concatenated string including the single hash or multiple hashes of the third lower level contribution and the single hash or multiple hashes of the fourth lower level contribution.

20. The method of claim 19.

21. 21. The method of any one of claims 16 to 20, wherein the discretionary signature is included in one or more non-usable outputs of the blockchain transaction.

22. 22. The method of claim 21 when relying on claim 17, wherein the one or more non-usable outputs include the summary hash.

23. 23. The method of claim 21 or 22, wherein the one or more unusable outputs also include a single hash or multiple hashes of the first lower level contribution and a single hash or multiple hashes of the second lower level contribution.

24. 21. The method of claim 16, wherein the discretionary signature is included in the available output, the transaction signature challenge is a function operand of a multi-signature check opcode, and the discretionary signature is a dummy operand of the multi-signature check opcode.

25. 25. The method of claim 24 when relying on claim 17, wherein the summary hash is included in the available output as a dummy operand of the multi-signature check opcode.

26. 26. The method of claim 24 or 25, wherein a single hash or multiple hashes of the first lower level contribution and a single hash or multiple hashes of the second lower level contribution are also included as dummy operands of the multi-signature check opcode.

27. 27. The method of any one of claims 1 to 26, comprising the step of transmitting the blockchain transaction to a node of a blockchain network where it is processed for recording in the blockchain.

28. 27. The method of any one of claims 1 to 26, comprising sending the blockchain transaction to an off-chain system for processing.

29. The higher level contributor generates a second blockchain transaction to spend the available output, the second blockchain transaction comprising: A receipt of said intermediate level contribution; The higher-level contributor's transaction signature and one or more inputs including: a further receipt challenge for the higher level contribution of said higher level contributor; a transaction signing challenge for the recipient of said higher level contribution; Further discretionary signing and one or more outputs including the further discretionary signature is generated by applying a private key of the higher-level contributor and a single or multiple hashes of the higher-level contribution and a signing function.

29. The method of any one of claims 1 to 28.

30. 30. The method of claim 29, wherein the one or more outputs of the second blockchain transaction include a further summary hash computed by hashing a further concatenated string, the further concatenated string including the summary hash and a single hash or multiple hashes of the contributions of the higher level contributors.

31. 31. A method as claimed in claim 29 or 30, wherein the higher level contribution is in the form of a final work in response to all contributions received from all contributors in the hierarchical structure, and the further proof of receipt challenge is satisfied by proof of receipt of the final work.

Images