Transparent Blockchain Database

Abstract

1. A computer-implemented method comprising: obtaining information describing the characteristic; dividing the information into at least two data items describing the characteristic with at least two different levels of precision; obtaining a set of data items for generating a Merkle tree, the set of data items including at least two data items; generating two or more leaf nodes of the Merkle tree by hashing each data item in the set of data items, the Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes; and storing at least one of the Merkle tree and instructions for generating a Merkle tree from the set of data items.

Description

[Technical field]

[0001] The present disclosure relates to a method for storing data in a secure manner. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained and publicly published at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). The blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than the so-called "coinbase transaction", points back to a preceding transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are further described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves multiple nodes each competing to perform a "proof of work", i.e., solving a cryptographic puzzle based on a representation of a prescribed set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and that the publication of blocks may be accomplished through the mere publication of block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or time ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes to data in transactions. There is no pre-specified limit on the maximum data capacity that can be stored within a single transaction, and therefore increasingly complex data may be incorporated. For example, this may be used to store electronic documents, or audio or video data, in the blockchain.

[0004] Nodes of the blockchain network (often referred to as "miners") perform a distributed transaction registration and validation process, which will be described in more detail later. In summary, during this process, a node validates a transaction and inserts the transaction into a block template for which the node attempts to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus allowing each node to record a new block on the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes of the network to be propagated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into a new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or incorporated into a block. Assuming the transaction is validated and thereby accepted onto the blockchain, then the transaction (including any user data) remains so registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," which distributes a certain amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes acting as agents of the network, and are encouraged to report and block fraudulent activity. Widespread publication of information allows users to continuously audit the execution of nodes. Mere publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element that specifies an amount of digital assets derivable from the advancing sequence of transactions. A consumable output may be called a UTXO (an “unspent transaction output”). An output may further comprise a locking script that specifies conditions for future redemption of the output. A locking script is a predicate that specifies the conditions required to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) may comprise a pointer (i.e., a reference) to such output in a preceding transaction and further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, when a pair of transactions is considered, we refer to them as a first transaction and a second transaction (or a “target” transaction). The first transaction comprises at least one output that specifies an amount of digital assets and comprises a locking script that specifies one or more conditions for unlocking the output. The second, target transaction comprises at least one input comprising 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 blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node is that the unlocking script meets all of one or more conditions specified in the locking script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another, earlier, valid transaction. Any node that finds a target transaction invalid according to any of these conditions will neither propagate it (as a transaction for registering a valid, but possibly invalid, transaction) nor include it in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction specifies the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to the complete account balance. The current state of every account is stored in the blockchain and constantly updated by separate nodes.

[0009] The term "transparent database" is explained, for example, in Peter Wayner, Transparent Databases 2nd Edition, "Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy", January 8, 2009. A transparent database can be considered to refer to a design database that is privacy preserving and secure. A transparent database protects personal data from insider attacks, and in some examples of transparent databases, even database administrators and authorized persons cannot access personally identifiable data. The term "transparent database" has not been officially defined. A transparent database is called transparent because it allows some light to escape the system while still providing a layer of confidentiality. The concept of a transparent database is more of a goal than a clear predicate. A transparent database design is one that minimizes risks to privacy and confidentiality while maintaining usability and functionality. Wayner shows how a transparent database should be constructed using several techniques.

[0010] The Linux password file may be considered to have a transparent database design, but predates Wayner's coining of the term "transparent database". The Linux password file is described in "Practical UNIX and Internet Security, 3rd Edition" by Simon Garfinkel, Gene Spafford, and Alan Schwartz, https: / / www.oreilly.com / library / view / practical-unix-and / 0596003234 / ch04s03.html [accessed September 2, 2021], and "Understanding / etc / shadow file format in Linux by Vivek Gite, https: / / www.cyberciti.biz / faq / understanding-etcshadow-file / [accessed September 29, 2021].

[0011] In systems prior to the Linux password file, computer systems stored the passwords of system users in plain text in a file. This was a crucial vulnerability since anyone with access to the file (or a hacker who could circumvent the file access controls) could access all users' passwords. To address this vulnerability the Linux password file system was designed. The system saves a salted hash of the password instead of the plain text. When a user enters their password, the system calculates a hash of the entered value, compares such hash to a hash value stored by the system, and if they match the system grants access. Now, even if the password file is accessed, only the salted hash of the password can be accessed. To obtain the password, an attacker would need to find a preimage of the stored hash value, which is a trial and error process that can take a long time. Note that the system is still required to enforce access rights to the file, but the system is now much more secure against insider attacks as well as access rights violations. The password is stored in $<id of hashing algorithm>$<salt>$<salted password hash> It is saved in the system in this format.

[0012] First is the ID of the hashing algorithm used to create the hash (SHA256, SHA512, etc.), then the salt value used, then the hash of the salted password, i.e. Hash(Password|Salt). [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] Peter Wayner, Transparent Databases 2nd Edition, "Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy", January 8, 2009 [Non-Patent Document 2] Simon Garfinkel, Gene Spafford, and Alan Schwartz, "Practical UNIX and Internet Security, 3rd Edition," https: / / www.oreilly.com / library / view / practical-unix-and / 0596003234 / ch04s03.html [Non-Patent Document 3] “Understanding / etc / shadow file format in Linux by Vivek Gite”, https: / / www.cyberciti.biz / faq / understanding-etcshadow-file / Summary of the Invention [Means for solving the problem]

[0014] Some techniques that can be used to build a transparent database can be considered as follows: 1. Encryption and hashing: For example, using one-way hash functions and / or encryption to maintain privacy. 2. Ignorant: The data is scrambled by the user / client, not the database server. In some instances, the scrambled data may travel across a network where the transparent database never sees the actual information hidden inside. 3. Minimization: This may comprise storing a base level of information. A minimal amount of data is retained while still providing functionality. For example, if the zip code for an address is fairly large, there is no need to retain the entire address. 4. Misdirection: Using "fake" data to obscure and hide real information in a way that does not allow an attacker to determine it among the fake, false data. This can be especially useful when encryption is not enabled. 5. Equivalence: Replacing and obfuscating sensitive information data with functionally equivalent data. For example, rather than a person's exact height, labels such as "short," "average," and "tall" may be used. These labels may be determined based on the numerical range within which the value describing the characteristic falls. 6. Quantization: Quantizing values ​​while providing a higher level of access to precise values. Reducing the precision of a number or value can add privacy and security. For example, latitude and longitude may be recorded in degrees only, while obscuring minutes and seconds.

[0015] A transparent database may have one or more of the six attributes listed above. Note that a transparent database may not have every possible attribute. Some transparent databases may mix several of the attributes listed above.

[0016] In an example, Merkle trees are used when publishing sensitive data to the blockchain: publishing data to the blockchain provides inconsistency evidence that it is computationally infeasible for this data to have been created (or fabricated) at a later time, i.e., the publication may not have been created after the block was mined.

[0017] According to one aspect disclosed herein, a computer-implemented method is provided that comprises obtaining information describing a characteristic. The method also comprises dividing the information into at least two data items describing the characteristic with at least two different levels of precision, and obtaining a set of data items for generating a Merkle tree, the set of data items including at least two data items. The method further comprises generating two or more leaf nodes of the Merkle tree by hashing each data item in the set of data items, the Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes, and storing at least one of the Merkle tree, instructions for generating a Merkle tree from the set of data items.

[0018] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be put into effect, reference will be made, by way of example only, to the accompanying drawings, in which: [Brief description of the drawings]

