Sensitive Data Blocking

Abstract

1. A method for blocking sensitive data in a message, the method being performed on a computing device, comprising the steps of: creating a copy of the message; generating at least one zero-knowledge proof, wherein generating each of the at least one zero-knowledge proof comprises obtaining a mask bit string identifying a location of at least one secret bit in bits of the copy; computing a public bit string by modifying the bits of the copy by assigning a predetermined value to the at least one secret bit; and determining a secret bit string, the secret bit string including the at least one secret bit, and the bits of the copy being determined by computing a public bit string, the mask bit string, and the hashing a copy of the message or a portion thereof to generate an output hash value; and generating a zero-knowledge proof using the public bit string, the mask bit string, the output hash value, and the secret bit string; removing each of the at least one secret bit from the copy to generate a modified message; and outputting the modified message to a recipient together with the at least one output hash value and the at least one zero-knowledge proof to enable the recipient to prove that the modified message is valid.

Description

[Technical Field]

[0001] The present disclosure relates to blocking sensitive data in messages. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly published at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter also referred to as a "blockchain network"). A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction, except for so-called "coinbase transactions," points to the preceding transaction in the sequence. The sequence may span one or more blocks, tracing back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are generated through a process known as "mining." "Mining" involves multiple nodes competing to perform "proof-of-work," i.e., solving a cryptographic puzzle based on the presentation of a defined set of ordered and validated pending transactions awaiting inclusion in a new block of the blockchain. Notably, a blockchain may be pruned at some nodes, and block publication can be achieved through the publication of only the block header.

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

[0004] Nodes (sometimes called "miners") in the blockchain network perform a distributed transaction registration and validation process, described in detail below. Briefly, during this process, nodes validate transactions, insert them into a block template, and attempt to identify a valid proof-of-work solution for it. Once a valid solution is found, the new block is propagated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network for propagation. Nodes receiving the transaction compete to find a proof-of-work solution and include the validated transaction in a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or included in a block. Assuming the transaction is validated and thereby accepted into the blockchain, the transaction (including any user data) therefore remains registered and indexed at each node in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle to generate the latest block are typically rewarded with a new transaction, called a "coinbase transaction," that generates a new quantity of digital assets, or tokens. Detection and rejection of invalid transactions is performed by competing nodes, who act as agents of the network and are incentivized to report and prevent illicit activity. Widespread publication of information allows users to continuously audit node performance. By simply publishing block headers, participants can 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 includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset derivable from the preceding transaction sequence. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies conditions for the output's future redemption. A locking script is a predicate that defines the conditions required to validate and transfer a digital token or asset. Each input in a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script to unlock the pointed-to output's locking script. Thus, when considering a pair of transactions, we refer to them as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input including a pointer to an output of the first transaction and an unlock 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 validity criterion applied by each node is that the unlock script meets all of one or more conditions defined in the lock script of the first transaction, and another is that the output of the first transaction has not yet been redeemed by another, previous, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will neither propagate it (as a valid transaction) (but may register an 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 transfers by referencing absolute account balances, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in the past sequence of transactions. The current state of all accounts is stored and constantly updated by nodes separate from the blockchain. Summary of the Invention

[0009] The immutability of a blockchain (e.g., the Bitcoin blockchain) has been thought to mean that any data uploaded to the public ledger cannot be censored. In a scenario where the distribution of some data payload (e.g., bank account number, passport number) within a Bitcoin transaction is blocked by an administrative authority, participants in the Bitcoin network face a dilemma: either block the data from propagating throughout the network or allow the same data to spread throughout the network. The former case violates the immutability of the blockchain, while the latter case harms other participants and may result in legal consequences for participants who share the data.

[0010] In embodiments of the present disclosure, a mechanism is provided to block some (more or less as needed) data from a blockchain transaction while maintaining the immutability of the blockchain, meaning that participants can still verify the integrity of the blockchain's history despite the data being blocked.

[0011] Embodiments of the present disclosure may be used to block (i.e., hide) sensitive data contained in any portion of any field of a blockchain transaction. For example, embodiments of the present disclosure may be used to block sensitive data contained in the OP_FALSE OP_RETURN field of a blockchain transaction.

[0012] A zero-knowledge proof (ZKP) is a method by which a party, known as a prover, can prove to another party, known as a verifier, that a statement is true without revealing any information other than the fact that the statement is true. In embodiments of the present disclosure, one or more ZKPs are generated to provide proof that a modified message (with sensitive data removed) is still valid without revealing any sensitive data necessary to prove the validity of the modified message. That is, the term "zero-knowledge proof" is used herein to mean a proof of knowledge between a prover and a verifier in which no information about sensitive / private data is revealed. In the context of blockchain transactions, a ZKP is used to prove the statement "these fields are part of a transaction with a given transaction ID," but without providing the information necessary to prove the statement, i.e., the blocked data. Thus, the validity of a modified blockchain transaction output can be verified without disclosing the blocked data.

[0013] According to one aspect disclosed herein, there is provided a method for blocking sensitive data in a message, the method being executed on a computing device and comprising: making a copy of said message; Generating at least one zero-knowledge proof, and generating each of the at least one zero-knowledge proof includes: obtaining a mask bit string that identifies the location of at least one secret bit within the bits of said copy; calculating a public bit string by modifying said at least one secret bit of said copy by assigning said secret bit a predetermined value; determining a secret bit string, the secret bit string including the at least one secret bit and satisfying the requirement that the bits of the copy are equal to the output of a bitwise logical calculation using the public bit string, the mask bit string, and the secret bit string; hashing a copy of the message or a portion thereof to generate an output hash value; generating a zero-knowledge proof using the public bit string, the mask bit string, the output hash value, and the secret bit string; and removing each of the at least one secret bit from the copy to generate a modified message; outputting the modified message to the recipient together with the at least one output hash value and the at least one zero-knowledge proof to enable the recipient to prove that the modified message is valid; A method is provided which includes:

[0014] According to one aspect disclosed herein, there is provided a method for verifying that a modified message is valid, the modified message corresponding to an original message with sensitive data removed, the method being performed on a computer device and comprising: obtaining the modified message, the modified message corresponding to the original message with each secret bit assigned a predetermined value; obtaining an output hash value of the modified message and verifying the output hash value using data stored in a memory of the computing device; receiving, from a sending device, at least one zero-knowledge proof associated with bits of the modified message; verifying each of the at least one zero-knowledge proof using: (i) knowledge of a bitwise logic operation used by the sending device to derive the secret bit sequence used to generate the zero-knowledge proof, or a verification key associated therewith; (ii) the bits of the modified message; (iii) a mask bit sequence identifying the location of at least one secret bit within the bits of the modified message; (iv) a hash value or a portion thereof of the bits of the modified message; and (v) an input hash value of the bits of the modified message; A method is provided which includes:

[0015] Although embodiments are described herein with respect to messages that are blockchain transactions, embodiments of the present disclosure extend outside the context of Bitcoin and other blockchains and can be used to block any portion of a message of any length. As described below, embodiments can efficiently block portions of messages of large data size through concurrency (i.e., parallel computation). [Brief explanation of the drawings]

[0016] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference is made, by way of example only, to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2]1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic, simulated representation of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of specific node software for processing transactions. [Figure 5] The input and output of the hash function are shown. [Figure 6A] Illustrates the process of blocking data within a message. [Figure 6B] Illustrates the process of blocking data within a message. [Figure 6C] Illustrates the process of blocking data within a message. [Figure 6D] Illustrates the process of blocking data within a message. [Figure 7] Illustrates the creation of a modified message. [Figure 8] 1 shows the circuitry used to generate a zero-knowledge proof that applies a single compression. [Figure 9] 1 shows the circuitry used to generate at least one zero-knowledge proof applying multiple rounds of compression. [Figure 10A] Illustrates the process of verifying that the modified message is valid. [Figure 10B] Illustrates the process of verifying that the modified message is valid. DETAILED DESCRIPTION OF THE INVENTION

[0017] Exemplary System Overview 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, which is typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Each blockchain node 104 is therefore highly coupled to other blockchain nodes 104.

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

[0019] A blockchain 150 includes a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes 104 in a decentralized or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, data can be removed from the blockchain 150 as long as each blockchain node 150 stores the block header (described below) for each block 151. Each block 151 in the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies a quantity representing an amount of a digital asset as an asset. In this example, the output is cryptographically locked to user 103 (requiring that user's signature or other solution to unlock it and thereby redeem or spend it). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0020] Each block 151 also contains a block pointer 155 that points back to an earlier block 151 in the chain, defining a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) contains a pointer to a previous transaction, defining an order for the sequence of transactions (Note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153 rather than to a preceding transaction.

[0021] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating the transactions 152 across the network 106. Each blockchain node 104 is configured to generate blocks 151 and store respective copies of the same blockchain 150 in its respective memory. Each blockchain node 104 also maintains an ordered set (or pool) 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is sometimes referred to as a "mempool." This term, as used herein, is not 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 is obligated to not accept other transactions that attempt to use the same output.

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

[0023] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a to provide change). In some cases, a transaction may have multiple inputs and combine amounts from multiple outputs of one or more previous transactions and redistribute them into one or more outputs of the current transaction.

[0024] According to a Bitcoin-like output-based transaction protocol, when an entity 103, such as an individual user or an organization, wants to act on a new transaction 152j (either manually or through an automated process used by a party), the acting entity sends the new transaction from its computer terminal 102 to a recipient. The acting party or recipient eventually sends this transaction to one or more blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but in principle other user terminals are also possible). In some examples, it is not excluded that the party 103 acting on the new transaction 152j can send the transaction directly to one or more blockchain nodes 104 rather than to a recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied to each blockchain node 104. The blockchain node protocol typically requires the blockchain nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the case of such output-based transaction protocols, this may involve checking that a cryptographic signature or other authentication of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152j that the new transaction assigns, which condition typically includes at least checking that the cryptographic signature or other authentication in the input of new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i, or may be simply fixed in the blockchain node protocol, or a combination thereof.In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104, following the same node protocol and applying the same tests, 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.

[0025] In an output-based model, the definition of whether a given allocated output (e.g., UTXO) is allocated (e.g., spent) is whether it has already been validly redeemed by an input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain 150 (unless it is flagged as invalid and propagated to change). This prevents double-spending, where a transactor attempts to allocate the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined order of transactions, account balances have a single, defined state at a time.

[0026] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process called mining, which is underpinned by a "proof-of-work." Blockchain nodes 104 add new transactions to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. Blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. This typically involves looking for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a predetermined number of leading zeros. 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 unpredictable output given its input. Therefore, this search can 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.

