Method executed by a computing device

Abstract

A method performed by a computing device, the method comprising: transmitting a data distribution control message to a node of a blockchain network, the data distribution control message indicating that data in a transaction of a plurality of transactions stored by the node and associated with a blockchain should not be distributed by the node; receiving a zero knowledge proof from the node, the zero knowledge proof to prove that the data is removed from the transaction according to the data distribution control message; generating a recorded transaction, the recorded transaction comprising evidence regarding removal of the data from the transaction in accordance with the data distribution control message; and transmitting the recorded transaction to the node to be submitted to the block chain.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method performed by a computing device. BACKGROUND

[0002] Blockchain is designed to be immutable, meaning that if data is embedded into the blockchain, it cannot be changed. This property makes it very difficult to remove unwanted data. If any data is removed from a blockchain transaction, the remaining transaction data cannot be verified again. This is because, due to the lack of certain data, the transaction ID cannot be reproduced by taking a double hash of the serialized transaction data. Subsequently, the transaction cannot be proven to be in a block using a Merkle proof, and then the block header can be proven to be in the blockchain using proof of work (PoW). This presents a challenge for node operators or other types of blockchain service providers that can need to distribute unwanted data during maintenance, as this unwanted data can be illegal. SUMMARY

[0003] According to one aspect disclosed herein, there is provided a method performed by a computing device, the method comprising: transmitting, to a node of a blockchain network, a data distribution control message, the data distribution control message indicating that data in a spendable output of a transaction of a plurality of transactions stored by the node and associated with a blockchain should not be distributed by the node; receiving, from the node, a zero knowledge proof for proving that the data was removed from the transaction in accordance with the data distribution control message; generating a record transaction, the record transaction comprising evidence of the removal of the data from the transaction in accordance with the data distribution control message; and transmitting the record transaction to the node for submission to the blockchain.

[0004] According to another aspect disclosed herein, there is provided a computer- readable medium storing processor-executable instructions, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the one or more processors to perform any of the methods described herein. The computer-readable medium can be a non-transitory medium.

[0005] According to another aspect disclosed herein, there is provided a computer program comprising instructions which, when executed by a computing device, cause the computing device to perform any of the methods described herein.

[0006] The instructions can be provided on one or more carriers. For example, there can be one or more non-transitory storage medium (e.g., EEPROM (e.g., flash memory), a magnetic disk, a CD-ROM or DVD-ROM, a read-only memory (e.g., for firmware), one or more data carriers (e.g., a compact disc, a DVD, a Blu-ray disc, a memory stick, a memory card, a hard disk, a tape, a solid state memory device, etc.), one or more transient memory (e.g., RAM) and / or one or more data carriers such as an optical or electrical signal carrier. The one or more memories can be integrated into the corresponding processing chip(s) and / or separate from the chip(s). The code (and / or data) used to implement an embodiment of the present disclosure can include source code in a conventional programming language (interpreted or compiled) such as C, assembly code, machine code, code for setting up or controlling an application specific integrated circuit (ASIC) or field programmable gate array (FPGA), or code for a hardware description language.

[0007] According to another aspect disclosed herein, there is provided a computing device comprising: one or more processors; memory; and computer-executable instructions stored in the memory which, when executed by the one or more processors, cause the processors to perform any of the methods described herein. BRIEF DESCRIPTION OF DRAWINGS

[0008] To assist in understanding embodiments of the present disclosure and to show how they can be implemented in practice, reference will now be made, by way of example only, to the accompanying drawings in which:

[0009] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0010] Figure 2 some examples of transactions that can be recorded in a blockchain are schematically illustrated;

[0011] Figure 3A is a schematic block diagram of a client application;

[0012] Figure 3B is a schematic model of an example user interface that can be represented by Figure 3A the client application of

[0013] Figure 4 is a schematic block diagram of some node software for processing transactions;

[0014] Figure 5 is an example transaction that includes unwanted data in an unspendable output of the transaction;

[0015] Figure 6 is an example transaction that includes unwanted data in an unspendable output of the transaction;

[0016] Figure 7a is a schematic block diagram of a blockchain node;

[0017] Figure 7b is a schematic block diagram of a data distribution control device;

[0018] Figure 8 is a sequence diagram of steps performed according to an embodiment of the present disclosure;

[0019] Figure 9 illustrates a transaction and two example recorded transactions, the transaction including unwanted data in spendable outputs of the transaction. DETAILED DESCRIPTION

[0020] 1. Exemplary System Overview

[0021] A blockchain refers to a distributed data structure, wherein a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter the “blockchain network”), and the copy is widely publically available. The blockchain comprises a chain of blocks, where each block comprises one or more transactions. Each transaction, with the exception of so-called “coinbase transactions”, points back to a previous transaction in a sequence, which can span one or more blocks, back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in a new block. The process of creation of new blocks is commonly referred to as “mining”, and involves each of a plurality of nodes competing to perform “proof-of-work”, i.e. to solve an cryptographic puzzle based on a representation of a defined ordered and valid set of pending transactions waiting to be included in the blockchain. It will be noted that the blockchain can be pruned at some nodes, and publication of blocks can be achieved by publication of block headers only.

[0022] Transactions in the blockchain can be used for one or more of the following purposes: to convey a digital asset (i.e. a quantity of a digital token); to order a set of entries in a virtualised ledger or registry; to receive and process a timestamp entry; and / or to order index pointers by time. Additional functionality on the blockchain can also be implemented with the blockchain. For example, the blockchain protocol can allow additional user data or data indexes to be stored in transactions. There is no pre-specified limit to the maximum data capacity that can be stored in a single transaction, and so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio or video data in the blockchain.

[0023] In an "output-based" model (sometimes referred to as 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 specifying a quantity of a digital asset, which can be derived from the sequence of transactions in progress. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output can also include a locking script, which specifies a future redemption condition for the output. The locking script is a predicate that defines the conditions necessary to verify and transfer the digital token or asset. Each input of a transaction (except for coinbase transactions) includes a pointer (i.e. a reference) to such an output in a previous transaction, and can also include an unlocking script, which is used to unlock the locking script of the output to which it points. Thus, consider a pair of transactions, which will be referred to as a first transaction and a second (or "target") transaction. The first transaction includes at least one output specifying a quantity of a digital asset, and includes a locking script defining one or more conditions to unlock the output. The second (target) transaction includes at least one input comprising a pointer to the output of the first transaction, and an unlocking script to unlock the output of the first transaction.

[0024] In such a model, when the second (target) transaction is sent to the blockchain network for propagation and recording in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to either of these conditions will not propagate the transaction (as a valid transaction, but possibly register the invalid transaction), nor include the transaction in a new block to be recorded in the blockchain.

[0025] Another model of transaction is an account-based model. In this case, each transaction defines a transfer of quantity by reference to an absolute account balance, rather than by reference to a UTXO of a previous transaction in the sequence of past transactions. The current state of all accounts is stored separately by the nodes into the blockchain, and is constantly updated.

[0026] Figure 1 An example system 100 for implementing a blockchain 150 is shown. The system 100 can comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners"), which can be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 can be arranged as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0027] Each blockchain node 104 comprises a computer device of a peer, different nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, special purpose processors, and / or field programmable gate arrays (FPGAs), as well as other devices such as application specific integrated circuits (ASICs). Each node also comprises memory, that is, computer-readable storage in the form of a non-transitory computer-readable medium. The memory can comprise one or more memory units employing one or more memory media, for example, a magnetic medium such as a hard disk; an electronic medium such as a solid state drive (SSD), flash memory, or electrically erasable programmable read only memory (EEPROM); and / or an optical medium such as an optical disc drive.

[0028] The blockchain 150 comprises a series of data blocks 151, with a respective copy of the blockchain 150 being maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As noted above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Rather, the blockchain 150 can be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) for each block 151. Each block 151 in the blockchain comprises one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0029] The blockchain nodes 104 can be configured to forward transactions 152 to other blockchain nodes 104, causing the transactions 152 to propagate throughout the network 106. The blockchain nodes 104 can be configured to create blocks 151 and store respective copies of the same blockchain 150 in their respective memory. The blockchain nodes 104 can also maintain an ordered set (or “pool”) 154 of transactions 152 that are waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a “memory pool”. In this document, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to the ordered set of transactions that a node 104 has accepted as valid, and for which the node 104 is forced not to accept any other transaction that attempts to spend the same output.