[0019] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates generally some examples of transactions that may be recorded in a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic mock-up of an example user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of some node software for processing transactions. [Diagram 5] FIG. 2 is an example diagram of a Merkle tree. [Figure 6] FIG. 2 is an example diagram of a message flow. [Figure 7] FIG. 2 is an example diagram of a Merkle tree. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Example System Overview 1 illustrates an example system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is strongly connected to the other blockchain nodes 104.

[0021] Each blockchain node 104 comprises a peer's computing equipment, with various of the nodes 104 belonging to different peers. Each blockchain node 104 comprises a processing device comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application specific processors, and / or other equipment, such as field programmable gate arrays (FPGAs), and application specific integrated circuits (ASICs). Each node also comprises a memory, i.e., computer readable storage in the form of one or more non-transitory computer readable media. The memory may comprise one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives.

[0022] The blockchain 150 comprises a chain of blocks of data 151, a respective copy of which is maintained at each of a number of blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, a transaction in this context referring to a certain kind of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or transaction scheme. A given blockchain uses a certain transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing a quantity of a digital asset, one example of a property being the user 103 to which the output is cryptographically locked (requiring that user's signature or other solution in order to be unlocked and thereby redeemed or spent). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

[0023] Each block 151 also has a block pointer 155 that points back to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than coinbase transactions) has a pointer back to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 goes all the way back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0024] Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and to store respective copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set (i.e., a "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and that the node 104 should be obligated not to accept any other transactions attempting to consume the same output.

[0025] For a given current transaction 152j, the (or each) input comprises 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 "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily imply a transfer of financial assets, although it is certainly one common use. More generally, consuming may be described as spending an output or allocating such output to one or more outputs in another transaction that is ahead of it. In general, a preceding transaction may be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i does not necessarily need to exist at the time that a current transaction 152j is created and even sent to the network 106, but a preceding transaction 152i needs to exist and be valid for the current transaction to be valid. Thus, "preceding" in this specification refers to a predecessor in a logical sequence, linked by a pointer, not necessarily in terms of the time of creation or sending in the temporal sequence, and therefore does not necessarily exclude a transaction 152i, 152j from being created or sent out of order (see the discussion below on orphan transactions). A preceding transaction 152i may equally be referred to as an antecedent transaction or a predecessor transaction.

[0026] The input of the current transaction 152j also comprises an input permission, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input of the preceding transaction 152i to the new user or entity 103b as specified 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 or entities (one of which may be the original user or entity 103a to give change). In some cases, a transaction can also have multiple inputs to collect together amounts from multiple outputs of one or more preceding transactions and to redistribute one or more outputs of the current transaction.

[0027] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an institution, wants to establish a new transaction 152j (either manually or by an automated process adopted by the party), the establishing party sends the new transaction from its computer terminal 102 to a recipient. The establishing party or the recipient finally sends this transaction to one or more of the blockchain nodes 104 (today generally servers or data centers, but in principle could be other user terminals) of the network 106. It is not excluded that the party 103 that establishes the new transaction 152j may send the transaction directly to one or more of the blockchain nodes 104, and in some examples may not send it to a recipient. The blockchain nodes 104 that receive the transaction check whether the transaction is valid according to the blockchain node protocol applied in each of the blockchain nodes 104. Blockchain node protocols typically require that blockchain nodes 104 check that a cryptographic signature in a new transaction 152j matches an expected signature, which depends on a previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise checking that a cryptographic signature or other permission of party 103 included in the input of the new transaction 152j matches a condition specified in the output of a previous transaction 152i that the new transaction consumes (or "allocates"), which condition typically comprises at least checking that a cryptographic signature or other permission in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be specified, at least in part, by a script included in the output of the previous transaction 152i.Alternatively, it may simply be fixed by the blockchain node protocol alone, or may result from a combination of these. Either way, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol, and so forward the new transaction 152j to one or more further nodes 104, and so on. In this manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0028] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it has yet to be validly redeemed according to the blockchain node protocol by the input of another transaction 152j that sits ahead of it. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if not valid, the transaction 152j is not propagated (unless it is flagged as invalid and propagated for warning purposes) or recorded in the blockchain 150. This protects against double spending, where a transactor tries to allocate the output of the same transaction more than once. An account-based model, on the other hand, protects against double spending by maintaining an account balance. Again, since there is a defined order of transactions, at any one time the account balance has a defined single state.

[0029] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process usually called mining, which is supported by "proof of work". At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 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 and hashed to a representation of the ordered pool of pending transactions 154, the output of the hash then satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has some predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, other types are not excluded. A property of a hash function is that it has an output that is unpredictable with respect to its input. This search can therefore only be performed by brute force, and therefore consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0030] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to check that the solution satisfies the conditions on the output of the hash). The first blockchain node 104 accepts the block and thus propagates it to the threshold consensus of other nodes enforcing the protocol rules. The ordered set of transactions 154 is then recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. A block pointer 155 is also assigned for the new block 151n to point back to the previously created block 151n-1 in the chain. A significant amount of effort, e.g., in the form of hashes, required to create a proof-of-work solution signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction, otherwise known as double spending. Once created, blocks 151 cannot be modified as they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on the blocks 151. This therefore provides an immutable public ledger of transactions as transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106.

[0031] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of transactions 154 that have not yet been issued at any given time, depending on when they started searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, the current pool of unissued transactions 154 is updated. The blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unissued transactions 154, and so on. There is also a protocol to resolve any possible "forks," which are cases when two blockchain nodes 104 solve their puzzles within a very short time of each other, causing conflicting views of the blockchain to be propagated between the nodes 104. In essence, whichever prong of the fork extends the longest becomes the final blockchain 150. Note that this should have no impact on users or agents of the network, since the same transactions appear in both forks.

[0032] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the additional amount of accepted digital assets into a new special type of transaction that distributes a specified additional amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It usually forms the first transaction of a new block 151n. To comply with protocol rules that allow this special transaction to be redeemed later, the proof of work signals the node's intent to construct the new block. Blockchain protocol rules may require a redemption period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is typically referred to as a "transaction fee" and is described below.

[0033] Due to the resources involved in transaction validation and issuance, typically at least each of the blockchain nodes 104 takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal or a group of user terminals networked together.

[0034] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform its respective one or more roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action ascribed to a blockchain node 104 herein may be performed by software running on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0035] A computing device 102 of each of a number of parties 103 in the role of consuming users is also connected to the network 101. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0036] Some or all of the parties 103 may be connected as part of a different network, for example, a network layered on top of the blockchain network 106. Users of the blockchain network (often called "clients") may be said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the required role of a blockchain node. Instead, each party 103 may interact with the blockchain network 106, and thereby utilize the blockchain 150, by connecting to (i.e., communicating with) the blockchain node 106. Two parties 103 and their respective devices 102 are illustrated for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an entity. Purely by way of example, first party 103a is referred to herein as Alice and second party 103b is referred to as Bob, although it will be appreciated that this is not limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

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

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

[0039] The client application 105 comprises at least a "wallet" function. It has two main functionalities. One of them is to allow each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that he or she currently owns. In an output-based system, this second functionality comprises reconciling the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0040] NOTE: Although various client functionalities may be described as being integrated within a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented as a set of two or more separate applications, for example interfacing via an API or one plugging into 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. While the following is described with respect to a client application 105, it will be appreciated that this is not limiting.