[0027] A first blockchain node 104 that solves the puzzle notifies the network 106 and provides its solution as a proof. This solution can be easily checked by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the conditions). The first blockchain node 104 propagates the block upon agreement of a threshold of other nodes to accept the block, thus enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. The new block 151n is also assigned a block pointer 155, pointing to the previously created block 151n-1 in the chain. The significant amount of effort required to generate the proof-of-work solution, e.g., in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as a double-spend. Once created, blocks 151 cannot be modified because they are known and maintained by each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose an order on the blocks 151. As transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0028] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may be solving the puzzle based on different snapshots of the pool of unpublished transactions 154, depending on when they began searching for a solution or the order in which transactions were received. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, in the order in which the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to produce blocks from the newly defined ordered pool of unpublished transactions 154. There is also a protocol for resolving possible "forks," which occur when two blockchain nodes 104 solve the puzzle within a very short time of each other, causing inconsistent views of the blockchain to propagate between the nodes 104. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150. Note that this does not affect users or agents of the network, since the same transactions appear in both branches.

[0029] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional, approved amount of a digital asset in a new special type of transaction that distributes an additional defined amount of the digital asset (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of the digital asset from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. The proof-of-work signals that the node that constructed the new block intends to follow protocol rules so that this special transaction can later be redeemed. Blockchain protocol rules may require this special transaction to expire, e.g., 100 blocks, before it can be redeemed. A regular (non-generating) transaction 152 often specifies an additional transaction fee in one of its outputs, further rewarding the blockchain node 104 that generated the block 151n in which the transaction was published. This fee is commonly referred to as a "transaction fee" and is described below.

[0030] Due to the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server including one or more physical server units, or an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0031] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 to perform one or more respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that any operation attributed to a blockchain node 104 may be performed by software executing on the processing unit of each 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.

[0032] Also connected to the network 101 are computing devices 102 for each of a number of parties 103 that act as consumer users. These users can interact with the blockchain network but do not participate in validating transactions and constructing blocks. Some of these users or agents may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0033] Some or all of the parties 103 may be coupled as part of a different network, for example, a network overlaid on the blockchain network 106. Users of the blockchain network (often called "clients") can be said to be part of the system that includes the blockchain network 106. However, these users are not blockchain nodes 104 because they do not perform the required role of a blockchain node. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby coupling (i.e., communicating) with the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown 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 can exist and participate in the system 100, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as "first party" and "second party," respectively.

[0034] Each party's 103 computing device 102 includes a respective processing unit that includes one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each party's 103 computing device 102 further includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may include one or more memory units that use 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. The memory on each party's 103 computing device 102 stores software, including a respective instance of at least one client application 105, configured to operate on the processing unit. It will be understood that any actions attributed to a party 103 given herein may be performed using software executing on the processing unit of each party's 102 computing device. Each party's 103 computing device 102 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing device 102 of a given party 103 may include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

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

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

[0037] NOTE: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in two or more different application suites, interfacing, for example, via an API, or one plugging into the other. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0038] An instance of a client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in embodiments, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions, in part, through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and to forward transactions 152 for propagation throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used for all nodes 104 in the network 106.

[0039] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. She then sends the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 with the best connection 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 involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0040] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any blockchain node 104 that receives the transaction 152j adds the new validated transaction 152 to the ordered set 154 of the blockchain maintained by that blockchain node 104. Additionally, any blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the network 106.

[0041] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, the blockchain nodes 104 begin competing to solve a proof-of-work puzzle for the latest version of their respective pools of transactions, including the new transaction 152. (Note that other blockchain nodes 104 attempt to solve the puzzle based on different pools 154 of transactions, but whoever comes first defines the set of transactions included in the latest block 151.) Eventually, the blockchain nodes 104 will solve the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once proof-of-work has been done for the pool 154 containing the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Because each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0042] Different blockchain nodes 104 may initially receive different instances of a given transaction and may therefore have conflicting views of which instances are "valid" before one instance is published into a new block 151, at which point all blockchain nodes 104 agree that only the published instance is the 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 one not yet published in a block 151).

[0043] As part of the account-based transaction model, another type of transaction protocol operated by some blockchain networks is sometimes called an "account-based" protocol. In an account-based model, each transaction transfers by referencing an absolute account balance, rather than defining the amount transferred by referencing back to the UTXO of a previous transaction in a series of past transactions. The current state of every account is stored and constantly updated by the network's nodes, separate from the blockchain. In such a system, transactions are ordered using an account's sequential transaction record (the so-called "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign a transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0044] UTXO-based model Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations. Note that the exemplary UTXO-based protocol is described with reference to Bitcoin, but could equally be implemented on other exemplary blockchain networks.

[0045] In a UTXO-based model, each transaction (“Tx”) 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO includes a value that specifies an amount of a digital asset, which represents a set number of tokens on the distributed ledger. Among other information, a UTXO may also include the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input and output fields 202 and 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the outstanding transaction 152 submitted to the node 104.

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

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

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

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

[0050] In the illustrated example, Tx0's output 203, UTXO0, contains a locking script [Checksig PA], which requires Alice's signature, Sig PA, in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction that attempts to redeem UTXO0 to be valid). [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 includes a pointer to Tx1 (e.g., its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, in order to distinguish it among any other possible outputs of Tx0. Tx1's input 202 further includes an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <SigP A The data (or "message") that Alice needs to sign to provide a valid signature may be defined by the lock script, or by the node protocol, or a combination of these.

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

number

[0052] The details of authentication using public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message using her private key, then another entity, such as node 104, given Alice's public key and the message in plaintext, can authenticate that the message must have been signed by Alice. Signatures typically involve hashing the message, signing the hash, and tagging the message as the signature, allowing the owner of the public key to authenticate the signature. Thus, in embodiments, reference to signing a particular piece of data, portion of a transaction, etc., may mean signing a hash of the piece of data or portion of a transaction.

[0053] If the unlock script of Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the 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 its ordered pool of pending transactions 154. The blockchain node 104 forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, thereby causing it to propagate throughout the network 106. Once Tx1 is validated and included in the blockchain 150, it defines it as having consumed UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it attempts to consume outputs that have already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

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

[0056] In particular, Alice must typically also include a fee for any Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 will likely be rejected by the blockchain nodes 104, and thus, although technically valid, it will not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transaction 152 if they do not want to). In some protocols, transaction fees do not require their own separate output 203 (i.e., they do not require a separate UTXO). Instead, the difference between the total amount indicated by 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 publishes the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition that produces the block containing UTXO1. However, nothing necessarily precludes that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0057] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, a given party 103's assets are dispersed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function in the client application 105 to compile the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on one of the Bitcoin nodes 104.

[0058] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to represent a specific function. "OP_...." represents a specific opcode in a scripting language. As an example, OP_RETURN, when preceded by OP_FALSE at the beginning of a lock script, is an opcode in a scripting language to generate an unspent output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

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

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

[0061] Client Software 3A illustrates an exemplary 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 perform the underlying transaction-related functions of the client 105, such as forming transactions 152 and sending transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the schemes described above and as will be described in further detail.

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

[0063] Note: Although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented in 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 in the functionality of a given module, or the transaction engine 401 may be split among more than one application. Also, this does not exclude some or all of the described functionality being implemented, for example, in the operating system layer. When reference is made elsewhere in this specification to a single or given application 105, it is understood that this is merely an example, and more generally, the described functionality may be implemented in any form of software.

[0064] 3B provides a simulated representation of an example user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It is understood that a similar UI may be rendered by any other party's client 105b, Bob's device 102b, or any other party's device.

[0065] 3B illustrates UI 500 from Alice's perspective. UI 500 may include one or more UI elements 501, 502, 502 that are rendered as separate UI elements via user output means.

[0066] For example, the UI elements may include one or more user-selectable elements 501, such as different buttons on a screen or different options in a menu. The user input means is configured to allow the user 103 (in this case, Alice 103a) to select or manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (Note: "manual," as used herein, simply means the opposite of automatic and is not necessarily limited to the use of hands). The options allow the user (Alice) to form a transaction 152 and submit the transaction to one or more nodes 104 for propagation through the blockchain network 106.

[0067] Alternatively or additionally, the UI elements may include one or more data entry fields 502 through which a user can form a transaction 152 and submit the transaction to one or more nodes 104 for propagation through the blockchain network 106. These data entry fields may be rendered via a user output means, e.g., on-screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touchscreen. Alternatively, data may be received orally, e.g., based on voice recognition.

[0068] Alternatively or additionally, the UI elements may include one or more information elements 503 that are output to output information to the user, for example, this / these may be drawn on a screen or rendered audibly.

[0069] For example, this / these may be rendered on the screen or audibly rendered. The functionality of these UI elements will be discussed in more detail shortly. It is also understood that the UI 500 shown in FIG. 3 is merely a schematic mockup and may in fact include one or more additional UI elements, which are not shown for the sake of brevity.

[0070] Node Software FIG. 4 illustrates example node software 450 that may be executed by each blockchain node 104 of the network 106 in the example UTXO or output-based model. Note that another entity may execute the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting 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 execute node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152j (Tx j ) is received, and another preceding transaction 152i (Tx m-1 ), the protocol engine 451 executes Tx jThe protocol engine 451 then identifies the unlock script in the Tx j Based on the pointer in the input of Tx i Identify and search for Tx i may be published on the blockchain 150. In this case, the protocol engine can obtain Txi from a copy of block 151 of the blockchain 150 stored in the node 104. Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 held by the node 154. i In either case, the script engine 451 identifies the lock script in the referenced output of Txi and passes it to the script engine 452.

[0071] The script engine 452 therefore i Lock script and Tx j 2, but the same can be applied to any pair of transactions. The script engine 452 executes the two scripts together as described above, which includes placing data on the stack 453 and retrieving data according to the stack-based scripting language (e.g., Script) being used.

[0072] By executing the scripts together, script engine 452 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output that the lock script is contained in. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, it returns the result "false."

[0073] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. Typically, there are one or more additional protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, and Tx j the total amount of digital assets specified in the output of Tx does not exceed the total amount pointed to by its input; i The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually validated, the decision engine 454 may then cause one or both of the agreement module 455C and the propagation module 455P to perform their respective blockchain-related functions as Tx j , which may choose to control the execution of Tx in each of the nodes' ordered transaction sets 154 for incorporation into block 151. j and a consensus module 455C that adds Tx to another blockchain node 104 in the network 106. j Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only conditional on both the transaction being declared and sufficient transaction fees remaining.

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

[0075] Blocking Data As mentioned above, the script pattern OP_FALSE OP_RETURN makes it easy to include data uploaded to the blockchain in unspendable outputs. To achieve this, users typically pay a small fee depending on the size of the data they upload. For example, in Bitcoin SV, the payload size of transaction data is effectively unlimited, allowing users to upload anything from simple text to full videos. In other blockchains, outputs can be made unspendable using only the script pattern OP_RETURN.

[0076] The combination of the script opcode OP_RETURN and the script opcode OP_FALSE OP_RETURN, which can be used to store arbitrary data on the ledger, leads to an increase in the size of the blockchain, consuming disk space on blockchain nodes that need to store the full data.