[0030] In a given current transaction 152j, the input (or each input) includes a pointer that references an output of a previous transaction 152i in the sequence of transactions, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spent or redeemed does not necessarily imply the transfer of a financial asset, although this is certainly a common application. More generally, spending can be described as consuming the output, or allocating it to one or more outputs in another subsequent transaction. Typically, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although to ensure that the current transaction is valid, the previous transaction 152i will need to exist and be validated, the previous transaction 152i does not have to exist at the time the current transaction 152j is created or even sent to the network 106. Thus, "previous" refers to a predecessor in the logical sequence linked by the pointers, and not necessarily the time of creation or sending in the temporal sequence, and thus does not necessarily exclude the case of out-of-order creation or sending of transactions 152i, 152j (see discussion below regarding orphan transactions). The previous transaction 152i can equally be referred to as a predecessor transaction or a predecessor transaction.

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

[0032] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its respective role and process transactions 152 in accordance with the blockchain node protocol. It will be appreciated that any action attributed herein to a blockchain node 104 can be performed by software running on the processing device of the respective computer device. The node software can be implemented in one or more applications at the application level or at a lower level such as the operating system level or the protocol level, or any combination of these levels.

[0033] Any given blockchain node can be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g., proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, a node can be dedicated to a particular operation. For example, a node 104 can focus on transaction validation and propagation, or it can focus on block mining. In some examples, a blockchain node 104 can perform more than one of these operations in parallel. Any reference to a blockchain node 104 can refer to an entity configured to perform at least one of these operations.

[0034] Each of the parties 103 in the role of consumer users has a computer device 102 that is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 can act as senders and recipients in transactions. Other users can interact with the blockchain 150 without having to act as senders or recipients. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0035] Some or all of the parties 103 can connect as part of a different network, such as a network that overlays the blockchain network 106. Users of the blockchain network (often referred to as “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 roles required of a blockchain node. Instead, each party 103 can interact with the blockchain network 106, thereby utilizing the blockchain 150, by connecting to (i.e., communicating with) a blockchain node 106. For illustrative purposes, two parties 103 and their respective devices 102 are shown: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It should be understood that more such parties 103 and their respective computer devices 102 can exist and participate in the system 100, but are not illustrated for the sake of convenience. Each party 103 can be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to only Alice or Bob, and any reference herein to Alice or Bob can be replaced with “first party” and “second party,” respectively.

[0036] The computer device 102 of each party 103 comprises respective processing apparatus comprising one or more processors, for example one or more CPUs, graphics processing units (GPUs), other accelerator processors, application specific processors and / or FPGAs. The computer device 102 of each party 103 also comprises memory, i.e. computer-readable memory in the form of a non-transitory computer-readable medium. This memory can comprise one or more memory units employing one or more memory media, for example a magnetic medium such as hard disk; an electronic medium such as SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer device 102 of each party 103 stores software, including respective instances of at least one client application 105 arranged to run on the processing apparatus. It will be appreciated that any action attributed herein to a given party 103 can be performed by software running on the processing apparatus of the respective computer device 102. The computer device 102 of each party 103 comprises at least one user terminal, for example a desktop or laptop computer, a tablet computer, a smartphone or a wearable device such as a smartwatch. The computer device 102 of a given party 103 can also comprise one or more other network resources, such as cloud computing resources accessed through the user terminal.

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

[0038] The client application 105 comprises at least a “wallet” function. This has two main functions. One of these functions is to enable the respective party 103 to create, authorise (e.g. sign) and send transactions 152 to one or more bitcoin nodes 104 for propagation in the network of blockchain nodes 104 and hence inclusion in the blockchain 150. The other function is to report to the respective party the amount of digital assets that it currently holds. In an output-based system, this second function comprises collating the amounts defined in the outputs of various transactions 152 belonging to the relevant party that are scattered throughout the blockchain 150.

[0039] Note: While various client functionalities can be described as integrated into a given client application 105, this is not necessarily limiting, and instead, any of the client functionalities described herein can be implemented in a suite of two or more different applications, for example, interfacing via APIs or one application as a plug-in to another application. More generally, the client functionalities can be implemented at the application layer or a lower layer such as an operating system, or any combination of these layers. The following will be described in terms of a client application 105, but it will be understood that this is not limiting.

[0040] The instance of the client application or software 105 on each computer device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This can enable the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for any transactions of which the respective party 103 is a recipient (or indeed inspect transactions of other parties in the blockchain 150, as in embodiments the blockchain 150 is a public facility which provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transactions 152 in accordance with a transaction protocol. As mentioned above, each blockchain node 104 runs software which is configured to validate transactions 152 and forward transactions 152 for propagation in the blockchain network 106 in accordance with a blockchain node protocol. The transaction protocol and the node protocol correspond to each other, a given transaction protocol and a given node protocol together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0041] As part of an account-based transaction model, another type of transaction protocol operated by some blockchain networks can be referred to as an "account-based" protocol. In the account-based case, each transaction does not define the amount of the transfer by reference to the UTXO of a previous transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored separately by the nodes of the network into the blockchain and is constantly updated. In such systems, transactions are ordered using a running transaction record of the account (also referred to as a "position" or "nonce"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field can also be signed in the transaction. For example, if the data field contains the ID of a previous transaction, the data field can point to the previous transaction.

[0042] Some account-based transaction models share some similarities with the output-based transaction model described herein. For example, as noted above, the data fields of an account-based transaction can point to the previous transaction, which is equivalent to the input of an output-based transaction referencing the output point of the previous transaction. Thus, both models support linking between transactions. As another example, an account-based transaction contains a “recipient” field (in which a receiving address of an account is specified) and a “value” field (in which a quantity of a digital asset can be specified). Together, the recipient and value fields are equivalent to the output of an output-based transaction, which can be used to allocate a quantity of a digital asset to a blockchain address. Likewise, an account-based transaction has a “signature” field, which includes a signature of the transaction. The signature is generated using a private key of the sender and confirms that the sender has authorized the transaction. This is equivalent to the input / unlocking script of an output-based transaction, which typically includes a signature of the transaction. When both types of transactions are submitted to their respective blockchain networks, the signature is checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a “smart contract” refers to a transaction that contains a script configured to perform one or more actions (e.g., send or “release” a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) satisfying one or more conditions defined by the script of the smart contract. A smart contract exists as a transaction on the blockchain and can be invoked (or triggered) by a subsequent transaction. Thus, in some examples, a smart contract can be considered equivalent to a locking script of an output-based transaction (which can be triggered by a subsequent transaction) and checks whether the input of the subsequent transaction satisfies one or more conditions defined by the locking script.

[0043] 2. UTXO-based model

[0044] Figure 2 An example transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as “Tx”) is the basic data structure of a blockchain 150 (each block 151 includes one or more transactions 152). The following will be described by reference to an output-based or “UTXO”-based protocol. But this is not limited to all possible embodiments. It should be noted that while the example UTXO-based protocol is described with reference to Bitcoin, it can equally be implemented on other example blockchain networks.

[0045] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 can comprise an unspent transaction output (UTXO) that can serve as a source for an input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO includes a value specifying an amount of digital asset. This represents a set of tokens on the distributed ledger. A UTXO can also contain the transaction ID of the transaction from which it originated, among other information. The transaction data structure can also include a header 201 that can include an indicator of the size of the input field 202 and the output field 203. The header 201 can also include an ID of the transaction. In embodiments, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the nodes 104.

[0046] For example, Alice 103a wishes to create a transaction 152j that transfers an amount of the relevant digital asset to Bob 103b. In this example, Alice's new transaction 152j is labeled "Tx1". This new transaction takes an output 203 of a previous transaction 152i in the sequence that locks an amount of digital asset to Alice and transfers at least some of such amount to Bob. In this example, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are merely arbitrary labels and do not necessarily imply that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can refer to any previous (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice. Figure 2 Figure 2 For example, Alice 103a wishes to create a transaction 152j that transfers an amount of the relevant digital asset to Bob 103b. In this example, Alice's new transaction 152j is labeled "Tx1". This new transaction takes an output 203 of a previous transaction 152i in the sequence that locks an amount of digital asset to Alice and transfers at least some of such amount to Bob. In this example, the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are merely arbitrary labels and do not necessarily imply that Tx0 refers to the first transaction in the blockchain 151 and Tx1 refers to a subsequent transaction in the pool 154. Tx1 can refer to any previous (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0047] The terms "previous" and "subsequent" as used in the context of a sequence of transactions herein refer to the order of transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, and so on). They can equally be replaced by "predecessor" and "successor", "ancestor" and "descendant", or "parent" and "child", and so on. This does not necessarily refer to the order in which they were created, sent to the network 106, or reached any given blockchain node 104. However, a subsequent transaction (a descendant transaction or "child") that points to a previous transaction (an ancestor transaction or "parent") is not valid unless the parent transaction is valid. A child that reaches a blockchain node 104 before its parent is considered orphaned. Depending on the node protocol and / or the behavior of the node, it can be discarded or buffered for a period of time to await the parent.