[0041] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the financial management function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction to see which of the respective parties 103 are recipients (or, in an embodiment, to certainly check the transactions of other parties in the blockchain 150, since the blockchain 150 is a public mechanism that gives credibility in transactions, in part through its public visibility). The financial management function on each computing device 102 is configured to organize and send the transactions 152 according to a transaction protocol. As presented above, each blockchain node 104 runs software configured to validate the transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol runs along with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0042] When a given party 103, for example Alice, wants to send a new transaction 152j to be included in the blockchain 150, she organizes the new transaction according to the relevant transaction protocol (using a money management function in Alice's client application 105). Alice then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j satisfies some conditions to be "valid", examples of which will be explained in more detail shortly. In some transaction protocols, the conditions for validity may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be specified by a combination of the script and the node protocol.

[0043] On condition that the newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, then assuming the transaction 152j is valid, this means that it will soon be propagated throughout the entire network 106.

[0044] Once admitted into the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle on the latest version of their respective pool of 154 that contains the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools of transactions 154, but whoever gets there first defines the set of transactions that will be included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that contains Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 has a pointer back to an earlier transaction, so that the order of transactions is also immutably recorded.

[0045] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views of which instances are "valid" before an instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance not published in block 151).

[0046] An alternative type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol as part of the account-based transaction model. In the account-based case, each transaction specifies the amount to be transferred not by referencing back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to the complete account balance. The current state of every account is stored and constantly updated by the nodes of the network, separate from the blockchain. In such a system, transactions are ordered using the account's running transaction statement (also called the "position"). This value is signed by the sender as part of their 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 back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0047] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a basic data structure of the blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limiting to all possible embodiments. Note that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented in other exemplary blockchain networks.

[0048] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure with one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for an input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO contains a value that specifies an amount of digital assets. It represents a set number of tokens on a distributed ledger. A UTXO may also contain a transaction ID of the transaction from which the UTXO came, among other information. The transaction data structure may also comprise a header 201, which may comprise indicators of the sizes of the input fields 202 and the output fields 203. The header 201 may also include an ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

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

[0050] At the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106, the preceding transaction Tx0 may already be valid and included in a block 151 of the blockchain 150. The preceding transaction Tx0 may already be included in one of the blocks 151 at that time, or may still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network 106 together, or even Tx0 can be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "subsequent" as used herein in the context of a sequence of transactions refer to the order of the transactions in the sequence, as defined by transaction pointers specified in the transactions (such as which transactions point back to which other transactions). They may be equivalently replaced with "predecessor" and "successor," or "predecessor" and "descendant," "parent," and "child," etc., which does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (predecessor transaction or "parent") is not valid until and unless the parent transaction is valid. A child that arrives at a blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, an orphan may be discarded or may be buffered for some time to wait for the parent.

[0051] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying an amount of digital assets represented by the UTXO, and a locking script that specifies 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 an amount to a particular party (the beneficiary of the transaction it is included in). That is, the locking script typically specifies an unlocking condition that comprises a condition that the unlocking script in the input of the following transaction comprises a cryptographic signature of the party to whom the preceding transaction is locked.

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

[0053] So, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A Locking script that requires [Checksig P A]. [Checksig P A ] is the public key P from Alice’s public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 comprises a pointer that points back to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Tx1's input 202 comprises an unlocking script that comprises Alice's cryptographic signature, which is created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). <Sig P A The data that needs to be signed by Alice to provide a valid signature (i.e., the "message") may be specified by a locking script, or by a node protocol, or by a combination of these.

[0054] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and the unlocking script together to check if the unlocking script satisfies the conditions specified in the locking script (where the conditions may comprise one or more criteria). In an embodiment, this comprises concatenating the two scripts, i.e. <Sig P A > <P A > || [Checksig P A ] where "||" denotes concatenation, "<...>" denotes the location of data on the stack, and "[...]" is a function provided by the locking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts could be run one after the other using a common stack. Either way, when run together, the scripts will use Alice's public key P as included in the locking script in the output of Tx0. A , to authenticate that the unlocking script in Tx1's input 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 an embodiment, the signed data comprises the entirety of Tx1 (so a separate element specifying the signed portion of the data in the clear need not be included, since it is already inherently present).

[0055] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then given Alice's public key and the message in plaintext, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically comprises hashing the message, signing that hash, and tagging this as a signature on the message, thus allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data, or part of a transaction, or the like, can, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0056] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to an ordered pool of pending transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already forms a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a prescribed order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 in which transactions 152 have been spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in the blockchain 150.

[0057] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore, such a transaction is neither propagated nor included in block 151.

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

[0059] In practice, Alice also typically needs to include a fee for Bitcoin nodes 104 that successfully include Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain nodes 104 and thus, although technically valid, may not be propagated or included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept the transaction 152 if they do not wish to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any difference between the total amount pointed to by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the blockchain node 104 that issues the transaction. For example, a pointer to UTXO0 is only an input to Tx1, which has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated (or consumed) by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0060] Alice and Bob's digital assets consist of the UTXOs that were locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored somewhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the money management function in the client application 105 to collate together the values ​​of all the various UTXOs that are locked to each party and have not yet been spent in another transaction ahead of them. It can do this by querying a copy of the blockchain 150 as stored in any of the Bitcoin nodes 104.

[0061] Note that script code is often expressed generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to specific opcodes in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of a locking script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0062] Typically, the input for a transaction is a public key P AThe signature includes a digital signature corresponding to the . In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs, and some or all of the transaction outputs. The specific part of the outputs it signs depends on the SIGHASH flag, which is a four-byte code typically included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0063] The locking script is sometimes referred to as a "scriptPubKey", referring to the fact that it typically comprises the public key of the party to which the respective transaction is locked. The unlocking script is sometimes referred to as a "scriptSig", referring to the fact that it typically provides the corresponding signature. However, more generally, it is not required in all applications of the blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to specify any condition or conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0064] Side Channels As shown in FIG. 1, the client applications on each of Alice's and Bob's computing devices 102a, 120b, respectively, may include additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (either induced by a party or a third party). The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction being (yet) registered on the blockchain network 106 or proceeding on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may be missing one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0065] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a variety of networks, such as a local area network, such as a mobile cellular network, or a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 as referenced elsewhere herein may comprise any link or links over one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Thus, when it is said that Alice and Bob exchange some pieces of information or data, etc., over the side channel 107, it should be noted that this does not necessarily imply that all these pieces of data must be sent over exactly the same links, or even the same type of network.

[0066] Client Software 3A illustrates an example implementation of a client application 105 for implementing embodiments of the disclosed techniques. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the lower-level transaction-related functionality of the client 105, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via a side channel 301, and / or sending transactions to one or more nodes 104 to be propagated through the blockchain network 106, as will be described in more detail shortly, in accordance with the techniques described above.

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

[0068] NOTE: Although various functionalities herein may be described as being integrated into the same client application 105, this is not necessarily limiting, and instead they may be implemented in a set of two or more separate applications, e.g., one plugging into the other or interfacing via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between two or more applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made elsewhere herein to a single or given application 105, etc., it will be appreciated that this is for the sake of example only, and more generally that the described functionality may be implemented in any form of software.

[0069] 3B provides a mock-up of one example of a UI 500 that may be rendered by a user interface (UI) layer 402 of a client application 105a on Alice's device 102a. It will be appreciated that a similar UI may be rendered by a client 105b on Bob's device 102b or by any other party's client.

[0070] 3B shows the UI 500 from Alice's perspective. The UI 500 may comprise one or more UI elements 501, 502, 502 rendered as separate UI elements via user output means.

[0071] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, etc. User input means are arranged to enable a user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options, such as by clicking or touching the UI element on the screen, or by speaking the name of the desired option (note that the term "manually" as used herein is intended only to contrast with automatic and is not necessarily limited to the use of one or more hands).

[0072] Alternatively or additionally, the UI element may comprise one or more data entry fields 502. These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received orally, e.g., based on voice recognition.