[0077] At first glance, this is not a major issue in a scenario where an authority blocks the distribution of some data payloads (e.g., bank account numbers, passport numbers) within a Bitcoin transaction. Because the payloads are in unspent outputs, blocking this data does not restrict the movement of coins. Therefore, the UTXO set is unaffected by this action. However, a problem arises if a third party needs to validate the UTXO set. This is because all fields of a transaction are required to generate a transaction ID (which is equal to the double hash of all data in the transaction). Therefore, without the blocked data, a third party cannot validate the integrity of the transaction's usable outputs. Also, a third party cannot validate the block containing the transaction because the transaction ID is required to calculate the Merkle root of all transactions stored in the block header. For example, new miners entering the Bitcoin network face this problem. They must download the entire blockchain and validate all transactions to construct the UTXO set. They can do this if and only if all data is available to them and has not been tampered with. This is known as the immutability of the blockchain.

[0078] Embodiments of the present disclosure allow network participants to block data while still being able to verify the integrity of the blockchain's history. Embodiments of the present disclosure can be used to block data present in a blockchain transaction or portion thereof.

[0079] Figure 5 shows a hash function that takes an initialization vector and an input message (preimage) as input and provides a hash output (hash digest). A hash function H is a function that maps data of any size to data of a fixed size. That is, a k-bit hash function H is a function defined as follows:

number

[0080] A cryptographic hash function must have the following properties: - Deterministic: The hash function must produce the same digest for the same preimage. -Speed: Hash digests need to be quickly computed. - One-way (preimage-resistant): Given a digest, it must be impossible to find the preimage. - Weak collision resistance (second preimage resistance): Given a hash value, it should be impossible to generate any message that produces the same hash. Strong collision resistance: it must be infeasible for two preimages to produce the same hash. - Diffusion: If at least one bit in the preimage is changed, then each bit in the digest has a 50% chance of being changed.

[0081] Hash functions provide a way to check the integrity of some data: given a piece of data as a preimage of a hash digest, one can later check the integrity of that data by comparing the current hash digest of that data with an earlier one.

[0082] Typically, a third party needs the entire contents of the input message to validate the hash output. In embodiments of the present disclosure, a third party can validate that the hash output is valid without accessing the confidential portion of the message. "Confidential" data, as used herein, refers to data that a user or an administrative entity may block. Confidential data can be private to the user (e.g., bank account number, passport number), illegal, malicious, defamatory, or obscene. As shown in FIG. 5 , in contrast to known techniques, embodiments of the present disclosure use an input message (preimage) to determine a public message, a confidential message, and a mask that identifies the locations of public and confidential bits in the input message. The confidential message is determined such that, when the input is provided as input to a logic circuit (which also receives the public message and mask as input), the logic circuit provides the input message (preimage) as output to a hash function. As described in more detail below, the input to the logic circuit is used to generate a zero-knowledge proof that can block / hide confidential bits in the input message while making other data in the input message publicly accessible. Confidential bits located anywhere in the input message can be blocked / hide from the recipient. Embodiments of the present disclosure allow flexibility to allow a person to create different masks to selectively reveal different portions of information of the same data to different entities at different times.

[0083] 6A-D are flowcharts illustrating a process 600 for blocking data in a message according to an embodiment of the present disclosure. The process 600 may be performed by a computing device.

[0084] Embodiments of the present disclosure are described first with reference to messages containing blockchain transaction data and processes 600 performed by blockchain nodes 104. In these examples, the messages may be all or part of one or more blockchain transactions.

[0085] In step S602, the blockchain node 104 receives the message in the form of a blockchain transaction and, in step S604, creates a copy of the blockchain transaction, referred to herein as RealContent. As shown in Figure 7, the RealContent is L bits in length. This copy is passed on as the actual data, but the blockchain node 104 controls the information that should actually be displayed in that particular copy.

[0086] In step S604, the blockchain node 104 pads the message string RealContent with padding bits 702 according to a hashing algorithm to generate a message string referred to herein as RealContentPad. As a result of the padding, the message string RealContentPad has a length that is a positive integer multiple of the input message size defined by the hashing algorithm. An example of a hashing algorithm is the SHA256 hash function.

[0087] For Bitcoin, the SHA256 hash function is used to derive a transaction's TxID. In particular, a Transaction ID (TxID) is a double SHA256 hash (or SHA256d = SHA256(SHA256(.))) of a serialized Bitcoin transaction (e.g., 32-bit Version, 32-bit LockTime, list of transaction inputs, list of transaction outputs including Data).

[0088] The compression function for SHA256 is:

number

[0089] Assuming the length of the message RealContent is l and is less than or equal to 447 bits, the padding performed in step S604 involves adding a single bit of value 1 to the end of the RealContent. Next, k zero bits are added, where k is the smallest positive solution to the equation l+1+k=448 mod 512. Finally, a 64-bit block is added that is a representation of the message length l written in binary form. For example, suppose the length of the message RealContent is 24 bits. The message RealContent is first padded with ones, and then 448-(24+1)=423 zero bits are added along with the 64-bit block to convert the RealContent into a 512-bit padded message RealContentPad.

[0090] A common hash function processes longer messages M (448 bits or more) by following an iterative approach (known as the Merkle-Damgard construction), which divides M into n blocks of k bits each, i.e.:

number

number

[0091] If the length of the RealContentPad is 512 bits (see step S608), the process 600 proceeds to step S610 shown in FIG. 6B.

[0092] In step S610, the blockchain node 104 identifies the location of at least one secret bit among the bits of the 512-bit padded message RealContentPad. The blockchain node 104 performs step S610 by querying the memory of the blockchain node 104.

[0093] For example, the memory of a blockchain node 104 may store one or more bit strings corresponding to content previously identified as sensitive.

[0094] In another example, one or more predefined rules defining sensitive data may be stored in the memory of the blockchain node 104. For example, the memory may store a predefined rule indicating that any URL containing a particular domain name should be blocked. In another example, the memory may store a predefined rule indicating that the words "passport number" followed by nine digits should be blocked.

[0095] In step S612, the blockchain node 104 generates a mask bit string Mask, which identifies the location of the public bit(s) and the confidential bit(s) within the 512-bit padded message RealContentPad. In particular, the blockchain node 104 generates the mask bit string Mask according to the following formula:

number

[0096] In another embodiment, as an alternative to steps S610 and S612, the blockchain node 104 can obtain the mask bit string Mask by reading the mask bit string from the memory of the blockchain node 104. Regardless of how the mask bit string Mask is obtained, in this embodiment, the length of the mask bit string Mask is 512 bits.

[0097] In step S614, the blockchain node 104 calculates the public bit string PublicData by modifying RealContentPad by assigning the same predetermined value (e.g., 0 or 1) to all secret bits and retaining the public bit values. Thus, in this embodiment, the length of the public bit string PublicData is 512 bits. To explain how the public bit string PublicData is calculated, reference is made here to modifying RealContentPad by assigning a value of 0 to all secret bits, but this is merely an example.

[0098] In step 614, the blockchain node 104 also computes a secret bit string, SecretData, which has a length of 512 bits and includes the secret bits. The blockchain node 104 can compute the secret bit string, SecretData, by taking the RealContentPad and retaining the secret bits contained therein; the remaining bits of SecretData can take any value.

[0099] The secret bit string SecretData satisfies the requirement that RealContentPad is equal to the public bit string PublicData and the output of a bitwise logical operation (including multiple logical operations) using the secret bit string SecretData and the mask bit string Mask as input.

[0100] As an example, a secret bit string SecretData might satisfy the following requirements:

number

[0101] In particular, the secret bit string SecretData satisfies the requirement that RealContentPad be equal to the bitwise XOR of (i) the public bit string and (ii) the result of a bitwise AND of the mask bit string and the secret bit string. This configuration is shown as part of the dashed circuit in Figure 8. Logic circuit configurations other than those described above and shown in Figure 8 are possible, provided that the logic circuit configuration takes as inputs (i) the public bit string PublicData, (ii) the secret bit string SecretData, and (iii) the mask bit string Mask, and the bitwise logical operations therein provide RealContentPad as output.

[0102] In step S616, the blockchain node 104 calculates a hash value Hashvalue by hashing the message string RealContentPad, where Hashvalue = SHA256(RealContentPad). The public initialization vector H used in step S616 i 0 comes from the Secure Hash Standard (SHS) in an embodiment where the SHA256 hash algorithm is used. For SHA256, the initial hash value H i 0 shall consist of the following eight 32-bit words:

number

[0103] In step S618, the blockchain node 104 generates a zero-knowledge proof using: Public bitstream, PublicData, Mask bit string, Mask, Output hash value, Hashvalue, A secret bit string, SecretData.

[0104] Zero-Knowledge Proofs (ZKPs) are cryptographic building blocks that allow a party (the prover) to prove to another party (the verifier) ​​that a statement is true without revealing any information other than the truth of the statement.

[0105] The zero-knowledge proof generated in step S618 is a type of proof that not only proves the validity of a statement, but also guarantees that the prover knows secret information without revealing anything about it.

[0106] While interactive zero-knowledge proofs require interaction between the prover and the verifier, there are also non-interactive zero-knowledge proofs in which the prover generates only one message, called a "proof," to convince the verifier that a statement is true. The zero-knowledge proof generated in step S618 may be a NIZK proof.

[0107] A zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a concise, very short, and easy-to-verify NIZK proof of knowledge. A statement is represented by a logic circuit that is used to generate a proof of the statement. In the most efficient configuration, the verifier simply performs a constant group operation. The zero-knowledge proof generated in step S618 may be a zkSNARK proof.

[0108] In the example where the zero-knowledge proof generated in step S618 is a zkSNARK proof, a proof key (which is read from the memory of the blockchain node 104) is additionally used in generating the zkSNARK proof.

[0109] The zkSNARK protocol generally consists of three phases: Given a Setup statement, a pair of proof and verification keys is computed through several internal steps, such as algebraic circuit generation, R1CS (Rank-1 Constraint System), QAP (Quadratic Span Programs), etc. Since accessing them could lead to attacks, the private information must be destroyed and never exist again. b. Proof generation Given public information, a proof key, and public and private inputs, the prover generates a proof and sends it to the verifier. c. Verification Given the public information, the verification key, and the public input, the verifier performs the verification.

[0110] A zkSNARK protocol must satisfy the following properties: Completeness: If the statement is true and the verifier and prover are honest, the proof is accepted. Soundness: If a statement is false, then a dishonest prover cannot convince an honest verifier that it is true except with negligible probability. Zero-Knowledge: A zero-knowledge proof reveals no information to the verifier other than the truth of the statement. Succinct: The proof is shorter than the circuit size and the verifier needs to perform fewer cryptographic operations than the circuit size. Non-Interactive: The proof is sent to the verifier in only one step. Arguments of Knowledge: The proof is considered computationally sound, i.e., an unbounded prover (such as a quantum computer) could prove a false statement without being detected. Knowledge: The prover knows the witness with certainty, and no proof can be constructed without access to the witness (which is the secret input needed to prove the statement), i.e., an extraction algorithm exists that interacts with the prover and outputs the witness.