[0048] One of the one or more outputs 203 of the previous transaction Tx0 comprises a particular UTXO, labeled UTXO0. Each UTXO includes a value specifying an amount of digital asset represented by the UTXO, as well as a locking script that defines a condition that must be satisfied by an unlocking script in an input 202 of a subsequent transaction for the subsequent transaction to be valid, thereby successfully redeeming the UTXO.​

[0049] A locking script (also known as scriptPubKey) is a piece of code written in a domain specific language recognised by the node protocol. A specific example of such a language is known as "Script" (S capitalised), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, for example the requirement for Alice's signature. The locking script appears in the output of the transaction. An unlocking script (also known as scriptSig) is a piece of code written in a domain specific language that provides the information required to satisfy the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0050] So in the illustrated example, the UTXO0 in the output 203 of Tx0 comprises a locking script [Checksig P A ] that requires Alice's signature Sig P A to redeem the UTXO0 (strictly speaking, to make a subsequent transaction attempting to redeem the UTXO0 valid). The [Checksig P A ] contains a representation (i.e. a hash) of the public key P A in Alice's public-private key pair. The input 202 of Tx1 comprises a pointer to Tx1 (for example by its transaction ID (TxID0), which in embodiments is the hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index identifying the UTXO0 in Tx0 to identify it amongst any other possible outputs of Tx0. The input 202 of Tx1 further comprises an unlocking script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying the private key in her key pair to a predetermined piece of data (sometimes referred to in cryptography as a "message"). Alice needs to sign the data (or "message") for which a valid signature is required to be provided by the locking script, the node protocol, or a combination thereof.

[0051] When the new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions can comprise one or more criteria).

[0052] It should be noted that script code is often represented diagrammatically (i.e. using inexact language). For example, a particular function can be represented using an opcode. "OP_..." refers to a particular opcode of the script language. By way of example, OP_RETURN is a script language opcode that, when preceded by OP_FALSE at the start of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby recording the data immutably in the blockchain 150. The data can comprise a file, for example, that needs to be stored in the blockchain.

[0053] Typically, the input of a transaction contains a digital signature corresponding to a public key PA. In embodiments, this is based on ECDSA using the elliptic curve secp256kl. The digital signature signs a particular piece of data. In embodiments, for a given transaction, the signature will sign part of the transaction input as well as some or all of the transaction output. The particular part of the output that is signed depends on a SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects which output is signed (and thus fixed at the time of signing).

[0054] The locking script, sometimes referred to as "scriptPubKey", typically includes the public key of the party to whom the corresponding transaction is locked. The unlocking script, sometimes referred to as "scriptSig", typically provides the corresponding signature. However, more generally, in all applications of the blockchain 150, the condition for UTXO redemption does not necessarily involve verifying a signature. More generally, the script language can be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" can be preferred.

[0055] 3. Client software

[0056] Figure 3A An exemplary implementation of the client application 105 for implementing embodiments of the disclosed solution is shown. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. In accordance with the solution discussed above and as will be discussed in further detail later, the transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data through the side channel 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106.

[0057] The UI layer 402 is configured to present a user interface through the user input / output (I / O) means of the respective user's computer device 102, including outputting information to the respective user 103 through the user output means of the device 102, and receiving back input from the respective user 103 through the user input means of the device 102. For example, the user output means can include one or more display screens (touch or non-touch screens) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output, etc. The user input means can include, for example, an input array of one or more touch screens (the same as or different from those used for output means); one or more cursor-based devices such as a mouse, trackpad or trackball; one or more microphones and speech or voice recognition algorithms for receiving speech 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 or joysticks, etc.

[0058] Note: While various functionalities herein can be described as integrated into the same client application 105, this does not necessarily constitute a limitation, rather they can be implemented in a suite of two or more different applications, e.g. one as a plug-in to another or interfaced via an application programming interface (API). For example, the functionalities of the transaction engine 401 can be implemented in a separate application than the UI layer 402, or the functionalities of a given module such as the transaction engine 401 can be split between more than one application. Also, it is not excluded that some or all of the described functionalities can be implemented at the operating system level. Where reference is made anywhere herein to a single or given application 105 or the like, it is to be understood that this is by way of example only, and more generally the described functionalities can be implemented in any form of software.

[0059] Figure 3B A model of an example of a user interface (UI) 500 is given, which can be presented by the UI layer 402 of the client application 105a on Alice's device 102a. It will be appreciated that a similar UI can be presented by the client 105b on Bob's device 102b or on the device of any other party.

[0060] By way of illustration, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 can include one or more UI elements 501, 502, 502, which are presented as distinct UI elements through the user output means.