[0073] Alternatively or additionally, the UI element may comprise one or more information elements 503 output for outputting information to the user. For example, this / these may be rendered on a screen or audibly.

[0074] It will be appreciated that the particular means of rendering the various UI elements, selecting options, and inputting data are not material. The functionality of these UI elements will be described in more detail shortly. It will also be appreciated that the UI 500 shown in FIG. 3 is merely a stylized mockup and may in fact comprise one or more additional UI elements that are not shown for simplicity.

[0075] Node Software FIG. 4 illustrates an example of node software 450 operated on each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may operate the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may operate node software including, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of a transaction 152 and process them according to a node protocol. Transaction 152j (Tx j ) is passed to another preceding transaction 152i (Tx m-1 When a transaction is received with an input pointing to an output (e.g., a UTXO), the protocol engine 451 j The protocol engine 451 also identifies the unlocking script in the Tx j Based on the pointer in the input of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine derives Tx i Alternatively, Tx i , may not yet have been published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i Either way, the script engine 451 can extract Txi The script engine 452 then identifies the locking script among the referenced outputs of the script.

[0076] Therefore, the script engine 452 executes the Tx i Locking script, and Tx j 2. For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same can apply to any pair of transactions. The script engine 452 runs the two scripts together as previously described, which includes placing data on and popping data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0077] By running the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria specified in the locking script - i.e., whether the locking script "unlocks" the output contained therein. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script satisfies one or more criteria specified in the corresponding locking script, it returns the result "true". Otherwise, the script engine 452 returns the result "false".

[0078] In the output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. j the aggregate value of the Digital Assets specified in the output of Tx does not exceed the aggregate value indicated by its input; iThere are also one or more further protocol-level conditions evaluated by protocol engine 451 that must also be satisfied, such as that the output pointed to by Tx has not already been consumed by another valid transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions, and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. j is indeed enabled, the decision engine 454 j 151. The node 450 may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to Tx j , and the propagation module 455P transmits the Tx j Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to issue a transaction only if the transaction is both valid and has sufficient remaining transaction fees.

[0079] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level activation of a signature and an additional positive output of a smart contract (where both individual outcomes are true, the overall outcome is considered to signal true).

[0080] Transparent Blockchain Database In some instances, a transparent database may be considered to have a "neutral switch" for data. A transparent database may be used in some instances to move information without seeing the important bits. An intelligent client on the edge of the network may perform the encryption, i.e., scrambling most of the information before it leaves the client. This is explained in Peter Wayner, Transparent Databases 2nd Edition, "Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy", January 8, 2009, which further states that the advantages of a transparent database can be "security (especially against insider threats), operating system independence, privacy, freedom from demands, simplicity, mixed access (different levels of access), speed, distributed workload (encryption can be done by the client and the server does not even have to decrypt it). These advantages are not guaranteed for every use case."

[0081] Example use case scenarios for transparent databases given in Peter Wayner, Transparent Databases 2nd Edition, "Confusion, Misdirection, Randomness, Sharing, Authentication And Steganography To Defend Privacy", January 8, 2009 include the following: A database that conceals the location of warships from the enemy while simultaneously providing accurate information to warships with proper authorization. ·Anti-rape database that identifies trends without containing any personal information. · A babysitter scheduling service that matches parents with available sitters while protecting the sitter's identity and location. · Department store database that monitors customer discretion. · A private billing system that detects fraud without revealing any information. -An anti-cheating poker game for the internet. · Pharmacy database to prevent dangerous drug interactions while keeping medical records secure. · A tool for travel agents to protect their clients from stalkers and kidnappers. · A securities exchange transaction mechanism designed to stop insider trading. Website log file tools that provide an accurate count of visitors while protecting visitor identities. · Credit card databases to protect sensitive e-commerce transactions. · Patent search tools that do not reveal the nature and focus of the search. · Electronic bulletin boards for conferences that route messages without aiding stalkers. A tool to check the radon levels in your home without having to keep any personal information. · Anti-Money Laundering Database. Privacy-preserving car tracking. XML encoding and decoding. Fuzzy and inexact matching.

[0082] The methods described herein may be applied to any of the possible use cases listed above.

[0083] When providing a transparent database system, privacy measures that render the system unusable would result in either missing these measures altogether or replacing the system with usable, but insecure, alternatives. The examples described herein provide a usable transparent database system. Although the transparent database design assumes that access control policies are enforced, even if these policies are violated, sensitive data is still protected because it is stored as ciphertext or hash values.

[0084] In an example, Merkle trees are used when publishing sensitive data to the blockchain: publishing data to the blockchain provides inconsistency evidence that it is computationally infeasible for this data to have been created (or fabricated) at a later time, i.e., the publication may not have been created after the block was mined.

[0085] In some examples, data (information) is split into data fields (data items). Each data field is then hashed separately and the hashes are mapped to the leaves of a Merkle tree. A root value for the tree may also be calculated. The root value may be inserted as a value inserted into the transaction. This provides confidentiality for all data fields. At the same time, selective disclosure to individual data fields and linking them to the root is possible without having to disclose the entire data. In some examples, one or more of the above six attributes of a transparent database are achieved by using a Merkle tree.

[0086] In some instances, transparent database techniques are applied when publishing invoice data on the blockchain. It may be desirable to protect shopper privacy even from the prying eyes of insiders while publishing invoice data on a public ledger, which is where transparent database techniques can help.

[0087] In some examples, the invoice data is split into fields (data items) where each field is hashed separately, and these hashes are used to construct a Merkle tree. The Merkle root is signed by the seller and inserted into the blockchain transaction. The tree structure allows for selective disclosure of invoice data fields without having to disclose the entire invoice data. As described below, the tree structure can be used to achieve any of the six transparent design attributes described above.

[0088] The following examples focus on publishing data to a blockchain, but may equally apply whenever data is notarized (hashed and signed). For example, the data in an electronic passport is notarized by a national authority. This data may be stored in a Merkle tree as disclosed herein. In some examples, the Merkle tree is used to enable selective disclosure of data fields.

[0089] A Merkle tree may be used in some examples to provide all six attributes of the transparent database described above, however, in some embodiments, fewer than six attributes may be provided.

[0090] 5 illustrates an example Merkle tree 500. Given some data d, which may comprise sensitive data, the following example method may be used to construct the Merkle tree and, optionally, to further publish the Merkle root in a blockchain transaction.

[0091] In the Merkle tree, fields d1, d2, ..., d T In the example of FIG. 5, T=8. In some examples, data fields d1, d2, ..., d T One or more of may be generated based on another data field or from a random value. T may be any value 2 n where n is an integer value. Each data field may be hashed and then each hash may be used as a leaf of the Merkle tree. If there are not enough leaves provided by the hash, the leaves may be repeated. The leaves may be repeated until there are enough leaves to fill the lower tier of the Merkle tree. In the example of FIG. 5, the leaves are repeated until eight leaves are provided. Iterating the leaves may be done by, for example, Repeating arbitrarily placed leaves, e.g. the first or last leaf, Iterating over the first generated leaf, To iterate over leaves at some position in a Merkle tree (e.g., to iterate over the last and penultimate leaves of a Merkle tree, to iterate over the first three leaves of a Merkle tree, etc.), Different repeating patterns may be used.

[0092] The root of the Merkle tree may then be calculated, having a root value R. In instances where transactions are stored on a blockchain, the root value R may be inserted into the blockchain transaction.