[0111] The zero-knowledge proof generated in step S618 may be any other known type of zero-knowledge proof, such as a multi-party computation (MPC)-based zero-knowledge proof (e.g., zkBOO), zkSNARK, STARK, or Bulletproof.

[0112] As known to those skilled in the art, proving and verifying keys work within the context of zkSNARKs, but do not work with other types of zero-knowledge proofs, such as MPC-based proofs (such as zkBOO), STARKs, or Bulletproofs.

[0113] In step S620, the blockchain node 104 removes the confidential bits from the message string RealContentPad and generates a modified message (e.g., a modified blockchain transaction) RealContentPublic. In one example, the blockchain node 104 performs step S620 by assigning the same predetermined value (e.g., 0) to all confidential bits and preserving the public bit value of RealContentPad. In this example, where RealContentPad has a length equal to 512 bits, it is understood that the modified message RealContentPublic also has a length equal to 512 bits.

[0114] Once the modified message (e.g., the modified blockchain transaction) is generated, the original message may be deleted from the memory of the computing device and replaced with the modified message. Alternatively, the original message may be retained in the memory of the computing device after the modified message (e.g., the modified blockchain transaction) is generated.

[0115] The modified blockchain transaction RealContentPublic is then output to a recipient. For example, the modified blockchain transaction RealContentPublic may be sent to a recipient blockchain node 104 in the blockchain network 106.

[0116] To allow the recipient blockchain node 104 to verify that the modified blockchain transaction RealContentPublic is valid, the blockchain node 104 further transmits: Zero-knowledge proofs, The output hash value, Hashvalue.

[0117] If the mask bit string Mask is publicly known, the blockchain node 104 does not need to transmit the mask bit string Mask to the recipient blockchain node 104. However, if the mask bit string Mask is not publicly known, the blockchain node 104 still transmits the mask bit string Mask to the recipient blockchain node 104.

[0118] 10A illustrates a verification process 1000 performed by a verifier computing device when RealContentPublic is 512 bits long. In an embodiment where the computing device is a recipient blockchain node 104, in step S1002, the recipient blockchain node 104 obtains the modified blockchain transaction RealContentPublic. In one example, the recipient blockchain node 104 receives the modified blockchain transaction RealContentPublic from the sender blockchain node 104 (which executes process 600). If the length of the modified blockchain transaction RealContentPublic is 512 bits (as determined in step S1004), process 1000 proceeds to step S1006.

[0119] In step S1006, the recipient blockchain node 104 verifies the output hash value by computing the SHA256 hash of the output hash value and confirms that SHA256(Hashvalue) is equal to the public transaction ID associated with the modified blockchain transaction RealContentPublic. If this verification fails, the process 1000 ends. If the recipient blockchain node 104 successfully verifies the output hash value, the process 1000 proceeds to step S1008.

[0120] In step S1008, the recipient blockchain node 104 verifies the zero-knowledge proof using: Zero-knowledge proofs, Modified Message, RealContentPublic, The input hash value used in step S616 (in this scenario, the initialization vector H i 0), Output hash value, Hashvalue, Mask bit string, Mask.

[0121] If the recipient blockchain node successfully verifies the zero-knowledge proof, the recipient blockchain node 104 can verify that the modified blockchain transaction RealContentPublic is valid.

[0122] In instances where the zero-knowledge proof generated in step S618 is a zkSNARK proof, a verification key (read from the memory of the recipient blockchain node 104) is additionally used in verifying the zkSNARK proof.

[0123] As known to those skilled in the art, verifying a zero-knowledge proof involves one or more checks using input information, and the output of the verification is a decision indicating whether the zero-knowledge proof is valid or invalid. The checks performed are specific to the type of zero-knowledge proof and are known to those skilled in the art. For all types of zero-knowledge proofs, a verifier will only accept the zero-knowledge proof if all checks pass.

[0124] In the context of zkSNARK proofs, the circuit (e.g., shown in Figure 8) is used during the configuration phase, so the configuration parameters (proof key and verification key) ensure that a dedicated circuit is actually being used. The prover uses the proof key and circuit to generate a zkSNARK proof. The verifier uses the verification key to perform the check. The verification key assures the verifier that a predefined statement (meaning the circuit) is indeed validated, without the verifier directly using the circuit. In contrast, in the context of Bulletproofs, the prover and verifier first agree on a circuit. Then, based on the circuit, the prover generates a proof and sends it to the verifier for validation. The verifier also uses knowledge of the circuit to validate the proof. Other MPC-based proofs are similar to Bulletproofs in that the verifier directly used the circuit in the verification process.

[0125] Steps S1006 and S1008 can be performed in any order, but because step S1006 requires fewer computations to perform than step S1008, it is advantageous to perform step S1006 first and then proceed to step S1008 only if the check in step S1006 is successful.

[0126] In the following, we refer to a simple example to illustrate the effect of the mask bit string Mask. Suppose Alice has RealContent="11011011", where the 14th bit "1101" corresponds to her public data that she can share with others, and "1011" is her private data. Suppose also that Alice needs to share her RealContent with Bob, but only wants to reveal the 14th bit. Hence, in this particular example, Mask="00001111". Suppose also that Bob knows the following:

number

[0127] Without the mask bit string Mask, the configuration is as follows:

number

[0128] If Alice is dishonest, she can lie to Bob about the public data (e.g., change 1101 to 0110). 1. Alice selects fake public data as PublicData=01100000, which sets each of the secret bits “1011” to 0. 2. She also chooses the entire 8-bit number 10111011 as her secret data. Note that a.11011011=01100000XOR10111011, and the output hash value of the circuit is the same as the actual Output=SHA256(11011011). Thus, without the mask, she can lie about the public parts of the data while the proof is still valid.

[0129] However, if a mask is used and publicly known, this attack becomes impossible for the following reasons: a. She chooses a fake input PublicData=01100000 and shares it with Bob. 10111011 is the secret data that is partially fake (i.e., the leftmost 4 bits). b. Bob knows the mask value 00001111. Given c.01100000, 00001111, and Output(=SHA256(11011011)), the zkSNARK proof will not be verified by Bob because:

number

[0130] In the above example, each secret bit in "1011" is set to 0, but this is just an example. Alternatively, each secret bit in "1011" can be set to 1, as in PublicData=01101111. This changes the logical calculation to:

number

[0131] However, setting each secret bit to 1 requires an extra operation (AND), making it less efficient than setting each secret bit to 0.

[0132] Now, refer back to FIG. 6A.

[0133] If the length of the RealContentPad is longer than 512 bits, i.e., has a length of 512n bits, where n≧2 (see step S608), the process 600 proceeds to step S622 shown in Figure 6B. In other words, if the size of the RealContent is greater than 447 bits, the process 600 proceeds to step S622 shown in Figure 6c.

[0134] In step S622, the blockchain node 104 divides the message string RealContentPad into multiple message blocks RealContentPad, each having a length of 512 bits corresponding to the input message size defined by the hash function. i Divide into.

number

[0135] FIG. 7 shows an example in which the RealContentPad is 3072 bits long and is divided into six message blocks, each 512 bits long.

[0136] In step S624, the value of i is set to 1, and in step S626, the blockchain node 104 i When step S626 is executed for the first time, it is found that the blockchain node 104 reads the 1512-bit message block RealContent1.

[0137] In step S628, the blockchain node 104 reads the input hash value. It will be appreciated that the first time step S628 is performed, the blockchain node 104 reads a pre-determined public initialization vector from the Secure Hash Standard (SHS), in an embodiment where the SHA256 hash algorithm is used. On subsequent times that step S628 is performed, the blockchain node 104 reads the previous output hash value, i.e., Hashvalue i-1In the context of the SHA256 algorithm, the input hash value is 256 bits long.

[0138] In step S630, the blockchain node 104 generates the message block RealContent i Hash value by hashing i where Hashvalue i =SHA256(RealContent i The input hash value read in step S628 is used in the compression performed in step S630. i-1 is read as the input hash value the next time step S628 is executed. For example, the hash value Hashvalue1 is used as the input hash value for compression of the second message block RealContent2.

[0139] Message Block RealContent i If i does not contain any confidential bits (as determined in step S632), the process proceeds to step S644 shown in Figure 6D. If there are more message blocks consisting of confidential data to process (as determined in step S644), the process proceeds to step S646, where the blockchain node 104 increments the value of i by one, and the process 600 loops back to step S626, where the blockchain node 104 increments the value of i by one for the next RealContent i Read out.

[0140] Message Block RealContent i If includes a confidential bit (as determined in step S632), the blockchain node 104 performs steps S634, S636, S638, S640, and S642 shown in Figure 6D. S634, S636, S638, S640, and S642 correspond to S610, S612, S614, S618, and S620.

[0141] In step S642, the blockchain node 104 transfers the RealContent i In one example, the blockchain node 104 performs step S642 by assigning the same predetermined value (e.g., 0) to all confidential bits in the RealContentPad and preserving the public bit value of the RealContentPad.

[0142] As an alternative to steps S634 and S636, the blockchain node 104 reads the mask bit string from the memory of the blockchain node 104 to generate the mask bit string Mask i You can get the mask bit string Mask i Regardless of how the mask bit string Mask is obtained, in this embodiment, i is 512 bits in length.

[0143] After step S642 is performed, the process 600 proceeds to step S644 described above.

[0144] If there are no more message blocks containing sensitive data to process (as determined in step S644), then process 600 ends. At the end of process 600, blockchain node 104 has removed all sensitive bits from the message string RealContentPad to generate a modified message (e.g., modified blockchain transaction) RealContentPublic.

[0145] As is apparent from the above, process 600 uses a pre-determined public initialization vector X0, which in an embodiment would be from the Secure Hash Standard (SHS) when the SHA256 hash algorithm is used to compress the first message block, RealContent1. The digest Hashvalue1 of the first compression is used as the input hash value X1 in the compression of the second message block, RealContent2. The digest Hashvalue2 of the second compression is used as the input hash value X2 in the compression of the third message block, RealContent3, and so on. Figure 9 shows an example circuit for this recursive hashing as described above. As previously mentioned, the secret bit string SecretData i The exact bitwise logic operations used to derive M may differ from those shown in Figure 9. For each message block, PublicData i , Mask i , and SecretData i is 512 bits long, so the final output of the bitwise logical calculation is RealContent i will be 512 bits long.

[0146] As is clear from the above, any message block containing confidential bits, RealContent i In process 600, the blockchain node 104 generates a zero-knowledge proof using: Public bitstream, PublicData i , Mask bit string, Mask i , Output hash value, Hashvalue i , Secret bit string SecretData i .

[0147] In the example where the zero-knowledge proof generated in step S640 is a zkSNARK proof, a proof key (which is read from the memory of the blockchain node 104) is additionally used in generating the zkSNARK proof.

[0148] In scenarios where multiple message blocks contain sensitive data, although Figures 6C and 6D show an iterative process, in some embodiments the proof generation process is performed in parallel. In these embodiments, each message block is hashed using the input hash value corresponding to the hashed output (digest) of the previous block (or, in the case of the first message block, the predetermined initialization vector X0, as described above). The calculated hash value Hashvalue associated with a message block containing sensitive data i Using , we can generate zero-knowledge proofs for these message blocks in parallel, independently of each other. This parallel execution can create N zero-knowledge proofs in the same time it takes to generate a single zero-knowledge proof, assuming sufficient computational resources. This parallel proof generation has the advantage of being able to handle large messages efficiently.

[0149] The modified blockchain transaction RealContentPublic is then output to a recipient. For example, the modified blockchain transaction RealContentPublic may be sent to a recipient blockchain node 104 in the blockchain network 106.

[0150] To allow the recipient blockchain node 104 to prove that the modified blockchain transaction RealContentPublic is valid, the blockchain node 104 creates a RealContentPublic containing the confidential bit. i Each time, it also sends: Zero-knowledge proofs, Output hash value, Hashvalue i .

[0151] Mask bit string Mask i is publicly known, the blockchain node 104 may use the mask bit string Mask i However, there is no need to send the mask bit string Mask to the recipient blockchain node 104. i If is not publicly known, the blockchain node 104 may use the mask bit string Mask i to the recipient blockchain node 104.

[0152] FIG. 10B illustrates a verification process 1050 performed by the verifier computing device when the RealContentPublic is greater than 512 bits long (ie, has a length of 512n bits, where n≧2).

[0153] In step S1010, a computing device (e.g., a recipient blockchain node 104) receives the last message block RealContentPublic. t Hash value of t Get the Hashvalue t Calculate the SHA256 hash of t ) is equal to the public transaction ID associated with the modified blockchain transaction RealContentPublic.