[0061] For example, the UI elements can include one or more user-selectable elements 501, which can be different buttons on a screen, different options in a menu, or the like. The user input means are arranged to enable the user 103 (in this case, Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the UI element on the screen, or speaking the name of the desired option. These options enable the user (Alice) to formulate a transaction 152, and send the transaction to one or more nodes 104 for propagation through the blockchain network 106.

[0062] Alternatively or additionally, the UI elements can include one or more data input fields 502, through which the user can input data. These data input fields are presented (e.g. on a screen) by the user output means, and data can be input into the fields by the user input means (e.g. a keyboard or touch screen). Alternatively, data can be received verbally, based on speech recognition, or the like.

[0063] Additionally or alternatively, the UI elements can include one or more information elements 503, which output information to the user. This / these can be presented on a screen or audibly, for example.

[0064] It will be appreciated that the particular manner in which the various UI elements are presented, options are selected, and data is input is not important. The functionality of these UI elements will be discussed in more detail later. It will also be appreciated that the UI 500 shown in Figure 3 is just an illustrative model, and in practice it can include one or more other UI elements, which are not illustrated for the sake of brevity.

[0065] 4. Node software

[0066] Figure 4An example of node software 450 running on each blockchain node 104 of network 106 is shown, in examples of UTXO-based or output-based models. It should be noted that another entity can run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required by node 104. Node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software containing one or more of the following: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). Consensus module 455C may include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may also be separate from consensus module 455C. One or more of these modules may operate in parallel. Node 104 may include additional modules. Protocol engine 401 is typically configured to recognize different fields of transaction 152 and process such fields according to the node protocol. When a field pointing to another previous transaction 152i(Tx) is received... m-1 The input of transaction 152j(Tx) is the output (e.g., UTXO) of the transaction. j When ), the protocol engine 451 identifies Tx j The unlock script is then passed to script engine 452. Protocol engine 451 is also based on Tx. j The pointer in the input is used to identify and retrieve Tx i Tx i It can be published on blockchain 150, in which case the protocol engine can retrieve Tx from the copy of block 151 of blockchain 150 stored at node 104. i Or, Tx i It has not yet been published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from the unpublished ordered transaction set 154 maintained by node 104. i Regardless of the method used, script engine 451 will identify Tx. i The locked script is referenced in the output and passed to the script engine 452.

[0067] Therefore, script engine 452 has Tx i The locking script and from Tx j The corresponding input unlock script. For example, in Figure 2Transactions labelled TxO and Tx1 are shown in the middle, but the same transactions can apply to any transaction pair. As mentioned previously, the script engine 452 runs both scripts together, which will include placing data onto and retrieving data from the stack 453 according to the stack-based scripting language used (e.g. Script).

[0068] By running the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e. does the unlocking script unlock the output that includes the locking script? The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does satisfy one or more criteria specified in the corresponding locking script, then the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0069] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for the transaction to be valid. Typically, one or more further protocol-level conditions must also be satisfied, which are evaluated by the protocol engine 451; for example, the total amount of the digital asset specified in the input of Tx j does not exceed the total amount pointed to in its output, and the pointed-to output of Tx i has not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 as well as the one or more protocol-level conditions, and only when they are all TRUE does the protocol engine validate the transaction Tx j as valid. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on the condition that Tx j is indeed valid, can the decision engine 454 choose to simultaneously control the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions on Tx j . This includes the consensus module 455C adding Tx j to the respective ordered transaction set 154 of the node for incorporation into a block 151, and the propagation module 455P forwarding Tx j to another blockchain node 104 in the network 106. Optionally, in embodiments, the application-level decision engine 454 can apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine can only choose to publish the transaction on the condition that the transaction is valid and that sufficient transaction fees are reserved.

[0070] Also, it should be noted that in this document, the terms "TRUE" and "FALSE" are not necessarily limited to returning results represented in a single binary number (bit) form, although this is indeed one possible implementation. More generally, "TRUE" can refer to any state that indicates a successful or affirmative result, and "FALSE" can refer to any state that indicates an unsuccessful or non-affirmative result. For example, in an account-based model, the combination of an implicitly agreed-upon level of verification of a signature and an additional affirmative output of a smart contract can indicate a result of "TRUE" (the overall result is considered TRUE if both individual results are TRUE).

[0071] 5. Removing unwanted data

[0072] As described above, a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the blockchain network 106, whereby each block 151 in the chain includes one or more transactions 152.

[0073] According to embodiments described herein, a blockchain node 104 receives a data distribution control message that indicates that the blockchain node 104 should not distribute unwanted data of transactions stored by the blockchain node 104. "Unwanted data" is referred to herein as any transaction data identified in a data distribution control message transmitted to the blockchain node 104 by a data distribution control device. For example, the unwanted data can be textual data or image data. The unwanted data can be illegal (e.g., child pornography or instructions for making a bomb), or can infringe copyright.

[0074] A transaction can contain unwanted data at two different types of locations within the transaction.

[0075] In one example, the unwanted data can be present in a spendable output (i.e., an unspent transaction output (UTXO)) of the transaction. In particular, the unwanted data can only be present in a locking script of the transaction, and not in any metadata fields such as a Bitcoin value.

[0076] Figure 5 An example transaction 500 is shown that includes unwanted data present in a spendable output of the transaction 500 (i.e., an unspent transaction output (UTXO)) of the transaction 500. <data>).

[0077] As Figure 5 shown, the unwanted data can be placed after the opcode OP_CHECKSIG and OP_RETURN. In another example, the unwanted data can be placed after the opcode OP_CHECKSIG and OP_PUSH and before the opcode OP_DROP (i.e., <P B >OP_CHECKSIG OP_PUSH <data>OP_DROP). It will be appreciated that other methods can be used by malicious entities to place unwanted data in the locking script of a spendable output of a transaction.

[0078] In this example, the validity of the UTXO must be considered when spending in the future. Any new transaction must reference the UTXO. When validating a new transaction, information about the UTXO is required, such as the Bitcoin value and the locking script. This causes a problem when the UTXO contains unwanted data and is spent by a new transaction. In order to validate the new transaction, the UTXO needs to be validated and therefore the unwanted data is known. If any other node or service provider needs to validate the transaction, they must also be able to access the unwanted data. The unwanted data can exist indefinitely in the UTXO set, as it is not known when the UTXO will be spent. The UTXO set can be made available to the public through a block explorer.

[0079] In an alternative example, the unwanted data can exist in any other part of the transaction (i.e. the unwanted data is not in the spendable output and therefore no longer plays a role in the consensus process). For example, the unwanted data can exist in an unspendable transaction output (typically characterised by an OP_FALSE OP_RETURN script pattern). As shown in Figure 6 This figure shows an example transaction 600 that includes unwanted data in an unspendable transaction output. In this case, the unwanted data is not in the spendable output and therefore no longer plays a role in the consensus process.

[0080] As mentioned above, when OP_FALSE is prepended to the opcode OP_RETURN at the start of the locking script, this creates an unspendable output of the transaction that can be exploited by malicious entities to store unwanted data within the transaction, thereby recording the data immutably in the blockchain 150.

[0081] In this alternative example, the blockchain node 104 can simply reject sharing a part of the transaction that contains the unwanted data. This is known as pruning and is mentioned in the Bitcoin whitepaper as a method for nodes to reclaim disk space. The unwanted data is not needed in the future as it does not affect the validation of any new transactions. The disadvantage of the pruning method is that the integrity of any other fields in the transaction cannot be independently validated.

[0082] In Figure 6 If the unwanted data in the second output is removed, the first output can still be unspent. This is acceptable as removing the data from the second output does not affect the validation of a transaction that spends the first output.

[0083] It will be appreciated that the unwanted data can be present in both spendable and non-spendable outputs of the same transaction.

[0084] Embodiments of the present disclosure relate to a mechanism by which a blockchain node 104 can remove unwanted data from a transaction, whilst allowing the remaining fields to be verified against a given transaction ID, and / or providing on-chain evidence of the removal of data in accordance with a data distribution control message.

[0085] Figure 7a A schematic block diagram of a blockchain node 104 is shown. The blockchain node 104 comprises a processing apparatus 702 comprising one or more processors, for example one or more central processing units (CPUs), accelerator processors, special purpose processors, and / or field programmable gate arrays (FPGAs), as well as other devices such as application specific integrated circuits (ASICs). The blockchain node 104 also comprises a memory 704, i.e. a computer readable memory in the form of a non-transitory computer readable medium. The memory 704 can comprise one or more memory units employing one or more memory media, for example a magnetic medium such as a hard disk; an electronic medium such as a solid state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory 704 can store the node software 450. The memory 704 can store a respective copy of the blockchain 150. The functionality of the processor 702 described herein can be implemented by code (software) stored on a memory (e.g. the memory 704). The code is configured such that, when fetched from the memory and executed on the processor 702, it performs operations in accordance with the embodiments discussed herein. The blockchain node 104 also comprises a communications interface to allow the transfer of data to and from the blockchain node 104.