[0093] The authorized party is responsible for the data field d of data d. iThe authorized party may also store instructions for constructing the Merkle tree. The instructions may comprise information describing how to construct the Merkle tree. The instructions may comprise a number of leaf nodes to be used in the Merkle tree. The instructions may comprise a mapping of data fields and corresponding hashes of the data fields to leaf nodes of the Merkle tree. The instructions may comprise a description of the hashes used to generate the hashed values ​​from the respective data fields. The instructions may comprise an indication of whether any of the nodes of the tree are used to flag the Merkle tree as comprising misleading data, quantization data, or equality data (the use of these flags is described further below).

[0094] The uploaded data is a specific value d i = V, this can be done using Merkle proofs without the need to reveal any other data fields. For example, a Merkle proof of d4 is 1|2 ,h 5-8}.

[0095] Using Merkle trees as described above provides a hashing transparent database design technique. Furthermore, when data is hashed by an authorized party and is not on a database or centralized server, a ignorant transparent database design technique is provided. Furthermore, for a particular value d i The tree structure allows for a minimization of the data that needs to be revealed when showing =V, thus providing a transparent database design technique of data minimization.

[0096] To apply the misdirection, "fake" data (misdirection data) can be used to create a Merkle tree. The root value of the Merkle tree created using the fake data can be inserted into the blockchain transaction. To flag the data as fake, one of the tree leaves is selected to be used as the flag. For example, the first leaf is the hash value of the string "misdirection", i.e., h1=Hash(misdirection). A party with access to the tree preimage knows that the data is misdirected. An outside observer seeing the transaction carry the Merkle tree root cannot distinguish between fake data and real data. It is possible to prove that the data is misdirected by providing a Merkle proof of the flag leaf.

[0097] To hide the fact that the data is fake, the cheat flag leaf can be hidden when providing a Merkle proof of the other leaves. To do this, we take steps to ensure that the pair leaf of the flag leaf is the hash of a random value. In the example where the first leaf is the hash value of the string "cheat", i.e., h1=Hash(cheat), the pair leaf is h2=Hash(rand). Then, h 1|2 Consider an example to provide a Merkle proof of a data field d3, containing: =Hash(h1|h2). If the range of h2 is limited, it may be feasible to launch a brute force attack to find if h1 is a malformed flag. This is explained further below with respect to domain-limited vulnerabilities.

[0098] To enforce equivalence, the sensitive data can be obscured with a similar value that is functionally equivalent. For example, a person's exact height can be replaced with "short," "average," or "tall." This technique converts the leaf into a hash of the equivalent value, i.e.,

[0099]

number

[0100] can be applied by setting

[0101]

number

[0102] d i Depending on the use case, sometimes both values, i.e.

[0103]

number

[0104] , d i It can be useful to include in the tree a leaf with hash(d i ) and another leaf is

[0105]

number

[0106] is set to.

[0107] Quantization can be used to reduce the precision of numbers and values ​​to add privacy and security without destroying usability. i =d i|1 |...|d i|m The technique can be applied by making i|1 holds the most significant bits (i.e., the less precise value), and d i|m holds the least significant bits. The hash of each subfield, h, is used as a leaf in the tree. i|j When it is desired to provide quantized values, d i|1 and a Merkle proof of it can be provided. When it is desired to provide a precise value, di =d i|1 |...|d i|m , and Merkle proofs for these leaves can be provided.

[0108] Using Merkle trees to store information on a blockchain as described above has many possible use cases. An example use case in which invoices are published to a blockchain is considered next, but it should be noted that the method can be used to store any type of data other than invoices.

[0109] By issuing invoices on the blockchain, the immutability of the blockchain can be used to guarantee the integrity of the invoice data record. The older this proof is, the stronger its integrity becomes. Keeping a record of purchased product descriptions, terms, and terms of sale ensures that sellers and buyers can protect their rights in case of audits, discrepancies, or cancellations.

[0110] An example is considered next that starts with a seller / website (first party, Alice 103a) that uses blockchain to register purchase transactions and invoices. In this example, there are at least two actors: 1. Seller / Online Shopping Website (First Party, Alice 103a) 2. Customer / Buyer (Second Party, Bob 103b)

[0111] Alice 103a saves records of customer purchase orders and invoices on the blockchain. In some examples, customers pay for their purchases in Bitcoin, and proof of payment and invoices are recorded in the same blockchain transaction, although other suitable types of payments and transactions other than Bitcoin may be used. In some examples, Alice 103a may have a digital certificate from a public key infrastructure (PKI) to attest to the authenticity of Alice's signature.

[0112] According to some examples, Alice 103a maps the invoice data to a Merkle tree and calculates the root value of the Merkle tree. Alice 103a may then sign the root value of the Merkle tree using Alice's private key. Alice 103a may also sign the payment related data using Alice's private key. Alice 103a may then insert the signature, the signed message, and optionally Alice's certificate into a blockchain transaction. Alice creates a transaction template with the input fields empty and sends the incomplete transaction to the customer, Bob 103b. Alice may also send the invoice data fields to Bob 103b. Bob 103b may then perform checks, complete the transaction by filling in the input fields, and send the complete transaction back to Alice 103a or to the blockchain network. Alice 103a may then send the transaction to the blockchain network.

[0113] 6 illustrates an example method for publishing data d to a blockchain network 106. The data d may comprise, for example, invoice data.

[0114] In 661, Alice 103a maps data d to a Merkle tree. The data d may comprise invoice data. In some examples, the invoice data may comprise one or more of the following data fields: Seller identification information (e.g. one or more of the following: name, contact details, address, registration number, etc.); Date of purchase, · The products being purchased (e.g., one or more of the following: details, description, quantity, price of each individual product, etc.); · Method of payment; Amount (e.g., one or more of the following: total amount to be paid, taxes, extra shipping charges, discounts, etc.); · Terms of Sale, · Invoice reference number.

[0115] In a completely privacy-preserving design, different fields of the invoice may be kept private, however, in case of an audit or dispute, it may be useful to reveal selective invoice data fields.

[0116] To create a Merkle tree, one or more of the invoice data fields may be hashed separately. A single root hash value R may be calculated for the tree.

[0117] An example Merkle tree based on invoice data is shown in Figure 7. In the example of Figure 7, Bob 103b bought two items in a transaction: item 1 and item 2. The transaction may also include the following data fields: seller data, date data, method data, amount data, and terms data. Each of the invoice data fields may be hashed separately and mapped to a Merkle tree to compute a single hash value.

[0118] In one example, assuming a seller has bought two items as in Figure 7, a Merkle Tree can be formed as follows: For each invoice data field, a hash h i That is, calculate h1=Hash(seller details), h2=Hash(date), h3=Hash(purchased item 1), h4=Hash(purchased item 2), h5=Hash(payment method), h6=Hash(amount), h7=Hash(sales terms), h8=h7.

[0119] At 661, a Merkle tree may be formed using the above calculated hashes as leaves, and a tree root value may be calculated, as shown in Figure 7. If the number of nodes in a level of the tree is odd, copies of certain nodes (e.g., the first node, the last node, etc.) may be added to make the number of nodes even. In this example, there are only seven leaves, so h8 is added by setting it to the value of h7 to have an even number of leaves.

[0120] At 663, Alice 103a calculates the root value R of the Merkle tree.

[0121] At 665, Alice 103a signs the root value R of the Merkle tree using a private key belonging to Alice 103a. In some examples, Alice 103a may also sign payment-related data using a private key belonging to Alice 103a, which may be the same key used to sign the root value or a different key. The payment-related data may comprise, for example, a seller payment address (i.e., an address to pay Alice 103a). In some examples, the seller payment address may comprise a Bitcoin address.