[0154] Last Message Block RealContent t In an example where includes a confidential bit, the recipient blockchain node 104 receives the hash value of the last message block from the sender computing device. t Receive the final message block RealContent t In an example where the RealContent does not contain any secret bits, the recipient blockchain node 104 receives the last message block RealContent from the sender computing device. t Hash value of tAlternatively, the recipient blockchain node 104 may receive the last message block RealContent t SHA256 hash of the previous message block RealContent t-1 Calculate the output hash value Hashvalue (using the output hash value from hashing) t may be generated.

[0155] If this verification fails, then process 1050 ends. Step S1010 can be performed at the end of process 1050 when there are no more message blocks to process, but because step S1010 requires fewer computations to perform than a zero-knowledge proof verification, it is advantageous to perform step S1010 first and then proceed to perform the zero-knowledge proof verification only if the check in step S1010 is successful.

[0156] The recipient blockchain node 104 outputs the hash value Hashvalue t If the verification is successful, the process 1000 proceeds to step S1012.

[0157] In step S1012, the blockchain node 104 divides the message string RealContentPublic into multiple message blocks, each having a length of 512 bits corresponding to the input message size defined by the hash function. i Divide into.

number

[0158] In step S1014, the value of i is set to 1, and in step S1016, the blockchain node 104 i When step S626 is executed for the first time, it is found that the blockchain node 104 reads the 1512-bit message block RealContent1.

[0159] In step S1018, the blockchain node 104 generates a mask bit string Mask i Using the message block RealContent i Determine whether a secret bit is present in

[0160] Message Block RealContent i If does not contain a secret bit, process 1050 proceeds to step S1020, where the recipient blockchain node 104 reads the input hash value. It will be appreciated that the first time step S1020 is performed, the blockchain node 104 reads a pre-determined public initialization vector from the Secure Hash Standard (SHS), in an embodiment where the SHA256 hash algorithm is used. On subsequent times that step S1020 is performed, the blockchain node 104 reads the previous output hash value, i.e., Hashvalue i-1 Read out.