[0086] Figure 7b A schematic block diagram of the data distribution control device 750 is shown. The data distribution control device 750 comprises a processing apparatus 752 comprising one or more processors, such as one or more central processing units (CPUs), accelerator processors, special purpose processors, and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). The data distribution control device 750 also comprises a memory 754, i.e. a computer readable storage medium in the form of a non-transitory computer readable medium. The memory 754 can comprise one or more memory units employing one or more memory media, such as for example a magnetic medium, such as a hard disk; an electronic medium, such as a solid state drive (SSD), flash memory or EEPROM; and / or an optical medium, such as an optical disc drive. The functionality of the processor 752 described herein can be implemented by code (software) stored on a storage medium (e.g. the memory 754). The code is configured, when executed from the memory and on the processor 752, to perform operations in accordance with the embodiments discussed herein. The data distribution control device 750 also comprises a communication interface to allow transmission of data to / from the blockchain node 104.

[0087] The data distribution control device 750 is coupled to the packet switched network 101. The data distribution control device 750 can be external to the blockchain network 106, but nevertheless able to communicate with the blockchain node 104.

[0088] Reference is now made to Figure 8 The sequence diagram shown describes embodiments of the present disclosure.

[0089] In step S802, the blockchain node 104 receives a data distribution control message indicating that the blockchain node 104 should not distribute data of a transaction (Tx) stored in the memory of the blockchain node 104 to anyone, not even other blockchain nodes. In particular, the data distribution control message specifies the transaction by one or more unique identifiers associated with the transaction, e.g. transaction IDs. The data distribution control message also specifies which data in the transaction is unwanted data by one or more identifiers of the unwanted data stored in the transaction. It will be appreciated that this can be implemented in a number of different ways. For example, the data distribution control message can comprise an identifier of a particular output of the transaction, e.g. an index number, e.g. to indicate that all data in the second output of the transaction is unwanted data. Additionally or alternatively, the data distribution control message can comprise one or more bit identifiers to identify the location of bits corresponding to the unwanted data in the transaction, e.g. to indicate that the data in bit positions 2000-3000 is unwanted data. The data distribution control message is transmitted from the data distribution control device 750 to the blockchain node 104.

[0090] In response to receiving the data distribution control message, in step S804 the blockchain node 104 is configured to obtain a zero-knowledge proof (ZKP) for proving removal of unwanted data from the transaction.

[0091] In some implementations, the blockchain node 104 can obtain the ZKP by generating the ZKP itself. The ZKP can be generated using: (i) the transaction referenced in the data distribution control message; (ii) the one or more identifiers of the unwanted data stored in the transaction, which are included in the data distribution control message; and (iii) a public parameter.

[0092] In other implementations, the blockchain node 104 does not perform the generation of the ZKP itself. Instead, the blockchain node 104 can receive the ZKP from a remote computing device.

[0093] In response to the blockchain node 104 transmitting to the remote computing device: (i) the transaction referenced in the data distribution control message, and (ii) the one or more identifiers of the unwanted data stored in the transaction, the blockchain node 104 can receive the ZKP from the remote computing device. In these examples, the remote computing device can be external to the blockchain network 106. That is, the remote computing device can not be a blockchain node 104. Alternatively, the remote computing device can be another blockchain node 104.

[0094] Although Figure 8 For simplicity, a single blockchain node 104 is shown, but the data distribution control device 750 can transmit the data distribution control message to multiple blockchain nodes 104 in the blockchain network 106. Thus, Figure 8 The illustrated blockchain node 104 can receive the ZKP from another blockchain node that also received the data distribution control message and generated the ZKP in response to receiving the data distribution control message. It will be appreciated that, in these examples, Figure 8 The illustrated blockchain node 104 does not necessarily transmit to the ZKP- generating blockchain node: (i) the transaction referenced in the data distribution control message, and (ii) the one or more identifiers of the unwanted data stored in the transaction.

[0095] It will be apparent that the ZKP can be constructed by a blockchain node, a blockchain service provider, or any other entity that has access to the unwanted data. A blockchain service provider is referred to herein as an entity that provides blockchain data but does not produce blocks. For example, a blockchain service provider can be an entity that provides a block explorer, such as WhatsOnChain, that provides blockchain data upon request. In another example, a blockchain service provider can be an entity that provides a platform that receives data from a user, puts the data into a transaction, pays a fee, sends the transaction to a blockchain network, and provides the user with a proof of inclusion of the data on the blockchain.

[0096] A zero-knowledge proof (ZKP) is a method by which a party, referred to as the prover, can prove to another party, referred to as the verifier, that a certain statement is true without revealing any information other than that the statement is true. In embodiments of the present disclosure, a ZKP is generated to prove that the unwanted data specified in a data distribution control message has been removed from a particular transaction (also specified in the data distribution control message). That is, the term "zero-knowledge proof" as used herein refers to a proof of knowledge between a prover and a verifier that can prove that no information about the unwanted data has been revealed.

[0097] Embodiments of the present disclosure are not limited to any particular type of ZKP. The ZKP obtained in step S804 can be an interactive zero-knowledge proof (requiring interaction between the prover and the verifier). Alternatively, the ZKP obtained in step S804 can be a non-interactive zero-knowledge (NIZK) proof, in which the prover only produces a message called a "proof" for the verifier to believe that the statement is true (i.e., that the unwanted data has been removed from the transaction).

[0098] A zero-knowledge succinct non-interactive argument of knowledge (zkSNARK) is an example of a succinct NIZK proof that is very short and easy to verify. The statement is expressed in terms of an arithmetic circuit used to generate the proof of the statement.

[0099] In the example where the ZKP is a zkSNARK proof, the public parameters correspond to the proving key (which is part of a proving and verification key pair computed at the setup phase).

[0100] As will be known to those skilled in the art, the proving and verification keys work in the context of a zkSNARK, but not for other types of zero-knowledge proofs, such as MPC-based proofs (e.g., zkBOO), STARKs, or Bulletproofs. However, all types of zero-knowledge proofs use some public parameters to generate the proof, and the form that the public parameters take depends on the type of zero-knowledge proof that is employed.

[0101] In response to receiving the data distribution control message, in step S806 the blockchain node 104 is configured to remove the unwanted data from the transaction (Tx) in accordance with the data distribution control message to generate a modified transaction (Tx’). The modified transaction (Tx’) corresponds to the original transaction (Tx) without the unwanted data. It will be appreciated that, in order to generate the ZKP, the unwanted data needs to be known. The transaction ID of the transaction (Tx) is not modified. That is, the transaction ID of the transaction (Tx) is the same as the modified transaction (Tx’). The ZKP is used to associate the incomplete transaction data in the modified transaction (Tx’) with the transaction ID. In particular, the ZKP contains the transaction ID as a fixed public parameter, so the transaction ID can be considered as data explicitly included as part of the ZKP. When a verifier verifies the ZKP, the verification process takes the ZKP and the modified transaction (Tx’) as inputs (and the verification key in the context of a zkSNARK), and outputs a “TRUE” or “FALSE” decision (e.g. a bit 1 or 0). The output will be “TRUE” if the correct redacted transaction for a given TxID is given as input to the ZKP.