[0122] At 667, Alice 103a receives a transaction template TxID incompleteIn the output of the transaction template, Alice 103a includes the root value, Alice's signature (which may correspond to Alice's private key), and Alice's address (e.g., payment address). The output may also comprise Alice's public key certificate (i.e., the seller's public key infrastructure certificate). It should be understood that there are many possible formats for the output, but one example of the output may be as follows: OP_FALSE OP_RETURN<root|seller_payment_address|seller signature|seller public key infrastructure certificate>

[0123] The seller may add their payment address and the amount for the transaction in Satoshis in further outputs of the transaction template. An example transaction template is shown in Table 1.

[0124] [Table 1]

[0125] In this example, the seller's payment address is written into the transaction template twice: once after the OP_FALSE OP_RETURN and once as a separate output. There are several other alternative ways to insert the data, as explained further below.

[0126] At 669, Alice 103a adds the output of Alice's payment address and the amount (which may be in satoshis, for example). incomplete , invoice data d, and instructions to Bob 103b on how to construct a Merkle tree for the invoice data and compute the root value R.

[0127] At 671, Bob 103b may perform one or more checks before completing the transaction. Bob 103b may build a Merkle tree based on the invoice data and instructions on how to build the Merkle tree received at 669. Bob 103b may then check that the root value matches the value signed by Alice 103a.

[0128] Bob 103b may check that Alice's signature and certificate are valid, at 671. This may comprise checking that the public key infrastructure certificate of Alice's 103a signature is valid. Bob 103b may check that the payment address of the seller in the transaction template matches.

[0129] If Bob 103b satisfies all the checks at 671, then Bob 103b sends the locked output (e.g., UTXO) to Bob 103b via transaction template TxID incomplete The unlocking script plus transaction TxID complete Example Transaction TxID complete is shown in Table 2.

[0130] [Table 2]

[0131] After 671, Bob enters transaction TxID 673. complete may be sent directly to the blockchain network 106, or in 675a, complete to Alice 103a, who can then forward the transaction to the blockchain network 106 at 675b. In some examples, between 675a ​​and 675b, Alice 103a may send the transaction TxID complete A check may be performed against

[0132] In the above example, the transaction template TxID incomplete and transaction TxID complete includes Alice's signature in the output, e.g., the non-consumable output. For example, Alice's signature may be preceded by opcode OP_FALSE OP_RETURN. The signature is not verified during the transaction verification process, but shall be verified separately by Bob 103b at 671. In this way, Alice's signature does not need to be an Elliptic Curve Digital Signature Algorithm (ECDSA) signature, since the digital certificate is verified by Bob 103b anyway. Also, the payment of the transaction by Bob 103b is separated from the issuance of the invoice at 669, and Alice 103a includes an extra input. In the example where Satoshis are used in the transaction, it is not required to spend Satoshis. The transaction verification process for blockchain full nodes is also reduced. Furthermore, the signed data and Alice's 103a signature can be separated and treated independently from the transaction. If Alice 103a wishes to issue a copy of the invoice, the signed data will be an exact copy, and Alice's signature could be an exact copy, but this is not an option when locking script signatures are used.

[0133] An alternative design is considered in which the seller includes an input and unlocking script that uses a signature with a (single|anyone can pay) sig hash flag, such as the one shown in Table 3. Transaction template TxID as shown in Table 3 incompletecan be created in 667 and sent in 669. A link is provided between Alice's signature in the unlocking script and Alice's identity (provided in this example in the PKI_Certificate) such that the signature in the unlocking script could only be generated by Alice 103a. In 671, Bob 103b checks the relationship between Alice's 103a's public key in the certificate and the public key used in the unlocking script, i.e., that the signature in the unlocking script could only be generated by the person named in the certificate. Bob 103b may not need to run the ECDSA signature verification algorithm. Bob 103b can also check that the appropriate sig hash flags are used in Alice's signature.

[0134] [Table 3]

[0135] In some examples, rather than having two outputs in a transaction as in Tables 1-3, it is possible to have only one output that is used for both. See Table 4. In such an example, Bob 103b may add a locked output (e.g., UTXO) and a locking script to Bob 103b at 671. The advantage of this system is that the invoice data and payment are all contained in one single output. However, this does not allow the blockchain nodes to separate the data from the payment output.

[0136] Note that in a transaction such as in Table 4, seller_payment_address appears only once, not twice as in Tables 1-3. The message to be signed is still, e.g., Signed_Message=Hash(<SELLER_PAYMENT_ADDRESS> |<Invoice_data_tree_Root> ) It could be.

[0137] [Table 4]

[0138] Transaction TxID in Table 5 complete In some examples, such as, rather than having one transaction used for payment and to carry invoice data, it is possible to have a transaction only to carry invoice data. Payment may be made in a separate blockchain transaction, and even using fiat. Delinking the payment transaction and the invoice data may be useful from a privacy perspective in some examples.

[0139] [Table 5]

[0140] When storing data, Alice 103a and Bob 103b may store the data off-chain. Alice 103a and Bob 103b may each store one or more of the following: Data fields (e.g. invoice data fields), at least one of a Merkle tree and instructions for generating a Merkle tree from a data field; At least one of the following: the raw transaction data, or an identifier for the transaction (transaction ID); The block height, as this helps to identify the location of a transaction within the blockchain.

[0141] Data may also be held on-chain. Such data may include one or more of the following: The root value of the Merkle tree, R, ·Alice's signature, A digital certificate to authenticate Alice's signature, Some data fields to be inserted into the transaction in clear text form. This may be for regulatory compliance or to reduce the complexity of providing invoice data fields (e.g., data fields that are routinely accessed for audits such as invoice total amount, invoice reference number, and seller name).

[0142] Data held on-chain may be sent from at least one of Alice 103a and Bob 103b.

[0143] Alice 103a or Bob 103b may then use the selective disclosure method to share a data field in the data and prove that it is part of the Merkle tree. This can be shared and proven to a third party (or from Bob 103b to Alice 103a, or vice versa). This can be done without having to reveal other data fields. For example, in FIG. 7, a Merkle proof for product 1 where h3=Hash(product 1) is Proof=h4,h 1|2 ,h 5-8 Thus, by revealing Item 1 and its proof, a route can be calculated and checked to match the values ​​inserted in the transaction.

[0144] If the input of a cryptographic hash function is chosen from a limited domain, it may be possible to find it using a dictionary attack, i.e., an attacker attempts to hash all domain values ​​until a match is found. One way to avoid such attacks is the use of a salt, where Alice 103a adds a random value to the input of the hash. Alice 103a shall communicate the salt to Bob 103b in such an example. In some examples, the salt may come from a large domain. In some examples, the salt is different for each leaf.

[0145] The dictionary attack vulnerability is leaf h i =Hash(d i ) data field d used to calculate i It appears when sending the Merkle proof of h i+1 =Hash(d i+1 ) given by h i Includes paired leaves of d i+1 can be easily cracked if it is from a restricted domain. In other words, when a prover tries to prove the containment of a leaf, its sibling leaves can be exposed if they come from a restricted domain.

[0146] To mitigate the above situation, in some examples, each leaf of the tree is paired with the hash of a random value. i =Hash(d i ), then the pair leaf is h i+1 =Hash(random()). This doubles the number of leaves in the Merkle tree, but reduces its vulnerability.

[0147] To apply the misleading indication, Alice 103a can create a transaction that resembles a real transaction. For example, an invoice data tree (Merkle tree) may be created based on "fake" data that does not correspond to a real transaction. An allocated leaf of the Merkle tree can be used to flag that the data used comprises fake misleading data. The misleading data may comprise misleading data items. During any possible audit process, Alice 103a can prove to an authorized auditor that the misleading flag is part of the signed data in the transaction, and therefore the transaction can be ignored. To an outside observer, the transaction will look like any other transaction that carries an invoice. Assuming that the misleading data has outputs similar to those shown in Table 1 and Table 2, if an outside observer sees a transaction output for a transaction based on the misleading data, OP_FALSE OP_RETURN<Hash_value|SELLER_PAYMENT_ADDRESS|SELLER_SIGNATURE|SELLER_PKI_CERTIFICATE> You will see the following.

[0148] There are several possibilities to indicate the use of the misdirection in a Merkle tree. For example, a particular (e.g., first, last, n-th) leaf should be equal to hash(misdirection). This allows Alice 103a or Bob 103b to misdirect an unauthorized entity while partially revealing the invoice data field. As an example, if a particular leaf for flagging the misdirection is chosen as the first leaf in FIG. 5 or FIG. 7, h1 may be equal to Hash(misdirection). This allows Alice 103a or Bob 103b to misdirect an unauthorized entity while partially revealing the data field, for example, where h3 and onwards are used as the invoice data field. Note that the pair (h2) of the misdirection flag leaf (h1) may be a random value to make it more difficult to perform a brute force attack and calculate Hash(misdirection).

[0149] Another example to demonstrate the use of invalid indicators in a Merkle Tree is to concatenate the invalid indicator value with the invoice data hash such that Hash_value = hash(random() | invalid indicator).

[0150] To apply equivalence to a Merkle tree, an equivalence value of a data field describing a characteristic desired to be kept private may be determined and used. The equivalence value may be a functional equivalence value of the data field. In some examples, a descriptive term may be used as the functional equivalence value to represent, for example, a numerical value in the data field. The functional equivalence value may be determined based on a range of values ​​within which the characteristic described in the private data field lies. For example, a functional equivalence value may be determined depending on a certain value within which a height value lies. For example, 150 cm may be in the range of 145 cm to 160 cm with a corresponding functional equivalence value of "low".

[0151] In some examples, the data fields that are determined to be kept private ("private data fields") and the functional equivalent value of the private data field may both be inserted into the Merkle tree. Different access rights may be given to each data field. In some examples, by keeping both the private data field and the functional equivalent value in the Merkle tree, this may be used in examples where a buyer (e.g., Bob 103b) queries the product received after the transaction is stored on the blockchain network 106, and the buyer may later be provided with access to the private data to check the exact data provided by the seller (Alice 103a). In some examples, in situations where a dispute arises regarding the transaction, access to the private data field may be given by Alice 103a to Bob 103b. This may be accomplished by having the exact value hashed and used as a leaf in forming the Merkle tree. The equivalent value may also be included in another leaf of the Merkle tree. In some examples, access to the private data as well as the functional equivalent value may be provided to one or more authorized verifiers to ensure that Alice provided a suitable functional equivalent value of the private data.

[0152] In one example, a seller (e.g., a pharmacy, a sports equipment center, etc.) needs a buyer's health profile to sell the buyer a needed item (e.g., a prescription, custom sports equipment tailored to at least one of the buyer's weight and height, etc.). The seller can use some of the leaves to contain the buyer's information and a hash of the exact value of the health profile, and some other leaves that contain the equivalent value. The equivalent value can be used for research and audit purposes. Both values ​​can be used to verify that the proper equivalent value is being used by the seller.