[0161] In step S1022, the blockchain node 104 generates the message block RealContent i Hash value by hashing i where Hashvalue i =SHA256(RealContent i The input hash value read in step S1020 is used in the compression performed in step S1022.

[0162] Message Block RealContent i If the RealContent i Verify the zero-knowledge proof for using: RealContent i Zero-knowledge proof of Message Block RealContent i , Output hash value, Hashvalue i .

[0163] RealContent i Input hash value (Hashvalue i-1 ), i.e. the hashed output (digest) of the previous block, The input hash value used to compress the modified message, Mask bit string, Mask i , In instances where the zero-knowledge proof generated in step S640 is a zkSNARK proof, a verification key (read from the memory of the recipient blockchain node 104) is additionally used in verifying the zkSNARK proof.

[0164] As mentioned above, step S1020 is preferably performed before step S1022, but steps S1020 and S1022 may be performed in any order.

[0165] If there are more message blocks to process (as determined in step S1025), the process proceeds to step S1026, where the blockchain node 104 increments the value of i by one, and the process 1050 loops back to step S1016, where the blockchain node 104 increments the value of i by one. i Read out.

[0166] If the recipient blockchain node successfully verifies each of the zero-knowledge proofs, the recipient blockchain node 104 can verify that the modified blockchain transaction RealContentPublic is valid.

[0167] In scenarios where multiple message blocks have sensitive data, the proof verification process is performed in parallel in some embodiments, although Figure 10B shows an iterative process. As mentioned above, each message block RealContent containing sensitive bits i, the recipient blockchain node 104 generates a zero-knowledge proof of the message block and the output hash value Hashvalue of the message block. i The blockchain node 104 hashes the message block using the input hash value corresponding to the hashed output (digest) of the previous block (or, in the case of the first message block, the predefined initialization vector X0, as described above) to obtain the remaining hash value Hashvalue of the block that does not contain any confidential data. i All hash values ​​can be calculated. i Once calculated, each verification of the zero-knowledge proofs associated with the message blocks containing the secret data performed in step S1024 can be performed in parallel. This parallel execution allows verification of N zero-knowledge proofs in the same time it takes to verify a single zero-knowledge proof, assuming sufficient computational resources.

[0168] 7 shows an example in which the length of RealContentPad is 3072 and it is divided into six message blocks RealContent1 to RealContent6. In the example of FIG.

[0169] By implementing process 600, each message block containing public data RealContent1 to RealContent3 is hashed to generate a respective output hash value, but because these contain only public data, zero-knowledge proofs for message blocks RealContent1 to RealContent3 are not generated.

[0170] Because the message block RealContent4 contains sensitive data, the blockchain node 104 generates a zero-knowledge proof for RealContent4 using: Public bitstream, PublicData4, Mask bit string, Mask4, The output hash value, Hashvalue4 (calculated using the compressed digest of message block RealContent3, Hashvalue3, as the input hash value), Secret bit string, SecretData4, The proof key read from the memory of the blockchain node 104 (when using a setting where zero-knowledge proofs are trusted, such as zkSNARK proofs).

[0171] Because the message block RealContent5 contains sensitive data, the blockchain node 104 generates a zero-knowledge proof for RealContent5 using: Public bitstream, PublicData5, Mask bit string, Mask5, The output hash value, Hashvalue5 (calculated using the compressed digest of message block RealContent4, Hashvalue4, as the input hash value), Secret bit string, SecretData5, The proof key read from the memory of the blockchain node 104 (when using a setting where zero-knowledge proofs are trusted, such as zkSNARK proofs).

[0172] At the end of process 600, the confidential bit 704 is removed from RealContentPad, generating the modified blockchain transaction RealContentPublic.

[0173] The modified blockchain transaction RealContentPublic is then output to a recipient. For example, the modified blockchain transaction RealContentPublic may be sent to a recipient blockchain node 104 in the blockchain network 106.

[0174] To allow the recipient blockchain node 104 to verify that the modified blockchain transaction RealContentPublic is valid, the blockchain node 104 further transmits: RealContent4 zero-knowledge proof, Output hash value, Hashvalue4, Zero-knowledge proofs for RealContent5, Output hash value, Hashvalue5.

[0175] If the mask bit string Mask4 is publicly known, then the blockchain node 104 does not need to transmit the mask bit string Mask4 to the recipient blockchain node 104. However, if the mask bit string Mask4 is not publicly known, then the blockchain node 104 will further transmit the mask bit string Mask4 to the recipient blockchain node 104. Similarly, if the mask bit string Mask5 is publicly known, then the blockchain node 104 does not need to transmit the mask bit string Mask5 to the recipient blockchain node 104. However, if the mask bit string Mask5 is not publicly known, then the blockchain node 104 will further transmit the mask bit string Mask5 to the recipient blockchain node 104.

[0176] To verify that the modified blockchain transaction RealContentPublic is valid, the recipient blockchain node 104 uses a predefined public initialization vector X0 from the Secure Hash Standard (SHS) in the compression of the first message block RealContent1, in an embodiment where the SHA256 hash algorithm is used. The digest Hashvalue1 of the first compression is used as the input hash value X1 in the compression of the second message block RealContent2. The digest Hashvalue2 of the second compression is used as the input hash value X2 in the compression of the third message block RealContent3.

[0177] The recipient blockchain node 104 verifies the RealContent4 zero-knowledge proof using: RealContent4 zero-knowledge proof, RealContentPad message block RealContent4, Output hash value, Hashvalue4, The input hash value (Hashvalue3) of RealContent4, i.e. the hashed output (digest) of the previous block, Mask bit string, Mask4, The proof key read from the memory of the recipient blockchain node 104 (when using a setting where zero-knowledge proofs are trusted, such as zkSNARK proofs).

[0178] The recipient blockchain node 104 verifies the RealContent5 zero-knowledge proof using: Zero-knowledge proofs for RealContent5, RealContentPad message block RealContent5, Output hash value, Hashvalue5, The input hash value (Hashvalue4) of RealContent5, i.e. the hashed output (digest) of the previous block, Mask bit string, Mask5, The verification key read from the memory of the recipient blockchain node 104 (if the zero-knowledge proof is a zkSNARK proof).

[0179] In this example, because the last message block RealContent6 does not contain sensitive data, the recipient blockchain node 104 can calculate the SHA256 hash of the last message block RealContent6 (using the output hash value Hashvalue5 associated with the fifth message block RealContent5 as the input hash value) to produce the output hash value Hashvalue6.

[0180] The recipient blockchain node 104 then calculates the SHA256 hash of Hashvalue6 and verifies that SHA256(Hashvalue6) is equal to the public transaction ID associated with the modified blockchain transaction RealContentPublic.

[0181] 6C and 6D, on the other hand, illustrate the generation of a zero-knowledge proof for each message block containing sensitive data. In other embodiments, adjacent message blocks of a RealContentPad containing sensitive data can be merged, with a single zero-knowledge proof being generated for the merged block.

[0182] Returning to the example of Figure 7, suppose RealContentPad has a length of 3072 and is divided into six message blocks, RealContent1 through RealContent6, with message blocks RealContent4 and RealContent5 containing confidential bits 704. In these other embodiments, blockchain node 104 generates a 1024-bit merged block by concatenating RealContent4 and RealContent5. merged =RealContent4││RealContent5.

[0183] In these other embodiments, the blockchain node 104 generates a zero-knowledge proof of the merged block using: By assigning a zero value to the confidential bit and preserving the public bit value, the RealContent merged PublicData is a public bit string calculated by modifying merged In this example, the length of PublicData is 1024 bits. Mask bit string Mask merged The merged block RealContent merged Identifies the location of the secret bit in the Mask. merged=Mask4||Mask5 (concatenated), so Mask merged is 1024 bits in length. Merged Block RealContent merged The hash value of the last message block in the merged block RealContent. In this example, the output hash value is Hashvalue5 (calculated using the compressed digest of message block RealContent4, Hashvalue4, as the input hash value). Here, the last message block is the merged block RealContent. merged is part of. Merged Block RealContent merged SecretData is a secret bit string containing the sensitive bits of merged Blockchain node 104 is a RealContent merged and preserve the secret bits contained therein to create a secret bit string, SecretData merged The remaining bits of SecretDatav can take any value. Secret bit string SecretData merged meets the following requirements:

number

[0184] The recipient blockchain node 104 receives the RealContent merged Verify the zero-knowledge proof of: RealContent merged Zero-knowledge proof of Merged Blocks, RealContent merged , Merged Block RealContent mergedThe input hash value, in this example Hashvalue3, Output hash value, Hashvalue5, Mask bit string, Mask merged , A verification key read from the memory of the recipient blockchain node 104 (when using a setting where zero-knowledge proofs are trusted, such as zkSNARK proofs).

[0185] The recipient blockchain node 104 knows the hash output of hashing the third message block, RealContent3, and stores it as RealContent merged Use this as the input hash value for Hashvalue5. merged This hashing is used as the input hash value for the compression of the sixth message block, RealContent6.

[0186] The above technique for merging adjacent blocks is similar to the message block RealContent i There is not enough entropy in the message block RealContent i This can be used when a malicious party may be able to brute force the secret bits present in the message block RealContent i If the number of secret bits in the message block RealContent is less than a predetermined threshold, i may be considered to not have sufficient entropy. The predetermined threshold may be a collision-resistant security level associated with the hash function used in embodiments of the present disclosure. For example, the collision-resistant security level associated with the SHA256 hash function is 128 bits. This means that a maximum of 2 128 This means that is required.

[0187] Thus, in an embodiment of the present disclosure, a blockchain node 104 identifies a message block containing sensitive data that contains a number of sensitive bits below a preset threshold, and merges the message block with at least one adjacent message block that also contains sensitive data to form a merged block, RealContent merged This merge can be configured to generate a merged block, RealContent merged The implementation may be such that the number of secret bits in exceeds a pre-set threshold.

[0188] For example, if a 512-bit message block, RealContent4, contains 56 secret bits and a 512-bit message block, RealContent5, contains 100 secret bits, then RealContent merged contains 156 secret bits that exceed the 128-bit collision-resistant security level associated with the SHA256 hash function.

[0189] The computational cost of generating a single zero-knowledge proof for the merged block (generated by concatenating two message blocks) is the same as the computational cost of generating a zero-knowledge proof for each of the two message blocks, but the time it takes to generate a single zero-knowledge proof is doubled. This is because, since all necessary inputs are available, including all intermediate states (hash values) from the original contents, generating a zero-knowledge proof for each of the two message blocks can be computed in parallel, i.e., each block can be computed independently.

[0190] Additionally, the blockchain node 104 may be configured to identify that a message block containing sensitive data contains a number of sensitive bits below a pre-set threshold and to designate one or more of the public bits as sensitive bits to increase entropy.

[0191] As previously mentioned, the message may be a blockchain transaction received by a computing device.

[0192] In one example implementation, the computing device is a blockchain node 104. The blockchain node 104 can receive blockchain transactions from computer terminals 102 of users of a blockchain network 106. The computer terminals 102 request that the blockchain transactions be propagated and recorded in the blockchain. The blockchain node 104 can perform the methods described herein to remove sensitive data from the blockchain transactions before propagating the modified blockchain transactions with information necessary to verify the modified blockchain transactions to other blockchain nodes 104 in the network 106.

[0193] In another implementation, the computing device is a blockchain node 104. The blockchain node 104 can receive blockchain transactions from a user's computer terminal 102 or another blockchain node 104 in the blockchain network 106, thereby recording the transactions in the blockchain. Before adding the received transaction to the mempool, the blockchain node 104 can perform methods described herein to remove confidential data from the blockchain transaction. The modified blockchain transaction is then added to the mempool. Once the blockchain node 104 identifies a valid proof-of-work solution, the blockchain node 104 generates a new blockchain block 151 containing the modified blockchain transaction. The new block 151, along with the information necessary to validate the accuracy of the modified blockchain transaction, is then propagated to other nodes in the network so that each node can record the new block 151 in the blockchain.

[0194] In another implementation, a computing device may receive a block 151 recorded in the blockchain from another blockchain node 104. This block includes a transaction.

[0195] The computing device may be, for example, a blockchain node 104. In response to receiving the block 151, the blockchain node 104 may perform the methods described herein to remove sensitive data from the blockchain transaction. The block 151 containing the modified blockchain transaction is then transmitted to other nodes in the network along with information necessary to validate the accuracy of the modified blockchain transaction, so that each node can record the new block 151 in the blockchain. Alternatively, in response to receiving a request for the block 151 from the recipient blockchain node 104, the blockchain node 104 transmits the block 151 containing the modified blockchain transaction and the information necessary to validate the modified blockchain transaction to the recipient blockchain node 104. For example, the recipient blockchain node 104 may be a new miner joining the Bitcoin network who needs to download the entire blockchain and validate all transactions to build a UTXO set.

[0196] In a variation of the above, in response to receiving the block 151, the blockchain node 104 may store the block in memory. In response to receiving a request for the block from a recipient blockchain node 104, the blockchain node 104 may perform the methods described herein to remove sensitive data from the blockchain transaction. The block containing the modified blockchain transaction is then transmitted to other nodes in the network along with the information necessary to validate the accuracy of the modified blockchain transaction. For example, the recipient blockchain node 104 may be a new miner joining the Bitcoin network who needs to download the entire blockchain and validate all transactions to build the UTXO set.

[0197] In another implementation, the computing device is not a blockchain node 104 on the blockchain network 106 (i.e., not an active node on the blockchain network 106). That is, the computing device is external to the blockchain network 106. The computing device may be coupled to the blockchain network 106, for example. The computing device maintains a copy of the blockchain 150 and provides blockchain data (e.g., blocks 151 recorded in the blockchain 150) to the client device 102. The computing device may receive blocks recorded in the blockchain 150 from one or more of the blockchain nodes 104. In response to receiving the blocks, the computing device may perform a method described herein to remove sensitive data from the blockchain transactions. The blocks containing the modified blockchain transactions are then transmitted to the client device along with information necessary to validate the accuracy of the modified blockchain transactions. Alternatively, in response to receiving a request for a block from the client device, the computing device transmits the blocks containing the modified blockchain transactions and the information necessary to validate the modified blockchain transactions to the client device. In a variation of the above, in response to receiving the blocks, the computing device may store the blocks in memory. In response to receiving a request for a block from a client device, a computing device can perform the methods described herein to remove sensitive data from a blockchain transaction. The block containing the modified blockchain transaction is then transmitted to the client device along with information necessary to validate the accuracy of the modified blockchain transaction.

[0198] Here, we describe an example in which a computing device can obtain the mask bit string by retrieving the mask bit string from the memory of the computing device. This may be possible if a government or regulatory agency identifies that a transaction in a block already recorded on the blockchain contains sensitive (e.g., illicit) data. In this scenario, the government / regulatory agency can publish the transaction ID and mask bit string to the computing device, e.g., a blockchain node 104 on the network 106.

[0199] Although embodiments are described herein with respect to messages that are blockchain transactions, embodiments of the present disclosure extend outside the context of Bitcoin and other blockchains and can be used to block any portion of a hash preimage.

[0200] As an example, a message may be a person's passport information: in the example of Figure 7, where RealContentPad has a length of 3072 and is divided into six message blocks, RealContent1 through RealContent6, each message block contains the person's identity attributes (e.g., name, date of birth, place of birth, passport number, issue date, expiration date).

[0201] In this example, message blocks RealContent1 through RealContent6 may be stored in an electronic passport along with a government signature on the hash value Hashvalue6 of the last message block RealContent6. The electronic passport may be in the form of a physical passport document that includes an embedded integrated circuit (e.g., a computing device) for storing and processing data. That is, the embedded integrated circuit on the physical passport document may be configured to perform embodiments of the present disclosure.

[0202] Alternatively, the e-passport may be in the form of an electronic passport document stored in the memory of a computing device (e.g., a mobile phone). This can be a virtual mobile ID that can be derived from already-issued government credentials, such as an e-Passport, which can be securely loaded onto a mobile device, such as a phone or token.

[0203] If the message blocks RealContent4 and RealContent5 include confidential bits, the computing device can perform the methods described herein to remove the confidential data from the copy of the passport information and generate modified passport information that includes only selected attributes of the original passport information. The modified passport information is then output to a recipient along with the information necessary to validate the modified passport information. For example, the computing device may transmit the modified passport information along with the information necessary to validate the modified passport information to a remote device (e.g., a computer terminal at an airport). In another example, the computing device may output the modified passport information and the information necessary to validate the modified passport information to a display of the computing device, allowing the recipient to verify the displayed information.

[0204] When a modified message (e.g., modified passport information) is generated, the original message (person's passport information) is not deleted from memory as it may be needed for later verification with other entities.

[0205] To enable the remote device to verify that the modified passport information is valid, the computing device further transmits a RealContent i For each, send: Zero-knowledge proofs, Output hash value, Hashvalue i .

[0206] Mask bit string Mask i is publicly known, the blockchain node 104 may use the mask bit string Mask i However, the mask bit string Mask i is not publicly known, the computing device may i to the remote device.

[0207] The remote device can use process 1050 to verify that the changed passport information is valid by: 1) Hash value of the last message block in RealContentPad t Obtain the hash value obtained. t Hashvalue t Verify that Hashvalue is equal to a trusted hash value previously stored in the memory of the remote device. t corresponds to the hash value Hashvalue6 of the last message block RealContent6. Thus, in the Bitcoin scenario (described above with reference to step S1010), it is the transaction ID that is the trusted value, whereas in the context of passport information, the trusted value is a trusted hash value that is pre-stored in the memory of the remote device.

[0208] As mentioned above, if the final message block contains secret bits, the computing device generates a Hashvalue t If the final message block does not contain the secret bit, the computing device receives the Hash value from the verification process it performs. t can be obtained, so that the computing device can t does not need to be sent to the remote device.

[0209] 2) Use the RealContent i Verify the zero-knowledge proof for each: RealContent i Zero-knowledge proof of RealContent i Output hash value, Hashvalue i , RealContent i Initialization vector (Hashvalue i-1 ), mask bit string, Mask i , The verification key read from the remote device's memory (if the zero-knowledge proof is a zkSNARK proof).