[0102] The ZKP proves that only the unwanted data has been removed from the transaction, and that the blockchain node has not removed or tampered with the transaction in any other way. In particular, the ZKP proves that the unwanted data has been “completely removed” from the given transaction, i.e. if the transaction includes data {X || Y}, and Y is completely removed, then the remainder is {X ||.}. This means that X has not been tampered with. If Y has not been completely removed, then the remainder can be {Z ||.}, which is inconsistent with the starting data.

[0103] Importantly, the data associated with the Bitcoin value and public key is not removed from the transaction, as it can help to identify who uploaded the unwanted data and which Bitcoin has been used for that purpose. This can also help to recover the Bitcoin in a transparent manner.

[0104] This is particularly true when the unwanted data is present in a UTXO and many different entities can be interested in that data. For example, the sender or recipient of a transaction that spends the UTXO containing the data, and any node or blockchain service provider that participates in processing that transaction. Any of these entities can wish to prove to another entity that they have complied with the data distribution control message. The blockchain node or blockchain service provider can wish to prove that they have deleted a particular part of the transaction, even if that particular part is not in the UTXO.

[0105] In some implementations, after the unwanted data is removed from the transaction, the blockchain node 104 still retains the unwanted data in the memory 704. In other implementations, after the unwanted data is removed from the transaction, the blockchain node 104 does not retain the unwanted data in the memory 704.

[0106] In step S808, the blockchain node 104 is configured to transmit the ZKP to the data distribution control device 750. The ZKP provides evidence to the data distribution control device 750 that the blockchain node 104 has complied with the data distribution control message. The data distribution control device 750 receives the ZKP transmitted from the blockchain node 104.

[0107] By verifying the ZKP, the data distribution control device 750 can explicitly check whether the proof relates to the correct part of the transaction identified in the data distribution control message. Techniques for verifying ZKPs, which provide an “valid” or “invalid” output, are known to those skilled in the art and are not discussed in detail herein. As an example only, if the ZKP is a zkSNARK, the data distribution control device 750 (or any other verifier) needs: the verification key (corresponding to the proof key described above), all the data of the transaction (save for the unwanted data itself) except for the unwanted data itself, and the ZKP.

[0108] In step S810, the blockchain node 104 can receive a request for the transaction (Tx) identified in the data distribution control message. The request is transmitted from the requesting computing device 800. For example, the requesting computing device 800 can be a user’s computer device 102. Alternatively, the requesting computing device 800 can be a blockchain node 104, for example, when a new miner enters the blockchain network, they have to download the entire blockchain and verify each transaction to build the UTXO set. The request received in step S810 can be transmitted from the requesting computing device 800 as part of the process of downloading the entire blockchain and verifying each transaction to build the UTXO set.

[0109] In response to the request received in step S810, in step S812 the blockchain node 104 transmits the modified transaction (Tx’) and a ZKP to the requesting computing device 800. The modified transaction (Tx’) does not include the unwanted data, so the transmission in step S812 complies with the data distribution control message. The ZKP used in embodiments of the present disclosure proves that the redacted transaction data in the modified transaction (Tx’) is correct for the given transaction ID. In particular, the ZKP transmitted in step S812 proves to the requesting computing device 800 that the redacted transaction data in the modified transaction (Tx’) is correct for the transaction ID of the modified transaction (Tx’). The ZKP allows the non-unwanted data (the remaining data in the modified transaction after step S806) to be verified, thereby providing transparency and auditability. This is particularly useful when the unwanted data is in a UTXO, as there can be many parties affected by the data distribution control message.

[0110] In step S812, the blockchain node 104 can additionally transmit a data distribution control message to the requesting computing device 800.

[0111] Once the blockchain node 104 has obtained the ZKP in step S804, the blockchain node 104 can transmit the ZKP to one or more other blockchain nodes 104 in the blockchain network 106. As the ZKP does not require any trust in the creator of the ZKP, once created it can be reused by any other device, such as the other node blockchain nodes 104 in the blockchain network 106. This advantageously minimises processing overhead in the blockchain network, as each blockchain node 104 in the blockchain network 106 does not need to generate a ZKP which can be computationally expensive.

[0112] While the above mentions a simple example in which the data distribution control message identifies a single transaction storing the unwanted data, it will be appreciated that the data distribution control message can determine that the blockchain node 104 should not distribute the unwanted data stored in multiple transactions in the memory of the blockchain node 104. In these examples, the blockchain node 104 performs steps S804, S806 and S808 for each transaction identified in the data distribution control message. That is, a ZKP is obtained for each transaction stored by the blockchain node 104 which includes the unwanted data and is identified in the data distribution control message. Each ZKP is constructed for a particular transaction ID (TxID) which is recorded as explicit data as part of the respective ZKP.

[0113] In response to receiving a ZKP in step S808, if unwanted data exists in the expendable output of a transaction, the data distribution control device 750 can be configured to generate a record transaction in step S814 to provide evidence of data removal from the transaction according to the data distribution control message.

[0114] The evidence may include a ZKP or a commitment to a ZKP. For example, a commitment to a ZKP may be a hash of a ZKP or a Pedersen commitment. Additionally or alternatively, the evidence may include a data distribution control message or a commitment to a data distribution control message. For example, a commitment to a data distribution control message may be a hash of a data distribution control message or a Pedersen commitment. The evidence may also include metadata associated with the removal of data from the transaction. Examples of commitments that may be used in embodiments of this disclosure, such as hashes or Pedersen commitments, are referenced herein. It should be understood that these are examples, and evidence regarding the removal of data may include other types of commitments.

[0115] At least a portion of this evidence may be stored in the input of the record transaction. Specifically, one or more of the following may be stored in the input of the record transaction: (i) a ZKP or a commitment to a ZKP; (ii) a data distribution control message or a commitment to a data distribution control message; and (iii) metadata.

[0116] Figure 9 An example of recording transaction 900 is shown, where both ZKP and data distribution control messages are provided at transaction ID TXID. m The input of transaction 950 is recorded.

[0117] The input to the exemplary record transaction 900, identified by index 0, includes a pointer to transaction 500 (e.g., via its transaction ID (TxID)). n (This is, in this embodiment, the hash of the entire transaction 500). The input to the exemplary record transaction 900 also includes an index identifying the UTXO0 in transaction 500 (which stores unwanted data before removal) to identify that UTXO0 in any other possible output of transaction 500. (As...) Figure 9 As shown, the input to the exemplary record transaction 900 identified by index 0 also includes both the ZKP in the unlock script and the data distribution control message (which implicitly links the evidence of removing unwanted data from transaction 500 to the UTXO0 of transaction 500, which stores the unwanted data before removal). These can be pushed from the stack and then discarded (i.e., OP_PUSH). <zkp>OP_DROP) is included in the unlocking script and thus does not affect execution of the script.

[0118] While the example record transaction 900 shows both the ZKP and the data distribution control message in the unlocking script, when they are both present, they are not required to be co-located in the record transaction 900, and as noted above, the record transaction 900 can not include both the ZKP and the data distribution control message at the same time.

[0119] At least a portion of the evidence can be stored in an output of the record transaction. That is, one or more of: (i) the ZKP or a commitment to the ZKP; (ii) the data distribution control message or a commitment to the data distribution control message; and (iii) the metadata; can be stored in an output of the record transaction. The output storing the portion of the evidence can be a spendable output or an unspendable output.

[0120] Figure 9 An example record transaction 950 is shown in which both the ZKP and the data distribution control message are provided in an unspendable output of the record transaction 950 with transaction ID TXID m .

[0121] The example record transaction 950 input identified by index 0 includes a pointer to transaction 500 (e.g., by its transaction ID (TxID n ), which in embodiments is the hash of the entire transaction 500). The example record transaction 950 input also includes an index identifying UTXO0 in transaction 500 (which prior to removal stored the unwanted data) to identify that UTXO0 in any other possible outputs of transaction 500.