[0153] In some examples, leaves with a hash of an exact value may be paired with a hash of a random value, in some examples, leaves with a hash of a functionally equivalent value may be paired with a hash of a random value.

[0154] An invoice tree may have one leaf that has a hash of one or more exact values ​​(which may be desired to be kept private), and another leaf that has a hash of a functional equivalent of one or more exact values.

[0155] For example, depending on the weight and height of the user, functional equivalence values, ie, low, medium, high, may be determined. One leaf is a hash of the exact buyer measurement, i.e., h i =Hash(weight|height) Another leaf h contains the equivalence class of this observation, which can be Hash(low), Hash(medium), Hash(high), etc. j =Hash(equivalence class).

[0156] h i is the hash of a random value h i+1 May be paired with h j is the hash of a random value h j+1 May be paired with.

[0157] For research and audit purposes, Seller will j In case of a dispute, the seller or the buyer can choose to reveal only the exact value (h i It may be desirable to clarify the original image of the

[0158] Quantization techniques may also be used to hide precise information in the Merkle tree. Information describing the characteristic may be obtained and may be divided into information having at least two data items that describe the characteristic with different levels of precision. A set of data items for generating a Merkle tree may be determined or obtained, including at least two data items that describe the characteristic with different levels of precision. Two or more leaf nodes of the Merkle tree may then be determined by hashing each data item in the set of data items, where the Merkle tree comprises a plurality of leaf nodes including two or more leaf nodes. At least one of Alice 103a and Bob 103b may then store at least one Merkle tree and instructions for generating the Merkle tree.

[0159] An example is considered where quantization techniques are used to hide precision information to the privacy of a shopper. An example of a delivery service for goods purchased by a shopper is considered. The delivery address may be a characteristic described by information (data) and may be included in the data of an invoice, for example. Rather than including the delivery address in a single data field, the delivery address data item may be split into further data that are each hashed separately. For simplicity, let the delivery address comprise: 1. The first line of the address, i.e. building number, apartment number, street name, etc. 2. Code, i.e. postcode or zip code 3. Country

[0160] These three data items describe the characteristic at different levels of accuracy. The delivery address characteristic can be split into these three data items. In one example, for the above data fields, the zip code can be split in two and then each data field is hashed separately to provide the following: h d1 =Hash(first line of address) h d2=Hash(first half of zip code) h d3 =Hash(second half of zip code) h d4 =Hash(Country)

[0161] It will be appreciated that this is just one example of splitting information into different data items with different levels of granularity. For the above information, the delivery service at the warehouse may determine the country and the first half of the zip code, i.e., h, that is sufficient to guide the delivery through the first leg. d2 and h d4 On the other hand, the driver who delivers the final delivery leg needs to know the exact delivery address, i.e., h d1 and h d3 For example, if the warehouse is in Manchester and the delivery is in London, the delivery service in Manchester only needs to know that they have a delivery to be sent to SW in South West London. The driver carrying the last leg of the delivery will know that the delivery is destined for 10 Downing Street.

[0162] remarks Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to one of ordinary skill in the art. The scope of the present disclosure is not limited by the described embodiments, but only by the claims that follow.

[0163] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one example of the blockchain 150, and that the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 as described above.

[0164] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, issuing, propagating, and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and issuing blocks (recall that these entities are not considered to be suitable Bitcoin network 106 nodes).

[0165] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, if not all, of the functions of creating, issuing, propagating, and storing blocks 151 of the blockchain 150. For example, in these other blockchain networks, a "node" may be used to refer to a network entity that is configured to create and issue blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0166] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in a similar manner as described above with reference to the blockchain node 104.

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

[0168] Statement 1: A computer-implemented method comprising: obtaining information describing a characteristic; partitioning the information into at least two data items describing the characteristic with at least two different levels of precision; obtaining a set of data items for generating a Merkle tree, the set of data items including at least two data items; generating two or more leaf nodes of the Merkle tree by hashing each data item in the set of data items, the Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes; and storing at least one of the Merkle tree; instructions for generating a Merkle tree from the set of data items.

[0169] Statement 2: A method according to Statement 1, comprising, upon obtaining information describing the characteristic, determining a functionally equivalent value describing the characteristic based on a first value describing the characteristic.

[0170] Statement 3: The method according to Statement 2, wherein the first value comprises a numerical value and the functionally equivalent value comprises a descriptive term, the method comprising determining the descriptive term by determining a numerical range that includes the numerical value, the descriptive term corresponding to the numerical range.