[0210] Other examples are possible. For example, embodiments of the present disclosure allow for selective disclosure of some information stored on a driver's license (e.g., to prove that the person is over the age of 18) without disclosing other information, such as the person's place of residence and / or handwritten signature. The driver's license may be a physical document or card, or may be stored electronically in the memory of a computing device.

[0211] In another example, embodiments of the present disclosure enable selective disclosure of some information stored on an ID card to prove that a person is a resident of London without disclosing other information. The ID card may be a physical object or may be stored electronically in the memory of a computing device.

[0212] Embodiments of the present disclosure allow flexibility to allow a person to create different masks to selectively reveal different portions of information of the same data to different entities at different times.

[0213] conclusion Other variations or uses of the disclosed technology may become apparent to those skilled in the art after reading the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0214] For example, although embodiments have been described above with reference to the SHA256 hash function (also referred to herein as a hash algorithm), embodiments of the present disclosure may utilize any hash function. By way of example only, other types of hash functions, such as Pedersen or MiMC hash functions, may be used.

[0215] Furthermore, embodiments of the present disclosure are not limited to using a particular type of zero-knowledge proof. By way of example only, the zero-knowledge proof may utilize the algorithm described in the paper by Jens Groth, "On the size of pairing-based non-interactive arguments. In Advances in Cryptology," EUROCRYPT 2016 - 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II, pages 305-326, 2016.

[0216] While the removal of the confidential bits from the RealContentPad in steps S620 and S642 is described with respect to assigning all confidential bits the same predetermined value (e.g., 0) and preserving the public bit values ​​of the RealContentPad, in other embodiments, these steps may include completely removing the confidential bit locations from the RealContentPad, such that this modified version of the RealContentPad includes only public bits. A message string of the modified version of the RealContentPad is then output to the recipient. For example, the modified version of RealContentPublic may be sent to a recipient blockchain node 104 in the blockchain network 106. Thus, in these examples, rather than receiving the modified blockchain transaction RealContentPublic from the sender blockchain node 104 (which performed process 600), the recipient blockchain node 104 can use the modified version of RealContentPab and the mask bit string Mask to reconstruct the modified blockchain transaction RealContentPublic (with all confidential bits assigned the same predetermined value).

[0217] Some embodiments described above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it is understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced by the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchain, blockchain network, and / or blockchain nodes may share some or all of the above-described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104.

[0218] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the above-mentioned functions of generating, publishing, propagating, and storing blocks 151 in the blockchain 150. It is not excluded that there are 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, but may not generate and publish blocks (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0219] In other embodiments of the present invention, 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, but not all, of the functions of generating, publishing, propagating, and storing blocks 151 of blockchain 150. For example, in these other blockchain networks, "node" may be used to refer to a network entity that is configured to generate and publish blocks 151 but does not store and / or propagate the blocks 151 to other nodes.

[0220] More generally, references above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element." Such entities / elements are configured to perform some or all of the roles of generating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above with reference to blockchain nodes 104.

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

[0222] Aspects of the present disclosure are defined below with reference to the following clauses:

[0223] (Section 1) 1. A method for blocking sensitive data in a message, the method being executed on a computing device and comprising: making a copy of said message; Generating at least one zero-knowledge proof, and generating each of the at least one zero-knowledge proof includes: obtaining a mask bit string that identifies the location of at least one secret bit within the bits of said copy; calculating a public bit string by modifying said at least one secret bit of said copy by assigning said secret bit a predetermined value; determining a secret bit string, the secret bit string including the at least one secret bit and satisfying the requirement that the bits of the copy are equal to the output of a bitwise logical calculation using the public bit string, the mask bit string, and the secret bit string; hashing a copy of the message or a portion thereof to generate an output hash value; generating a zero-knowledge proof using the public bit string, the mask bit string, the output hash value, and the secret bit string; and removing each of the at least one secret bit from the copy to generate a modified message; outputting the modified message to the recipient together with the at least one output hash value and the at least one zero-knowledge proof to enable the recipient to prove that the modified message is valid; A method comprising:

[0224] (Section 2) padding a copy of the message before generating at least one zero-knowledge proof so that the copy has a length that is a positive integer multiple of the input message size as defined by the hash function used in hashing; if the length of the copy corresponds to the input message size as defined by the hash function, a single zero-knowledge proof is generated by hashing the copy of the message, using a public initialization vector to generate the output hash value; Item 1. The method according to item 1, further comprising:

[0225] (Section 3) and before generating the at least one zero-knowledge proof, padding the copy of the message so that the copy has a length that is a positive integer multiple of the input message size as defined by the hash function used for hashing; If the length of the copy after padding is greater than the input message size defined by the hash function, the method dividing a copy of the message into a plurality of message blocks, each message block having a length corresponding to the input message size as defined by the hash function; identifying one or more message blocks containing sensitive data; Including, Item 1. The method of item 1, wherein a zero-knowledge proof is generated for each of the one or more message blocks containing secret data.

[0226] (Section 4) Item 3. The method of item 3, wherein for one or more of the at least one zero-knowledge proof, bits of the copy correspond to bits of a message block of the one or more message blocks, and the zero-knowledge proof is generated by hashing the message block to generate an output hash value.

[0227] (Section 5) 5. The method of claim 4, wherein the plurality of message blocks includes a first message block and one or more further message blocks, and if the first message block contains confidential data, a public initialization vector is used for hashing the first message block, and if the further message block contains confidential data, a hash value output from hashing a message block immediately preceding the further message block is used for hashing the further message block.

[0228] (Section 6) 6. The method according to any one of items 3 to 5, wherein some message blocks of the plurality of message blocks contain confidential data, and the method includes a step of generating zero-knowledge proofs in parallel for each of the some message blocks.

[0229] (Section 7) 7. The method of any of clauses 3 to 6, wherein for one of the at least one zero-knowledge proof, bits of the copy correspond to bits of a merged block, the merged block including multiple adjacent message blocks each including secret data, the zero-knowledge proof is generated by iteratively hashing each message block in the merged block, and an output hash value is generated by hashing the final message block of the merged block using a hash value output from hashing a message block of the multiple adjacent message blocks that immediately precedes the final message block.

[0230] (Section 8) identifying message blocks containing sensitive data as containing a number of sensitive bits below a predetermined threshold; merging the message block with at least one adjacent message block containing sensitive data to generate a merged block; Item 8. The method according to Item 7, further comprising:

[0231] (Section 9) Item 9. The method of item 8, wherein the predetermined threshold is defined by the collision resistance of the hash function.

[0232] (Section 10) 10. The method according to any one of clauses 1 to 9, wherein the secret bit string satisfies the requirement that the bits of the copy are equal to the bitwise XOR of (i) the public bit string and (ii) the result of a bitwise AND of the mask bit string and the secret bit string.

[0233] (Section 11) 11. The method according to any one of items 1 to 10, wherein obtaining the mask bit string includes reading the mask bit string from a memory.

[0234] (Section 12) Obtaining the mask bit string locating at least one secret bit within the bits of the copy of the message; generating a mask bit string that identifies the location of the at least one sensitive bit within the copy; Item 11. The method according to any one of Items 1 to 10, comprising:

[0235] (Section 13) 13. The method according to any one of items 1 to 12, further comprising the step of outputting the at least one masked bit sequence to the recipient.

[0236] (Section 14) 17. The method of any of clauses 1 to 16, wherein the outputting step includes sending the modified message together with the at least one output hash value, the at least one public bit string, and the at least one zero-knowledge proof to a remote device associated with the recipient.

[0237] (Section 15) 14. The method of claim 13, wherein the message includes blockchain transaction data and the modified message includes modified blockchain transaction data.

[0238] (Section 16) Item 15. The method of item 14, wherein the computing device is a blockchain node in a blockchain network.

[0239] (Section 17) 17. The method of clause 16, wherein the blockchain transaction data is received from a client device requesting that the blockchain transaction be recorded in a blockchain, the remote device being a further blockchain node in the blockchain network, and the modified blockchain transaction data is sent to the further blockchain node for propagation within the blockchain network.

[0240] (Section 18) the remote device is a further blockchain node in the blockchain network, and the method comprises: receiving the blockchain transaction; generating a block to be recorded in a blockchain, the block including the modified blockchain transaction data; transmitting the block containing the modified blockchain transaction data to the further blockchain node in the blockchain network; 16. The method according to any one of items 1 to 15, comprising:

[0241] (Section 19) Item 16. The method of item 15, wherein the computing device is external to the blockchain network and the remote device is a client device.

[0242] (Section 20) 20. The method of claim 16 or 19, comprising receiving a block recorded in a blockchain, the block comprising transaction data of the blockchain.

[0243] (Section 21) 21. The method of claim 20, wherein the generating, deleting, and transmitting steps are performed in response to receiving the block.

[0244] (Section 22) 21. The method of claim 20, wherein the generating and deleting steps are performed in response to receiving the block, and the transmitting step is performed in response to receiving a request for the block from the remote device.

[0245] (Section 23) 21. The method of clause 20, wherein the generating, deleting, and transmitting steps occur in response to receiving a request for the block from the remote device.

[0246] (Section 24) 24. The method according to any one of clauses 1 to 23, wherein at least one zero-knowledge proof is a zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof.

[0247] (Section 25) 25. The method of claim 24, wherein generating the zero-knowledge proof further comprises using a proof key.

[0248] (Section 26) 26. The method according to any one of items 1 to 25, further comprising the steps of: after generating the modified message, deleting the message from memory; and storing the modified message in memory.

[0249] (Section 27) A computer program embodied on a computer-readable storage device, configured to perform the method of any of paragraphs 1 to 26 when run on a computing device.

[0250] (Section 28) A computing device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform the method of any one of paragraphs 1 to 26.

[0251] (Section 29) 1. A method for verifying that a modified message is valid, the modified message corresponding to an original message with sensitive data removed, the method being executed on a computer device, comprising: obtaining the modified message, the modified message corresponding to the original message with each secret bit assigned a predetermined value; obtaining an output hash value of the modified message and verifying the output hash value using data stored in a memory of the computing device; receiving, from a sending device, at least one zero-knowledge proof associated with bits of the modified message; verifying each of the at least one zero-knowledge proof using: (i) knowledge of a bitwise logic operation used by the sending device to derive the secret bit sequence used to generate the zero-knowledge proof, or a verification key associated therewith; (ii) the bits of the modified message; (iii) a mask bit sequence identifying the location of at least one secret bit within the bits of the modified message; (iv) a hash value or a portion thereof of the bits of the modified message; and (v) an input hash value of the bits of the modified message; A method comprising:

[0252] (Section 30) 30. The method of clause 29, wherein obtaining the modified message comprises receiving the modified message from the sending device.

[0253] (Section 31) obtaining the modified message, receiving a version of the original message that includes only the public bit of the original message; generating the modified message using the version of the original message and the mask bit sequence; Item 30. The method of item 29, comprising:

[0254] (Section 32) 32. The method of any of clauses 29 to 31, wherein the bits of the modified message correspond to the entire modified message, and the modified message has a length corresponding to an input message size defined by a hash function used to generate an output hash value of the modified message.

[0255] (Section 33) 32. The method of any of clauses 29 to 31, wherein the modified message includes a plurality of message blocks, the output hash value is a hash of an ending message block of the plurality of message blocks, and the plurality of message blocks have a length corresponding to an input message size defined by a hash function used to generate the output hash value.

[0256] (Section 34) 34. The method of claim 33, wherein the bit of the modified message corresponds to one of the plurality of message blocks.

[0257] (Section 35) 32. The method of any one of clauses 29 to 31, wherein the bits of the copy correspond to bits of a merged block, the merged block includes multiple adjacent message blocks containing secret data, and the step of verifying the zero-knowledge proof uses a hash value of the final message block of the merged block.

[0258] (Section 36) 36. The method of any of clauses 29 to 35, wherein the original message is a blockchain transaction, the data stored in the memory of the computing device is a transaction identifier associated with the blockchain transaction, and the step of verifying the output hash value includes hashing the output hash value and comparing the output of the hashing with the transaction identifier.

[0259] (Section 37) 37. A method according to any one of clauses 29 to 36, wherein multiple zero-knowledge proofs associated with bits of the modified message are received from the sending device, and the step of verifying the multiple zero-knowledge proofs is performed in parallel.

[0260] (Section 38) A computer program embodied on a computer-readable storage device, configured to perform the method according to any one of clauses 29 to 37 when executed on a computing device.

[0261] (Section 39) A computing device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the computing device to perform the method of any one of paragraphs 29 to 37.

Claims

1. 1. A method for blocking sensitive data in a message, the method being executed on a computing device and comprising: making a copy of said message; Generating at least one zero-knowledge proof, and generating each of the at least one zero-knowledge proof includes: obtaining a mask bit string that identifies the location of at least one secret bit within the bits of the copy; calculating a public bit string by modifying said at least one secret bit of said copy by assigning said secret bit a predetermined value; determining a secret bit string, the secret bit string including the at least one secret bit and satisfying the requirement that the bits of the copy are equal to the output of a bitwise logical calculation using the public bit string, the mask bit string, and the secret bit string; hashing a copy of the message or a portion thereof to generate an output hash value; generating a zero-knowledge proof using the public bit string, the mask bit string, the output hash value, and the secret bit string; and removing each of the at least one secret bit from the copy to generate a modified message; outputting the modified message to the recipient together with the at least one output hash value and the at least one zero-knowledge proof to enable the recipient to prove that the modified message is valid; A method comprising:

2. padding a copy of the message before generating at least one zero-knowledge proof so that the copy has a length that is a positive integer multiple of the input message size as defined by the hash function used in hashing; if the length of the copy corresponds to the input message size as defined by the hash function, a single zero-knowledge proof is generated by hashing the copy of the message, using a public initialization vector to generate the output hash value; The method of claim 1 further comprising:

3. and before generating the at least one zero-knowledge proof, padding the copy of the message so that the copy has a length that is a positive integer multiple of the input message size as defined by the hash function used for hashing; If the length of the copy after padding is greater than the input message size defined by the hash function, the method dividing a copy of the message into a plurality of message blocks, each message block having a length corresponding to the input message size as defined by the hash function; identifying one or more message blocks containing sensitive data; Including, The method of claim 1 , wherein a zero-knowledge proof is generated for each of the one or more message blocks that includes secret data.

4. 4. The method of claim 3, wherein for one or more of the at least one zero-knowledge proof, bits of the copy correspond to bits of a message block of the one or more message blocks, and the zero-knowledge proof is generated by hashing the message block to generate an output hash value.

5. 5. The method of claim 4, wherein the plurality of message blocks includes a first message block and one or more further message blocks, and wherein if the first message block contains sensitive data, a public initialization vector is used for hashing the first message block, and if the further message block contains sensitive data, the hashing of the further message block uses an output hash value from hashing a message block immediately preceding the further message block.

6. 4. The method of claim 3, wherein some message blocks of the plurality of message blocks contain secret data, the method comprising generating zero-knowledge proofs for each of the some message blocks in parallel.

7. 4. The method of claim 3, wherein for one of the at least one zero-knowledge proof, bits of the copy correspond to bits of a merged block, the merged block including multiple adjacent message blocks each including secret data, the zero-knowledge proof is generated by iteratively hashing each message block in the merged block, and an output hash value is generated by hashing the last message block of the merged block using an output hash value from hashing a message block of the multiple adjacent message blocks that immediately precedes the last message block.

8. identifying message blocks containing sensitive data as containing a number of sensitive bits less than a predetermined threshold; merging the message block with at least one adjacent message block containing sensitive data to generate a merged block; The method of claim 7 further comprising:

9. The method of claim 8 , wherein the predetermined threshold is defined by the collision resistance of the hash function.

10. 2. The method of claim 1, wherein the secret bit string satisfies the requirement that the bits of the copy are equal to a bitwise XOR of (i) a public bit string and (ii) a result of a bitwise AND of the mask bit string and the secret bit string.

11. The method of claim 1 , wherein obtaining the string of mask bits comprises reading the string of mask bits from a memory.

12. Obtaining the mask bit string locating at least one secret bit within the bits of the copy of the message; generating a mask bit string that identifies the location of the at least one secret bit within the copy; The method of claim 1 , comprising:

13. The method of claim 1 , further comprising the step of outputting the at least one masked bit sequence to the recipient.

14. 2. The method of claim 1 , wherein the outputting step comprises transmitting the modified message, along with the at least one output hash value, the at least one public bit string, and the at least one zero-knowledge proof, to a remote device associated with the recipient.

15. 15. The method of claim 14, wherein the message comprises blockchain transaction data and the modified message comprises modified blockchain transaction data.

16. 16. The method of claim 15, wherein the computing device is a blockchain node in a blockchain network.

17. 17. The method of claim 16, wherein the blockchain transaction data is received from a client device requesting to record a blockchain transaction in a blockchain, the remote device is a further blockchain node in the blockchain network, and the modified blockchain transaction data is sent to the further blockchain node for propagation within the blockchain network.

18. the remote device is a further blockchain node in the blockchain network, and the method comprises: receiving a blockchain transaction; generating a block to be recorded in a blockchain, the block including the modified blockchain transaction data; transmitting the block containing the modified blockchain transaction data to the further blockchain node in the blockchain network; 17. The method of claim 16, comprising:

19. 16. The method of claim 15, wherein the computing device is external to a blockchain network and the remote device is a client device.

20. 20. The method of claim 16 or 19, comprising receiving a block recorded in a blockchain, the block including the blockchain transaction data.

21. 21. The method of claim 20, wherein the generating, deleting, and transmitting steps occur in response to receiving the block.

22. 21. The method of claim 20, wherein the generating and deleting steps occur in response to receiving the block, and the transmitting step occurs in response to receiving a request for the block from the remote device.

23. 21. The method of claim 20, wherein the generating, deleting, and transmitting steps occur in response to receiving a request for the block from the remote device.

24. 2. The method of claim 1, wherein the at least one zero-knowledge proof is a zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) proof.

25. 25. The method of claim 24, wherein generating the zero-knowledge proof further comprises using a proof key.

26. 10. The method of claim 1, further comprising the steps of: deleting the message from memory after generating the modified message; and storing the modified message in memory.

27. A computer program embodied on a computer readable storage device, the computer program comprising instructions configured to perform the method of claim 1 when executed on a computing device.

28. 10. A computing device including a processor and a memory, said memory storing instructions that, when executed by said processor, cause said computing device to perform the method of claim 1.

29. 1. A method for verifying that a modified message is valid, the modified message corresponding to an original message with sensitive data removed, the method being performed on a computing device; obtaining the modified message, the modified message corresponding to the original message with each secret bit assigned a predetermined value; obtaining an output hash value of the modified message and verifying the output hash value using data stored in a memory of the computing device; receiving, from a sending device, at least one zero-knowledge proof associated with bits of the modified message; verifying each of the at least one zero-knowledge proof using: (i) knowledge of a bitwise logic operation used by the sending device to derive the secret bit sequence used to generate the zero-knowledge proof, or a verification key associated therewith; (ii) the bits of the modified message; (iii) a mask bit sequence identifying the location of at least one secret bit within the bits of the modified message; (iv) a hash value or a portion thereof of the bits of the modified message; and (v) an input hash value of the bits of the modified message; A method comprising:

30. 30. The method of claim 29, wherein obtaining the modified message comprises receiving the modified message from the sending device.

31. obtaining the modified message, receiving a version of the original message that includes only the public bit of the original message; generating the modified message using the version of the original message and the mask bit sequence; 30. The method of claim 29, comprising:

32. 30. The method of claim 29, wherein the bits of the modified message correspond to an entire modified message, and the modified message has a length corresponding to an input message size defined by a hash function used to generate an output hash value of the modified message.

33. 30. The method of claim 29, wherein the modified message includes multiple message blocks, the output hash value is a hash of a last message block of the multiple message blocks, and the multiple message blocks have a length corresponding to an input message size defined by a hash function used to generate the output hash value.

34. 34. The method of claim 33, wherein a bit of the modified message corresponds to one of the plurality of message blocks.

35. 30. The method of claim 29, wherein a merged block includes multiple adjacent message blocks containing secret data, and wherein verifying the zero-knowledge proof uses a hash value of a last message block of the merged block.

36. 30. The method of claim 29, wherein the original message is a blockchain transaction, the data stored in the memory of the computing device is a transaction identifier associated with the blockchain transaction, and verifying the output hash value comprises hashing the output hash value and comparing an output of hashing to the transaction identifier.

37. 30. The method of claim 29, wherein multiple zero-knowledge proofs associated with bits of the modified message are received from the sending device, and the step of verifying the multiple zero-knowledge proofs occurs in parallel.

38. 30. A computer program embodied on a computer readable storage device, the computer program comprising instructions configured to perform the method of claim 29 when executed on a computing device.

39. 30. A computing device including a processor and a memory, said memory storing instructions that, when executed by said processor, cause said computing device to perform the method of claim 29.

Images