[0122] As shown in Figure 9 , the record transaction 950 includes both the ZKP and the data distribution control message in the locking script of the unspendable output. However, as noted above, at least a portion of the evidence can be stored in a spendable output of the record transaction (e.g., <P C > OP CHECKSIG OP_RETURN <zkp> <ddcm>).

[0123] When the evidence about removing unwanted data from transaction 500 (e.g., the ZKP and / or the data distribution control message) is provided in the output of the record transaction 950, the record transaction 950 links that evidence to the particular UTXO that stored the unwanted data before it was removed (e.g., UTXOo of transaction 500).

[0124] One way to provide this link is to include the transaction ID (TxIDn) and the output index number of transaction 500 in the output of the record transaction 950 (e.g., in the OP_RETURN data), the combination of TxIDn and the output index number thereby specifying the UTXO that stored the unwanted data before it was removed. Figure 9 In the example of FIG. 9, the output index number (index number 0) is used to identify UTXOo in transaction 500 (which stored the unwanted data before it was removed).

[0125] When the ZKP is provided in the output of the record transaction 950, the ZKP will explicitly reference the transaction ID (TxIDn) of transaction 500, as the ZKP is generated from transaction 500. Specifically, the ZKP includes TxIDn as a fixed public parameter (and thus TxIDn can be considered to be included as part of the ZKP). In these examples, TxIDn does not need to be explicitly specified in the output of the record transaction 950 (e.g., in the OP_RETURN data) in addition to the ZKP. In these examples, the output index number can also be provided in the output of the record transaction 950 (e.g., in the OP_RETURN data), the combination of TxIDn and the output index number thereby specifying the UTXO. Figure 9 In the example of FIG. 9, the output index number is used to identify UTXOo in transaction 500 (which stored the unwanted data before it was removed).

[0126] When the data distribution control message is provided in the output of the record transaction 950, the data distribution control message can specify the particular UTXO that stored the unwanted data to be pruned, thereby providing this link.

[0127] While the example record transaction 950 shows both the ZKP and the data distribution control message in the locking script, when they are both present, they are not required to be co-located in the record transaction 950, and as noted above, the record transaction 900 can not include both the ZKP and the data distribution control message at the same time.

[0128] The above metadata can include one or any combination of: (i) a version number associated with the code (software) stored in memory 754 that, when fetched for execution on processor 752, performs operations in accordance with embodiments discussed herein; (ii) a type / scheme of zero-knowledge proof associated with the ZKP received in step S808; (iii) data indicating that the ZKP or commitment to the ZKP is included in the record transaction; (iv) an identifier of the location in the record transaction of the ZKP or commitment to the ZKP; (v) data indicating that the data distribution control message or commitment to the data distribution control message is included in the record transaction; (vi) an identifier of the location in the record transaction of the data distribution control message or commitment to the data distribution control message; a date and / or time at which the record transaction is generated.

[0129] In the illustrated example, UTXOo in the output of transaction 500 includes a locking script that requires Bob’s signature P B to redeem UTXOo (strictly speaking, to make a subsequent transaction attempting to redeem UTXOo valid).

[0130] The input to record transaction 900, 950 will typically include an unlocking script that includes an encrypted signature by Bob, created by Bob applying his private key to a predefined portion of data (sometimes referred to in cryptography as a “message”). The data (or “message”) that needs to be signed by Bob to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof. The message includes UTXOo in the output of transaction 500, i.e., includes the unneeded data. In one example, the message includes UTXOo of transaction 500 (e.g., the value assigned to the first output and the first locking script of the first output) and all of the contents of record transaction 900, 950, except for all of the unlocking scripts of the record transaction.

[0131] In some embodiments of the present disclosure, record transaction 900, 950 does not include a signature that is predicated on the UTXO locking script of transaction 500. Specifically, record transaction 900, 950 does not include a signature of a message that includes the spendable output of transaction 500, which includes the unneeded data. Thus, a party does not need to know the unneeded data in transaction 500 to verify record transaction 900, 950.

[0132] If the spendable output of transaction 500 that includes the unneeded data assigns a value of a digital asset to an entity, the record transaction can include a spendable output that reassigns the value of the digital asset to a different entity. As Figure 9 In the illustrated example, the data distribution control message 902 identifies a single transaction 904 that stores the unwanted data. The data distribution control message 902 also includes a zero-knowledge proof (ZKP) 906 that provides evidence that the data can be removed from the transaction 904. The ZKP 906 is generated by the data distribution control device 750 in step S814. The ZKP 906 is included in the record transaction 950 to provide on-chain evidence that the data can be removed from the transaction 904 in accordance with the data distribution control message 902.

[0133] Once the record transaction is generated in step S814, in step S816 the data distribution control device 750 transmits the record transaction to the blockchain node 104 for submission to the blockchain.

[0134] Although Figure 8 The sequence diagram of FIG. 9 illustrates steps being performed in a particular order, but embodiments of the present disclosure are not limited to Figure 8 The steps of FIG. 9 are performed in this particular order. For example, step S814 can be performed before step S810, and steps S814 and S816 can be performed before steps S810 and S812.

[0135] Although the above refers to a simple example in which the data distribution control message identifies a single transaction that stores the unwanted data, the data distribution control device 750 receives a single ZKP, and the data distribution control device 750 generates a single record transaction, this is merely an example. In embodiments, the data distribution control message thereby identifies multiple transactions that store the unwanted data, and the data distribution control device 750 receives multiple ZKPs, one or more record transactions can be generated in step S814 to provide evidence that the data was removed from the transactions in accordance with the data distribution control message. For example, a single record transaction can be generated (e.g., referencing the multiple ZKPs) to provide evidence that the data was removed from the multiple transactions in accordance with the data distribution control message. In another example, multiple record transactions can be generated in step S814, each of the multiple record transactions providing evidence that the data was removed from a respective transaction of the multiple transactions in accordance with the data distribution control message.

[0136] Although steps S814 and S816 are described as being performed by the data distribution control device 750, S814 and S816 can also be performed by the blockchain node 104. Specifically, once the blockchain node 104 generates the record transaction in S814, it can add the record transaction to its mempool and transmit the record transaction to one or more other blockchain nodes 104 in the blockchain network 106.

[0137] The record transaction (e.g., including the ZKP) is then included in the blockchain to provide on-chain evidence that the data was removed from the transaction in accordance with the data distribution control message. Thus, in embodiments of the present disclosure, the unwanted data can be removed from the transaction, but the evidence trail always exists (this is the immutability of the blockchain). The ZKP can provide more detail as to which data bits were removed.

[0138] The advantage of using ZKP is that it provides an independent mathematical proof of the statement. In embodiments of the present disclosure, the ZKP ensures that it can be proven that the data segment has been removed without having to trust the blockchain node or the service provider.

[0139] In one example, the data distribution control message can indicate that there is an illegal data segment in the first output of a transaction Tx. Assume that this first output is spendable and has not been spent (UTXO). According to embodiments of the present disclosure, the data distribution control message alerts the blockchain nodes of the illegal data segment. One of the blockchain nodes removes the data and creates a ZKP to prove that they have removed the data. They share the ZKP with the data distribution control device and other blockchain nodes. Since the ZKP allows the verification of other fields in the transaction, the blockchain nodes can prove that the illegal data was uploaded using a signature related to the public key P. Later, the individual can be identified using the public key P. The ZKP can be used to prove that their public key is associated with the illegal data and that the individual can be prosecuted.