[0171] Statement 4: The method according to any preceding statement, the method comprising calculating a root value of the Merkle tree, signing the root value using the first party's private key, and signing the first party's address using the first party's private key.

[0172] Statement 5: The method according to Statement 4, the method comprising creating a transaction template, the transaction template comprising an output comprising a root value, a first party address, and a first party signature.

[0173] Statement 6: The method according to Statement 5, the method comprising sending to a second party the transaction template, the set of data items for generating the Merkle tree, and instructions for generating the Merkle tree.

[0174] Statement 7: The method according to Statement 6, the method comprising: checking by the second party validity of the signature; constructing by the second party a second Merkle tree having a second root value using the data for determining the Merkle tree and the instructions for generating the Merkle tree; checking that the second root value matches the root value signed by the first party; if the second root value matches the root value signed by the first party, adding an output locked to the second party to an unlocking script of the transaction template to complete the transaction; and sending by the second party the transaction to the first party or to the blockchain.

[0175] Statement 8: The method according to statement 6 or statement 7, wherein the output comprises a public key infrastructure certificate for the first party signature, the method comprising checking by the second party the validity of the public key infrastructure certificate for the first party signature prior to sending the transaction by the second party to the first party or to the blockchain.

[0176] Statement 9: The method according to statement 7 or statement 8, the method comprising sending the transaction to the blockchain by the first party.

[0177] Statement 10: The method according to any of statements 5-9, the method comprising sending the root value of the Merkle tree and the first party signature to the blockchain by at least one of the first party and the second party.

[0178] Statement 11: A method according to any of statements 7-9, the method comprising storing, by the first party and the second party, at least one of: data items for determining a Merkle tree, the Merkle tree, and instructions for generating a Merkle tree from a set of data items, at least one of transaction data and an identifier of the transaction.

[0179] Statement 12: The method according to any preceding statement, the method comprising performing, by at least one of the first party and the second party, sharing with a third party the data fields used to determine the Merkle tree, and sending a Merkle proof of the data fields to the third party.

[0180] Statement 13: A method according to any preceding statement, the method comprising: generating a set of invalidity-indicating data items; generating two or more leaf nodes of a further Merkle tree by hashing each data item in the set of invalidity-indicating data items; setting a leaf node at a particular position of the further Merkle tree to a certain value indicating that the invalidity-indicating data item was used to generate the further Merkle tree; and storing the further Merkle tree, the further Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes.

[0181] STATEMENT 14: The method according to any preceding statement, wherein the set of data items includes one or more data items describing an invoice.

[0182] Statement 15: A method according to the preceding statement, wherein each leaf node generated by hashing one of the one or more data items describing the invoice is paired with a leaf node generated by hashing a random value.

[0183] Statement 16: A computing device comprising: a memory having one or more memory units; and a processing device having one or more processing units, the memory storing code configured to operate on the processing device, the code configured to perform any of the methods of statements 1 to 15 when on the processing device.

[0184] Statement 17. A computer program embodied on a computer readable storage and configured to perform the method of any of statements 1 to 15 when run on one or more processors.

[0185] According to another aspect disclosed herein, a method for comprising a first user action may be provided.

[0186] According to another aspect disclosed herein, a method may be provided that includes an action of a second user.

[0187] According to another aspect disclosed herein, a method may be provided that comprises actions of a first user and a second user.

[0188] According to another aspect disclosed herein, a system may be provided that includes a computing device of a first user.

[0189] According to another aspect disclosed herein, a system may be provided that includes a computing device of a second user.

[0190] According to another aspect disclosed herein, a system may be provided that includes computing devices of a first user and a second user. [Explanation of symbols]

[0191] 100 Systems 101 Packet Switching Network 102 Computer terminals, computer equipment 103 User, Party 103a First Party, Alice 103b Second Party, Bob 104 Blockchain nodes 105 Client Applications 106 Peer-to-peer (P2P) networks, blockchain networks 107 Side Channel 150 Blockchain 151 Data, Block 152 Transactions 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input, input field 203 Output, Output Field, Unspent Output, Transaction Output, Unspent Transaction Output, UTXO 401 Transaction Engine 402 User Interface (UI) Layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Memory Module 500 User Interface (UI), Merkle Tree 501 User Selectable Elements 502 Data Entry Fields 503 Information Element

Claims

1. obtaining information describing the characteristic; partitioning said information into at least two data items describing said characteristic with at least two different levels of precision; obtaining a set of data items for generating a Merkle tree, said set of data items including said at least two data items; generating two or more leaf nodes of a Merkle tree by hashing each data item in the set of data items, the Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes; storing at least one of the Merkle tree and instructions for generating the Merkle tree from the set of data items; A computer-implemented method comprising:

2. obtaining information describing the characteristic, determining a functionally equivalent value describing said characteristic based on a first value describing said characteristic. The method of claim 1.

3. wherein the first value comprises a numerical value and the functionally equivalent value comprises a descriptive term, and the method further comprises: determining said descriptive terms by determining a numerical range including said numerical value, said descriptive terms corresponding to said numerical range; The method of claim 2.

4. calculating a root value of the Merkle tree; signing the root value using a first party private key; signing a first party address using the first party's private key; 4. The method according to claim 1 , comprising:

5. creating a transaction template, the transaction template having an output comprising the root value, the address of the first party, and a signature of the first party; The method of claim 4.

6. sending the transaction template, the set of data items for generating the Merkle tree, and instructions for generating the Merkle tree to a second party; The method of claim 5 comprising:

7. checking the validity of the signature by the second party; constructing, by the second party, a second Merkle tree having a second root value using the set of data items for determining the Merkle tree and the instructions for generating the Merkle tree; checking that the second root value matches the root value signed by the first party; if the second root value matches the root value signed by the first party, adding an output locked to the second party to an unlocking script of the transaction template to complete the transaction; sending the transaction by the second party to the first party or to a blockchain; The method of claim 6, comprising:

8. the output comprises a public key infrastructure certificate for the signature of the first party, the method comprising: Prior to sending a transaction to the first party or to a blockchain by the second party, checking by the second party the validity of the public key infrastructure certificate for the signature of the first party. The method according to claim 6 or 7.

9. Sending the transaction to the blockchain by the first party. The method according to claim 7 or 8, comprising:

10. the root value of the Merkle tree, and said signature of said first party; sending to a blockchain by at least one of the first party and the second party.

10. The method of claim 5, comprising:

11. the data items for determining the Merkle tree; at least one of the Merkle tree and the instructions for generating the Merkle tree from the set of data items; at least one of transaction data and an identifier of the transaction; storing by the first party and the second party 10. The method according to any one of claims 7 to 9, comprising:

12. sharing with a third party the data fields used to determine said Merkle tree; sending a Merkle proof of said data fields to said third party; Steps to be performed by at least one of the first party and the second party 12. The method of claim 1 , comprising:

13. generating a set of invalid data items; generating two or more leaf nodes of a further Merkle tree by hashing each data item in said set of invalid data items; setting a leaf node at a particular position of the further Merkle tree to a certain value that indicates that an invalid data item was used to generate the further Merkle tree; storing the further Merkle tree, the further Merkle tree comprising a plurality of leaf nodes including the two or more leaf nodes. The method of claim 1.

14. 14. A method according to any one of claims 1 to 13, wherein the set of data items comprises one or more data items describing an invoice.

15. 2. The method of claim 1 , wherein each leaf node generated by hashing one of the one or more data items describing an invoice is paired with a leaf node generated by hashing a random value.

16. a memory comprising one or more memory units; a processing device comprising one or more processing units, said memory storing code configured to run on said processing device, said code configured to execute the method of any one of claims 1 to 15 when present on said processing device. Computer equipment.

17. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 15 when run on one or more processors.

Images