[0140] In another example, the data distribution control device issues a data distribution control message that declares that there is illegal data in an unspendable output of a transaction that appears many blocks deep in the blockchain. The blockchain nodes comply with the data distribution control message by creating a ZKP to prove that the illegal data or the entire unspendable output has been removed from the pruned transaction and prune the output containing the illegal data. The blockchain nodes store the ZKP in their own internal log file in memory and / or on the blockchain as a proof of pruning. The blockchain nodes no longer distribute the output containing the illegal data, but if any other device requests a transaction that does not include the output, the blockchain nodes can share the transaction with them along with the ZKP.

[0141] Further comments

[0142] Other variations or uses of the disclosed technology can become apparent from the disclosure provided herein. The scope of the disclosure is not limited to the embodiments described, but only to the claims that follow.

[0143] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, Bitcoin blockchain 150 and Bitcoin nodes 104. However, it will be appreciated that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description can generally apply to any blockchain. That is, the present application is in no way limited to the Bitcoin blockchain. More generally, any reference above to the Bitcoin network 106, Bitcoin blockchain 150 and Bitcoin nodes 104 can be replaced by reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain node can share some or all of the features of the Bitcoin blockchain 150, Bitcoin network 106 and Bitcoin nodes 104 as described above.

[0144] In preferred embodiments of the application, the blockchain network 106 is a Bitcoin network, and the Bitcoin nodes 104 perform at least all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there can be other network entities (or network elements) that perform only one or some but not all of these functions. That is, a network entity can perform the function of propagating and / or storing blocks, without creating and publishing blocks (remember that such entities are not considered to be nodes of the preferred Bitcoin network 106).

[0145] In other embodiments of the application, the blockchain network 106 can not be a Bitcoin network. In these embodiments, it is not excluded that nodes can perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "node" can be used to refer to a network entity that is configured to create and publish blocks 151, but does not store and / or propagate these blocks 151 to other nodes.

[0146] Even more generally, any reference above to the term "Bitcoin node" 104 can be replaced by the term "network entity" or "network element", where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functionality of such a network entity / element can be implemented in hardware, in the same way as described above with reference to the blockchain node 104.

[0147] Some embodiments have been described in terms of a blockchain network for implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is merely one type of consensus mechanism, and any suitable type of consensus mechanism can be used in general embodiments, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-past-time. As one particular example, proof-of-stake uses a randomization process to determine which blockchain node 104 has the opportunity to produce the next block 151. The selected node is often referred to as a validator. A blockchain node can lock up its tokens for a period of time in order to have the opportunity to be a validator. Generally, the node that locks up the most stake for the longest time is the most likely to be the next validator.

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

[0149] According to one aspect disclosed herein, there is provided a method performed by a computing device, the method comprising: transmitting, to a node of a blockchain network, a data distribution control message, the data distribution control message indicating that data in a transaction of a plurality of transactions (stored by the node and associated with a blockchain) should not be distributed by the node; receiving, from the node, a zero-knowledge proof for proving that the data was removed from the transaction in accordance with the data distribution control message; generating a record transaction, the record transaction comprising evidence of the removal of the data from the transaction in accordance with the data distribution control message; and transmitting the record transaction to the node for committal to the blockchain.

[0150] The data distribution control message can indicate that it is the data in a spendable output of the transaction that should not be distributed.

[0151] The evidence can comprise the zero-knowledge proof, or a commitment to the zero-knowledge proof.

[0152] The evidence can comprise the data distribution control message, or a commitment to the data distribution control message.

[0153] At least a portion of the evidence can be stored in an output of the record transaction.

[0154] The output can be a spendable output of the record transaction. Alternatively, the output can be an unspendable output of the record transaction.

[0155] At least a portion of the evidence can be stored in an input of the record transaction.

[0156] The record transaction can include metadata associated with removing the data from the transaction.

[0157] The record transaction can not include a signature of data that includes the spendable output of the transaction.

[0158] The spendable output of the transaction can assign a value of a digital asset to an entity, and the record transaction can include a spendable output that reassigns the value of the digital asset to a different entity.

[0159] The data distribution control message can indicate that the node should not distribute data in multiple transactions of a plurality of transactions.

[0160] The method can include receiving, from the node, a plurality of zero-knowledge proofs, each of the plurality of zero-knowledge proofs proving removal of the data from a respective transaction of the multiple transactions in accordance with the data distribution control message; generating one or more record transactions to provide evidence of removal of the data from the multiple transactions in accordance with the data distribution control message; and transmitting the one or more record transactions to the node for submission to the blockchain.

[0161] The computing device can be external to the blockchain network.

[0162] The zero-knowledge proof can be a Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zkSNARK) proof.

[0163] According to another aspect disclosed herein, there is provided a computer- readable medium storing processor-executable instructions, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the one or more processors to perform any of the methods described herein. The computer-readable medium can be a non-transitory medium.

[0164] According to another aspect disclosed herein, there is provided a computing device comprising: one or more processors; a memory; and computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processors to perform any of the methods described herein.< / ddcm> < / zkp> < / zkp> < / data> < / data>

Claims

1. A method executed by a computing device, the method comprising: Transmit a data distribution control message to a node in the blockchain network, the data distribution control message indicating that data in one of a plurality of transactions stored by the node and associated with the blockchain should not be distributed by the node; Receive a zero-knowledge proof from the node, the zero-knowledge proof being used to prove that the data was removed from the transaction according to the data distribution control message; Generate a recording transaction, the recording transaction including evidence regarding the removal of the data from the transaction according to the data distribution control message; as well as The recorded transaction is transmitted to the node for submission to the blockchain.

2. The method of claim 1, wherein the evidence includes the zero-knowledge proof.

3. The method of claim 1, wherein the evidence comprises a commitment to the zero-knowledge proof.

4. The method according to any one of the preceding claims, wherein the evidence includes the data distribution control message.

5. The method according to any one of claims 1 to 3, wherein the evidence comprises a commitment to the data distribution control message.

6. The method according to any one of the preceding claims, wherein at least a portion of the evidence is stored in the output of the recorded transaction.

7. The method of claim 6, wherein the output is a spendable output of the recorded transaction.

8. The method of claim 6, wherein the output is an unspendable output of the recorded transaction.

9. The method according to any one of the preceding claims, wherein at least a portion of the evidence is stored in the input of the recorded transaction.

10. The method according to any of the preceding claims, wherein the recording transaction includes metadata associated with removing the data from the transaction.

11. The method according to any of the preceding claims, wherein the record transaction does not include a signature of the data containing the spendable output of the transaction.

12. The method according to any of the preceding claims, wherein the spendable output of the transaction assigns the value of the digital asset to an entity, and the recording transaction includes a spendable output that redistributes the value of the digital asset to a different entity.

13. The method according to any one of the preceding claims, wherein the data distribution control message indicates that data in a plurality of transactions among the plurality of transactions should not be distributed by the node.

14. The method of claim 13, wherein the method comprises: Receive multiple zero-knowledge proofs from the node, each of the multiple zero-knowledge proofs proving that the data is removed from the corresponding transaction in the plurality of transactions according to the data distribution control message; One or more record transactions are generated to provide evidence regarding the removal of the data from the plurality of transactions according to the data distribution control message; as well as The one or more recorded transactions are transmitted to the node for submission to the blockchain.

15. The method according to any one of the preceding claims, wherein the computing device is located outside the blockchain network.

16. The method according to any one of the preceding claims, wherein the zero-knowledge proof is a zero-knowledge concise non-interactive knowledge proof (zkSNARK) proof.

17. The method according to any one of the preceding claims, wherein the zero-knowledge proof is used to prove that only the indicated data has been removed from the transaction, and the node has not removed or modified any other data in the transaction.

18. A computer-readable medium storing processor-executable instructions, the processor-executable instructions including instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of the preceding claims.

19. A computing device, the computing device comprising: One or more processors; Memory; Computer-executable instructions stored in the memory, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 17.

Images