Computer-implemented methods and systems

Abstract

Embodiments provide computer-implemented methods and systems for filtering, censoring, redacting, obfuscating or selectively pruning prohibited data in a blockchain transaction or part of a blockchain transaction. The blockchain transaction or the part of the blockchain transaction includes a Zero Knowledge Proof (ZKP) or a flag for a ZKP that replaces a portion of prohibited data such that it cannot be accessed (eg viewed or downloaded) in its original form from the transaction or the part thereof. The prior existence of the prohibited data in the transaction or part thereof can be verified by the ZKP, but sharing of the transaction or part thereof containing the ZKP or its flag will not distribute the prohibited data itself. In an advantageous embodiment, this enables nodes on a blockchain network to comply with policies or requirements e.g. company policies, contracts, licenses, court orders etc. that have the authority to restrict dissemination of the prohibited content while still allowing transmission, spending or otherwise processing of the blockchain transaction or part thereof.

Description

[0001] COMPUTER-IMPLEMENTED METHODS AND SYSTEMS

[0002] TECHNICAL FIELD

[0003] Embodiments herein relate to improvements in controlling access to data that is stored, processed and / or transmitted via a computing network. Embodiments are particularly suited for controlling access to data stored in association with a blockchain, for example data that is stored in and / or referred to from blockchain transactions, and data that is shared or otherwise processed by nodes the implement and / or interact with a blockchain network. Advantageously, embodiments provide technical solutions for removing, filtering, redacting or otherwise controlling data that is designated as prohibited by at least one authority and shared via a blockchain network.

[0004] BACKGROUND

[0005] Blockchain transactions are able to store and share data beyond just digital assets (e.g. cryptocurrency). For example, blockchain transactions can include data relating to tokenisation schemes, Non-Fungible Tokens (NFTs), smart contracts, supply chain management and provenance systems, and much more. As the number of blockchain- implemented applications grows, more and more data, of different types and relating to different purposes, is being inserted into transactions that are then written to a blockchain ledger.

[0006] Undoubtedly, there are many benefits to writing data to the blockchain. These include the provision of an immutable, time-stamped and cryptographically secured audit trail of the data's history. Some blockchain protocols also enable public viewing of the data that is written to the ledger, while others are private or permissioned.

[0007] Despite these benefits, in some situations it may be desirable to prune or omit data that has been provided in a blockchain transaction, as acknowledged in "Erasing Data from Blockchain Nodes” (arXiv:1904.08901vl, 18 Apr 2019) by Florian et al. For example, illegal data or data which violates rights may have been written to the blockchain. A court order may prevent the publication of a document or part of a document to protect the identity of one or more individuals, but the data has been included in a transaction. In other examples, a contractual obligation such as a licence agreement or confidentiality clause may prohibit disclosure of a document's content or part thereof. In yet other examples, a copyright may apply to an aesthetic work, or certain content may contravene an organisation's policies e.g. a historical document may be of public interest but contain portions of material that are deemed offensive or even possibly illegal under current social, legal or regulatory standards. There are, of course, many possible circumstances and motivations under which a data controller or other party may wish to restrict sharing of certain types or instances of data via the blockchain.

[0008] In respect of the Bitcoin blockchain, one option is for the nodes on the network to prune such a transaction. This is a simple process defined in Satoshi Nakamoto's white paper: "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008). However, this only applies if the transaction output containing the data has been spent. If the output has not yet been spent, and the controller will not or cannot spend it (e.g. because they have lost the necessary cryptographic keys to sign and spend the output) the simple transaction prune is not possible.

[0009] Therefore, improved solutions are needed for pruning selected portions of data from blockchain transactions. Embodiments of the present disclosure address at least this technical problem.

[0010] SUMMARY

[0011] It is known that different types of data can be stored in blockchain transactions that are then written to a blockchain. Images, files, multimedia content, video, audio, text etc can all be inserted into transactions that are then included in blocks, verified by the full nodes on the network and then stored on-chain. How the data is inserted in the transaction may depend upon the protocol and particular application concerned, but typically involves inclusion of the data (or a reference to where it can be accessed) in a transaction output. For example, data can be inserted into an output after an OP_RETURN instruction in the script of a Bitcoin transaction output, or disguised as part of cryptographic key or other script component e.g. as disclosed in W02017 / 145004. Other data insertion techniques are known and fall within the scope of the disclosure. Sometimes this data is referred to as 'metadata' because it is included in the transaction for some application-oriented purpose rather than for compliance with the blockchain protocol that the transaction has been formed in accordance with. However, sometimes metadata may comprise illegal or otherwise undesirable content. For example, it may violate rights such intellectual property or human rights, or may contravene a policy, law, rule or other requirement specified by a particular authority. That authority may be a legally-oriented authority, an organisation such as a company, an individual such as an employer, a piece of statutory or common law etc. Sometimes, data may be incorporated into a blockchain transaction that is sent to the network for verification and mining, but then its prohibition only comes to light at a later date. Therefore, the transaction containing the undesirable content may be propagated by nodes on the network, or an (unspent) output that it is provided in may be in a mem pool.

[0012] Embodiments disclosed herein provide methods and systems for controlling, preventing sharing of, restricting access to or selectively removing (pruning) data from a blockchain transaction, or a part of a blockchain transaction e.g. a script, an output etc. Additionally, or alternatively, such methods and systems may be described as providing a recovery solution for removal or restriction of, or selective pruning of, (meta)data provided in a blockchain transaction and / or a part of a blockchain transaction.

[0013] In an illustrative embodiment, a transaction comprising a proof (such as, for example) a zero knowledge proof (ZKP) that replaces the prohibited data can be provided to one or more nodes in the (blockchain) network. In some embodiments, the transaction or part thereof might comprise a flag that represents and / or indicates the existence of the ZKP rather than comprising the ZKP itself directly within the transaction / part. The ZKP of the prohibited data enables a verifier to prove that the transaction or transaction part had previously contained the prohibited data, without revealing the prohibited data itself or any attributes about it.

[0014] The transaction or part that comprises the ZKP or the flag for the ZKP can be sent to one or more nodes on the network for their respective replacements of the original / previous version of the transaction / part that contained the prohibited data. This transaction / part may be called the 'recovery transaction / part' because it allows the offending transaction / part to be continued with by the nodes but without the part(s) that are prohibited. Therefore, embodiments of the present disclosure may, in one form of wording, be described as blockchain-implemented recovery method or systems. In some scenarios, the replacement transaction comprising the proof may be sent to the one or more network nodes after the original version had already been sent to the node(s).

[0015] Preferably, the at least one portion of prohibited data comprises data that is specified or defined as prohibited in or by a policy, rule set, order, legal instrument, contract, instruction, license or other controlling resource. The controlling resource may be generated or endorsed by a controlling entity or authority. Purely for the sake of convenience, we may refer to such a controlling resource as a 'prohibition order'.

[0016] In some embodiments, the ZKP may be associated or linked with a prohibition order that provides and / or confirms parameters or other data relating to the prohibition. Such data may include details relating to the authority / authorities that have issued the prohibition order, dates, parties relevant to the prohibited data and / or prohibition order etc. For example, a contract may comprise a confidentiality clause prohibiting the public dissemination of a document. The contract is enforceable under the law of a given legal jurisdiction. The contract or a court order enforcing the contract, may be provided as the prohibition order.

[0017] In accordance with one possible wording, embodiments enable or facilitate transmission of data across a network from a sending resource to at least one receiving resource. Such methods may comprise sending, from the sending resource to the receiving resource(s), a blockchain transaction or a part of a blockchain transaction to at least one node on a blockchain network. Additionally, or alternatively, such methods may comprise receiving, at the sending resource from the receiving resource, a blockchain transaction or a part of a blockchain transaction from a node on a blockchain network.

[0018] One or more requests or instructions may be sent, from or on behalf of the sending resource to the receiving resource(s). The receiving resource(s) may be node(s) on a blockchain network. The one or more requests may request or instruct the node(s) on the network to replace or substitute the original / previous version of the transaction / part that contained the prohibited data with the recovery transaction / part in their storage facility / facilities with the redacted version containing the ZKP. The node(s) may have already received the original transaction / part from the sending party or from a different sending party. Preferably, the blockchain transaction or the part thereof includes at least one proof, such as a Zero Knowledge Proof (ZKP) or a flag for the Zero Knowledge Proof. The flag can comprise any form of code or identifier that is arranged to indicate that a portion of data at a particular location within a transaction / part has been omitted and / or replaced. The flag may serve as a signal or indicator of the redaction, omission, obfuscation or substitution of the prohibited portion(s) of data. In some embodiments, nodes (participant resources) in the network may be arranged to be able to recognise one or more flags relating to ZKPs and act accordingly. Thus, the flag may be predetermined and coded into software and / or firmware provided for execution by the nodes. The node(s) may be operative or arranged to recognise the flag(s) and respond to their recognition in accordance with machine executable instructions installed on processors of the system that implements the method.

[0019] Additionally, or alternatively, the at least one Zero Knowledge Proof (ZKP) may be arranged such that it can be used to verify (i.e. prove or attest) that at least one prohibited portion of data has been omitted from the blockchain transaction or the part thereof.

[0020] Herein, the term 'omitted' may be interpreted as meaning 'inaccessible in its original and / or unmodified form'.

[0021] The zero Knowledge proof (ZKP) or the flag for the Zero Knowledge Proof can comprise one, some or all of: a hash of the at least one portion of prohibited data; a cryptographic hash of the at least one portion of prohibited data; the output of an obfuscation technique that has been applied to the at least one portion of prohibited data; the output of a masking operation that has been applied to the at least one portion of prohibited data.

[0022] Such ZKPs are readily known to the person skilled in the art. In one or some embodiments, the Zero Knowledge Proof or the flag for the Zero Knowledge Proof may be provided in the blockchain transaction or part thereof such that it replaces the at least one portion of prohibited data.

[0023] In one or some embodiments, the part of the blockchain transaction may be or comprise one, some or all of: an output of a blockchain transaction; an unspent output of a blockchain transaction; a script provided within, or in association with, a blockchain transaction; a portion of metadata provided within or in association with the blockchain transaction or the part thereof.

[0024] In one or some embodiments, the at least one portion of prohibited data may comprise data that is specified or defined as prohibited in or by a policy, rule set, order, legal instrument, contract, instruction, license or other control resource.

[0025] In one or some embodiments, a method of the disclosure may comprise the step of verifying (proving) that the Zero Knowledge Proof or the flag for the Zero Knowledge Proof is a replacement of, or substitute for, the at least one portion of prohibited data in the blockchain transaction or the part thereof.

[0026] In one or some embodiments, the blockchain transaction or part thereof may comprise a flag which indicates that the at least one portion of prohibited data has been replaced by the Zero Knowledge Proof.

[0027] In one or some embodiments, a method of the disclosure may comprise the step of using the Zero Knowledge Proof to verify (prove) that a previous (e.g. original or initial or prior) version of the blockchain transaction or the part thereof contained the at least one portion of prohibited data.

[0028] The previous version may be previous relative to a version of the transaction or part thereof that contained the prohibited data. In one or some embodiments, the Zero Knowledge Proof (ZKP) or the flag for the Zero Knowledge Proof may prevent access to the at least one portion of prohibited data from the blockchain transaction or the part thereof. 'Access' is intended to include at least 'viewing', 'sharing', 'downloading', 'writing to or over', 'editing', 'presenting', 'displaying' or otherwise processing.

[0029] In one or some embodiments, the sending resource and / or the receiving resource may be or may comprise at least one of: i) a node on a computer-based network; and / or ii) a node on a blockchain network; and / or iii) a computing resource arranged to process blockchain transactions; and / or iv) a digital wallet.

[0030] In one or some embodiments, a method of the disclosure may comprise using a storage resource to store at least one of: the at least one prohibited portion of data; the Zero Knowledge Proof or the flag for the Zero Knowledge Proof; a policy, rule set, order, legal instrument, instruction, contract, license or other control resource that specifies or defines the at least one portion of prohibited data as prohibited; an identifier that associates the at least one portion of prohibited data with the Zero Knowledge Proof or the flag for the Zero Knowledge Proof.

[0031] In one or some embodiments, verification that at least one prohibited portion of data has been omitted from the blockchain transaction or the part thereof comprises verifying that the at least one portion of prohibited data is an element in a Merkle tree having a given root. This verification step may be performed substantially in accordance with the techniques and systems disclosed and claimed in the applicant's pending UK patent application GB2303996.9, filed on 20 March 2023, and any patent application claiming priority therefrom. UK patent application GB2303996.9 and any applications claiming priority therefrom are incorporated herein in their entirety. In some embodiments, the storage resource may comprise: a virtual or physical storage resource; at least one cloud based storage resource; at least one Distributed Hash Table (DHT); at least one database; at least one distributed, centralised or decentralised storage resource; a spreadsheet; a file system arranged to store, index and / or search for data records.

[0032] BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0035] Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain;

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

[0037] Figure 3B is a schematic mock-up of an example user interface that may be presented by the client application of Figure 3A;

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

[0039] Figure 5 is a sequence diagram showing communication between a requestor and a node in accordance with an illustrative embodiment of the disclosure;

[0040] Figure 6 is a sequence diagram showing communication between a requestor, a node, and a server in accordance with an illustrative embodiment of the disclosure;

[0041] Figure 7 is a flow diagram illustrating steps of a method in accordance with an illustrative embodiment of the disclosure;

[0042] Figure 8 is a flow diagram illustrating steps of another method in accordance with an illustrative embodiment of the disclosure;

[0043] Figure 9 is a schematic of a transaction that may be subject to a method disclosed herein;

[0044] Figure 10 is a schematic of two transactions which may be subject to methods disclosed herein;

[0045] Figure 11 shows a data structure that may be created by, modified by, or used in methods disclosed herein; and

[0046] Figure 12 is a flow diagram illustrating steps of a method in accordance with an illustrative embodiment of the disclosure. DETAILED DESCRIPTION

[0047] As explained above, sometimes data that has been included in a blockchain transaction may need to be removed or otherwise processed so as to prevent its availability to one or more parties from the blockchain without specific authorisation to do so. This is especially important in respect of public blockchains but applies also to private and permissioned blockchains. 'Availability' may comprise viewing, accessing and / or downloading from the blockchain. We may call such data 'prohibited data' because sharing of the prohibited data has been deemed undesirable, detrimental, unauthorised and / or illegal by one or more authorities.

[0048] In some examples, sharing of the prohibited data may violate a right, such as an intellectual property right. For instance, the prohibited data may comprise copyrighted material / subject matter or may infringe a design right. In other examples, the prohibited data may breach confidentiality restrictions such as those imposed by a contract or statutory law. In legally- oriented contexts, orders such as freezing orders or interim injunctions may exist, or court- imposed publication bans may apply to the prohibited data.

[0049] In some cases, the prohibited data may be a sub portion of a larger portion of data. The sub portion and larger portions of data may be referred to as metadata because it comprises data that is inserted into the transaction (Txo) for application-level purposes, not because it is required by the protocol of the blockchain that the transaction is formed in accordance with.

[0050] In one or more examples, the prohibited data may be sensitive in some way, such as comprising data relating to a person's medical history, state security or commercial advantage e.g. trade secrets. In other examples, prohibited data may comprise illegal or illicit data that is contrary to the laws of a given state or jurisdiction. In essence, the prohibited data may be data that is subject to restriction and control by any given authority that is relevant to a particular context or application. We may use the term 'authority' to include any entity that has jurisdiction, governance, control and / or authority over the prohibited data. The authority may possess the right to enforce sanctions or consequences arising from prohibited actions relating to the prohibited data, or initiate such enforcement by or via other parties. An authority can comprise an individual entity (e.g. a natural or legal person, or a machinebased resource such as an algorithm executing on hardware) or a group of such entities. For example, the authority may be or comprise a government, an organisation such as a corporate or non-corporate entity, a legal or judicial entity such as a court of law or law enforcement entity, a regulatory body etc. In other examples, the authority may determine, control or at least influence the implementation or design of a blockchain protocol and its associated technologies. In some situations, more than one authority may be relevant in respect of data that is written to the blockchain.

[0051] In some cases, the blockchain may be a private or permissioned blockchain rather than a public blockchain, and may be specified or implemented by a particular controlling entity that acts as an authority over users of the blockchain.

[0052] EXAMPLE USE CASE: 1

[0053] As explained above, there can be a need to omit undesirable material from blockchain transactions (or at least prevent access to it in its discernibly original form) whilst still allowing the transaction / part that contains it to be shared or otherwise processed by participants on the network. The prohibition of sharing of the data needs to be performed in a way that still enables the transaction or transaction part that contains it to be shared or processed by nodes on the network.

[0054] Consider a scenario in which metadata is provided as part of a blockchain transaction (Txo) that is sent to the blockchain network for verification and mining by full nodes and subsequent inclusion on the blockchain's ledger. In some embodiments, this may comprise storing the data in a network resource that is arranged to store data relating to unconfirmed blockchain transactions that have not yet been included in a block. In some (but not all) embodiments, this may comprise an ordered set or pool 154 as referred to in the section below entitled 'Example System Overview'.

[0055] Suppose that, subsequent to submission of the transaction to the network, it is discovered or determined that at least one portion of the metadata contravenes the rules or instructions included in a prohibition order. In our example use case, this could be that a judge orders that a particular individual's identity is not revealed, and the metadata comprises a document or portion of text or an image etc. that includes the individual's name or address or social insurance number etc. that could lead to identification of the individual.

[0056] In response to this, a subsequent (recovery) transaction (Txi) or a relevant part of it may be submitted to the blockchain network along with a request that the nodes on the network replace their stored copies of the original transaction or relevant part of it (Txo) with the pruned version of the transaction or relevant part of it (Txi). The recovery transaction or recovery transaction part replaces the prohibited data with a ZKP or a flag indicating that the prohibited data has been removed but is still verifiable via a ZKP. The recovery transaction or part may be generated and / or sent to the network nodes by a sending resource.

[0057] In some embodiments, the receiving nodes on the network may already have a copy of original version of the transaction or part (Txo) and are able to use the ZKP, and / or flag that directs to it, to prove that the contents of the recovery transaction or part (Txi) are the same as the original transaction (Txo) but that certain portion(s) have been omitted, and that the sender of the recovery transaction / part has the original, omitted data. This verification is performed without providing any knowledge about the prohibited data itself, just that it exists and the sender can prove it. The receiving node(s) may identify the relevant transaction (Txo) or part thereof via an identifier that uniquely identifies it. This identifier may comprise one or more of a block header of: a blockchain block that contains the transaction, a blockchain transaction identifier (TxID) as known in the art, an input and / or output identifier, or a user- specified identifier that is not required by the blockchain's protocol but is associated with or provided within the transaction or part.

[0058] In other embodiments, the receiving node(s) may not have a pre-stored copy of the original transaction (Txo). The sending node may instruct the receiving node(s) to monitor incoming traffic on the network and, if a transaction having the unique identifier specified by the sender is detected, substitute the detected version for the pruned version (Txi).

[0059] In some cases, one or more of the receiving nodes may inspect a prohibition order or other evidence to ensure that the omission of the data is authorised and legitimate. The prohibition order may be provided on the blockchain or an offline storage resource and may be accessed from there by the receiving nodes. In some examples, the prohibition order may be provided within or in association with the recovery transaction or a part thereof. For example, the prohibition order or a pointer to it may be provided as metadata in an output script of the recovery transaction (Txi).

[0060] Upon positive confirmation by a node that the prohibited data has been legitimately removed (ie upon successful verification of the prohibited data by the ZKP) a node may replace its stored version or detected version of the transaction (Txo) or part thereof with the recovery transaction (Txi) or part thereof.

[0061] In this way, embodiments of the disclosure provide a mechanism for censorship, filtering, editing, redaction and / or updating of (meta)data that has been submitted to one or more nodes on a blockchain network.

[0062] EXAMPLE USE CASE: 2

[0063] We now provide an illustration of one possible embodiment of the disclosure in use, with particular reference to Figures 5 to 12 and enumerated clause set 2 provided below.

[0064] Referring to Figure 5, there is shown a communication sequence 600 which involves a requestor 602 communicating with a network resource in the form of a node 604. The node may be a node 104 on a blockchain network 150 as shown in Figure 1.

[0065] A requestor 602 may include a computer device or system, such as a phone, tablet, laptop, personal computer, or suchlike. The requestor 602 may be a user instructing the computer device to communicate with the node 604, or may be a computer-based resource such as hardware and firmware arranged to executing code that is operative, when executed, to perform steps in accordance with an embodiment disclosed herein. Hence, the computing resource may be automated to communicate with the node 604. In any case, in such an embodiment, the node 604 receives a request 606 originating from the requestor 602. In this example embodiment, the request 606 is for one or more blockchain transactions (which we may refer to simply as "transactions hereafter for the sake of ease of reference). In other embodiments, the request 606 may be for one or more portions of transactions or data constituting said one or more portions. For example, the request 606 may be for any data in an output field of a particular transaction, such as the data of an unspent transaction output contained in a particular transaction. Transactions, including the requested transaction, may be stored at the node 604.

[0066] In response to receiving the request 606, the node 604 determines whether the transaction (or portion thereof) requested by the requestor 602 contains any data deemed to be prohibited. In embodiments, a data structure (such as data structure 1300, see Figure 11) stores identifiers (such as identifiers 1302) identifying which transactions contain data deemed to be prohibited. An example of such a data structure is shown in Figure 11 and described in detail later.

[0067] An identifier may comprise one or more of:

[0068] • transaction header data

[0069] • data relating to part or all of blockchain block

[0070] • a transaction ID (TxID) orTxID field as known in the art of blockchain technologies;

[0071] • at least one portion of data that is normally provided in association with or as a required or optional feature of the transaction as specified by the blockchain protocol being used by the particular implementation;

[0072] • or a hash of one or more of the above.

[0073] An identifier is any data that allows identification of a particular transaction. The identifier can comprise any form of suitable flag or identification mechanism, including but not limited to a transaction identifier (TxID) as known I the art of blockchain technologies.

[0074] The node 604 queries the data structure (such as data structure 1300) to determine whether the requested transaction (or portion thereof) has a corresponding identifier (such as an identifier 1302) which is present in the data structure, such presence of the identifier in the data structure thereby indicating at least the presence of prohibited data (such as prohibited data 1304) in the requested transaction. In embodiments, the query includes a determination that the node 604 also seeks a proof (such as a proof 1306) that the requested transaction does indeed contain at least one portion of prohibited data. In embodiments the query contains an indication that the node 604 seeks demonstrative data (such as demonstrative data 1308) that demonstrates some recordal of a desire or requirement, however registered, recorded, or expressed in the data structure, that sharing, publication, provision, propagation etc. of the data is restricted, controlled, or forbidden in some manner.

[0075] Having determined that the requested transaction does contain prohibited datal, the node 604 responds to the request 606 by providing to the requestor 602 the requested transaction, or requested portion thereof, minus the at least one portion of prohibited data identified by reference to the data structure. The returned transaction 610 may be described as a redacted transaction.

[0076] Referring to Figure 7, an embodiment is shown in the form of a series of computer- implemented method steps 800. This method 800 is shown containing steps carried out at a node such as node 604. At S802, a node receives a request for a blockchain transaction or a portion thereof. The request may be from a requestor such as requestor 602. At S804, the node determines, from the request, an identifier identifying the requested transaction. At S806, the node determines whether the identifier identified by the node from the request is present in a data structure stored on or accessible by the node and, thus, that the presence of the identifier in the data structure indicates that the transaction contains at least one portion of prohibited data.

[0077] At D808, the node examines determines whether, based on the presence or absence of the identifier in the data structure, whether the requested transaction contains at least one portion of prohibited data. If the determination is negative, i.e. that is there is no prohibited data contained in the requested transaction, then the node moves to S810 and provides the requested transaction. On the other hand, if the determination is positive, (i.e. there is at least one portion of prohibited data in the requested transaction) the node moves to S812 and provides the requested transaction minus the prohibited data. In other words, the node provides to the requestor a redacted version of the transaction. In alternative embodiments, the node may refuse or decline to provide the requested transaction altogether.

[0078] Referring to Figure 6, in another embodiment, having received a request 706 for a transaction from a requestor 702, a node 704 queries a data structure (such as data structure 1300) by sending a message 708A to a server 712 that hosts or has access to the data structure. The server 712 searches the data structure for the requested transaction, determines whether the data structure identifies that the requested transaction contains at least one portion of prohibited data, and sends a return message 708B to the node 704 to inform the node 704 whether the requested transaction contains prohibited data.

[0079] The query from the node 704 to the server 712 may include an indication that the node 704 also seeks a proof (such as a proof 1306) that the requested transaction does indeed contain undesirable material, and / or the query may contain an indication that the node 704 seeks demonstrative data (such as demonstrative data 1308) that demonstrates some requirement or desire, however registered, recorded, or expressed in the data structure, that the data is prohibited and its sharing, publication, provision, propagation etc. is restricted in some manner.

[0080] Having thereby determined that the requested transaction does contain prohibited data, the node 704 responds to the request 706 by providing to the requestor 702 the requested transaction, or portion thereof, minus the prohibited data identified by the server 712 with reference to the data structure. The returned transaction 710 may be described as a redacted transaction.

[0081] Referring to Figure 8, an embodiment is shown in the form of a series of computer- implemented method steps 900. This method 900 is shown containing steps carried out at a node such as node 704. At S902, a node receives a request for a transaction or a portion thereof. The request may be from a requestor such as requestor 702. At S904, the node determines, from the request, an identifier identifying the requested transaction. At S906, the node instructs a server (such as server 712) to determine whether the identifier identified by the node from the request is present in a data structure accessible by the server and whether the data structure associates the identifier with at least one portion of prohibited data. At S907, the node receives a response from the server, which may be affirmative or negative, and may contain additional information beyond simply an affirmative or negative response, such as information stored in association with the identifier in the data structure.

[0082] At D908, the node examines the server's response and determines whether the response contains an affirmative indication, that is, that the identifier is present in the data structure, thereby indicating that the requested transaction contains at least one portion of prohibited data. If the determination is negative, that is the identifier is not present in the data structure, thereby indicating that there is no prohibited data in the requested transaction, then the node moves to S910 and provides the requested transaction.

[0083] If the determination is positive, i.e. that there is at least one portion of prohibited data in the requested transaction, the node moves to S912 and provides the requested transaction absent the at least one portion of prohibited data. In other words, the node provides to the requestor a redacted transaction. In alternative embodiments, the node may refuse to provide the requested transaction altogether.

[0084] Referring to Figure 9, a schematic of a transaction 1000 is shown which exemplifies transactions that may be requested, provided, stored, redacted, and / or refused in accordance with other embodiments described herein.

[0085] Transaction 1000 has a header comprising a transaction ID, TxIDo 1002. The transaction 1000 has input fields 1004 and output fields 1006. The input fields include a first input 1008 which includes a pointer to a previous transaction, an index of a (previously) unspent transaction output (UTXO) of the previous transaction, and an unlocking script for unlocking the UTXO. Transaction 1000 is shown for illustrative purposes, and transactions having alternative structures and fields, and formed in accordance with any suitable blockchain protocol, are equally possible. The output fields include a first output 1010 which includes an amount (in an embodiment, an amount of digital asset(s)), a locking script which locks control of the digital asset(s) to a subsequent transaction with an appropriate unlocking script, and data or a reference, link, or directions to data, such as a URL or file path. In this embodiment, the data is prohibited data 1012. In embodiments, further inputs 1014 and further outputs 1016 may be present.

[0086] Transaction 1000 may be stored on a node, such as nodes 604 and 704, as part of a blockchain. Having received a request for transaction 1000, when a node 604 or server 712 examines a data structure for an identifier potentially identifying the transaction 1000 as containing at least one portion of prohibited data, in this case prohibited data 1012, the node 604 or server 712 may use the TxID, in this case TxIDo 1002, to search the data structure. If the node 604 or server 712 finds TxIDo 1002 in the data structure, the node 604 or 704 takes this as a positive determination that transaction 1000 contains at least one portion of prohibited data.

[0087] Referring to Figure 10, schematics of two transactions, 1100 and 1200, are shown which exemplify transactions that may be requested, provided, stored, redacted, and / or refused in accordance with other embodiments described herein. Transaction 1100 has a header comprising a transaction ID, TxIDi 1102. Transaction 1100 has input fields 1104 and output fields 1106. The input fields include a first input 1108 which includes a pointer to a previous transaction, an index of a (previously) unspent transaction output (UTXO) of the previous transaction, and an unlocking script for unlocking the UTXO. The output fields include a first output 1110 which includes an amount (for example, an amount of digital asset(s)) and a locking script which locks control of the amount to a subsequent transaction with an appropriate unlocking script, which in this case is transaction 1200. Transaction 1100 is stored on a blockchain.

[0088] Transaction 1200 has a header comprising a transaction ID, TxIDz 1202. Transaction 1200 has input fields 1204 and output fields 1206. The input fields include a first input 1208 which includes a pointer to transaction 1100, an index of previously unspent transaction output UTXOi 1110 of transaction 1100, and an unlocking script for unlocking UTXOi 1110. The output fields include a first output 1210 which includes an amount (in an embodiment, an amount of digital asset(s)), a locking script which locks control of the amount to a subsequent transaction with an appropriate unlocking script, and material data or a reference, link, or directions to material data. In this embodiment, the data is prohibited data 1212.

[0089] In this embodiment, transactions 1100 and 1200 are shown for illustrative purposes and transactions having alternative structures and / or fields, formed in accordance with any suitable blockchain protocol, are also possible.

[0090] In embodiments, transactions 1100 and 1200 may include further inputs 1114, 1214 and further outputs 1116, 1216 respectively.

[0091] In Figure 10, transaction 1200 is not stored on a blockchain but has been submitted for addition to the blockchain. Transaction 1200 is therefore in a queue or holding area 520 for whatever verification and / or validation procedures are required for the blockchain protocol in use. In some, but not all embodiments the holding area 520 may be a mempool. Transaction 1200 may be stored in memory on a node such as node 604 or node 704.

[0092] Having received a request for transaction 1200, or to submit transaction 1200 to the blockchain, or to propagate or otherwise share or publicise transaction 1200, when a node 604 or server 712 examines a data structure for an identifier potentially identifying transaction 1200 as containing prohibited data, in this case prohibited data 1212, the node 604 or server 712 may use the TxID, in this case TxIDo 1202, to search the data structure. If the node 604 or server 712 finds TxIDo 1202 in the data structure, the node 604 or 704 takes this as a positive determination that transaction 1200 contains at least one portion of prohibited data.

[0093] Referring to Figure 11, a data structure 1300, useable in conjunctions with embodiments described herein and shown in the form of an array, is shown. The data structure 1300 comprises a plurality of identifiers that identify transactions. In an embodiment, the identifiers are transaction IDs "TxID" 1302. The data structure 1300 associates identifiers with what has been determined or designated (by at least one authority) to be prohibited data 1304. In an embodiment, the respective data 1304 associated with each particular transaction identified by an identifier is stored in the data structure. In another embodiment, one or more hashes of such prohibited data is stored instead. In an embodiment, a proof of what the prohibited data is, and / or a proof that the associated transaction contains that prohibited data, is stored alongside the identifier.

[0094] In an embodiment, the proof includes a zero-knowledge proof (ZKP) 1306. In an embodiment, prohibition order 1308 is stored alongside the identifier. A prohibition order in this context comprises data and / or instructions which demonstrates an intent, aim, desire, instruction, or suchlike indication that the prohibited data is undesirable or not allowed for some reason and is not to be distributed, disclosed, shared, or propagated. For this reason, 'prohibition order' may also be referred to herein as 'demonstrative data'. The prohibition order may, in embodiments, include: a court order that the material is not to be shared, distributed, etc.; a contract that stipulates a restriction on the sharing, distribution etc. of the prohibited data; and / or a policy that describes a restriction on the data. In some other cases, the prohibited data may be prohibited by a law, rule, or policy of some kind. This rule, law, or policy may be specified by at least one authority such as, for example, a court of law, or an organisation such as a company or association, a public body, regulatory body.

[0095] Embodiments involving examples of transaction identifiers and the data that is stored in association with those identifiers will now be described. In these exemplary embodiments, the identifiers may be transaction identifiers that are required as a feature specified by the blockchain protocol that the transaction are formed in accordance with. In conventional terminology, such a blockchain transaction identifier may be referred to as a TxID.

[0096] Suppose that it has been determined that a transaction identified by means of transaction identifier TxIDo contains prohibited data in accordance with any embodiment described above. In an example embodiment, data structure 1300 contains one or a plurality of records. Each record comprises an associated set of fields 1310 comprising transaction ID TxIDo alongside the following:

[0097] • a hash of the prohibited data portion(s) that are contained in the transaction (while the data structure 1300 may instead store the prohibited data itself, a hash of the data may be advantageous where, for example, storage space is at a premium or if the prohibited data is of a sufficiently private, sensitive or secret nature as to warrant it being stored in a non-readable form); • a zero-knowledge proof that the transaction identified by TxIDo contains the prohibited data which hashes to the aforementioned hash;

[0098] • and a court order that stipulates that the data contained in the transaction is prohibited data that is not to be shared, revealed, provided, propagated etc. under any circumstances.

[0099] Note that, in this example, the prohibited data may be prohibited data 1012 as shown in transaction 1002 of Figure 9.

[0100] Suppose that it has been determined that a transaction identified by means of transaction identifier TxIDz contains at least one portion of prohibited data. Data structure 1300 contains an associated set of fields 1312 comprising transaction ID TxIDz alongside the following: an image file "IMG_001.png" designated as prohibited data which is stored in the transaction, which may, for example, be prohibited data 1212 of the transaction shown in Figure 10; a zero-knowledge proof that the transaction identified by TxIDz contains the image file; and a contract that specifies that the image file contained in the transaction is prohibited data whose sharing is in violation of the contract (for example, due to the image file violating a copyright held in the image, or disclosure of the image is contrary to its creator's wishes as set out in the contract).

[0101] Suppose that it has been determined that a transaction identified by means of transaction identifier TxIDAContains at least one portion of prohibited data. Data structure 1300 contains an associated set of fields 1314 comprising transaction ID TXI DA alongside the following: a username and password pair, designated as prohibited data, which are stored in the transaction; a zero-knowledge proof that the transaction identified by TxIDA Contains the username and password; and a policy that sets out that disclosing this username and / or password publicly is contrary to the requirements of the company or institution with which the policy is associated.

[0102] Suppose that it has been determined that a transaction identified by means of transaction identifier TxIDBeontains at least one portion of prohibited data. Data structure 1300 contains an associated set of fields 1316 comprising transaction ID TxIDsalongside the following: a URL of a website at which the prohibited data may be found or accessed; a zero-knowledge proof that the transaction identified by TxIDsfacilitates access to the material by means of the URL; and a court order that stipulates that the prohibited data to which the URL leads, contained in the transaction, is prohibited data that is not to be shared, revealed, provided, propagated etc. under any circumstances.

[0103] Referring to Figure 12, an embodiment is shown in the form of computer-implemented method steps 1400. In this embodiment, a data structure, such as data structure 1300, is modified or populated with identifiers of transactions deemed to include prohibited data or a link, address, or directions etc. thereto.

[0104] In method 1400, a computer device, such as node 604, node 704, or server 712, identifies (at step S1402) a transaction that contains at least one portion of prohibited data. The transaction may be stored on a blockchain or may be queued in a queue, holding area, mempool, or a buffer for verification, validation, confirmation, and / or addition to a blockchain. The identification may comprise receiving an identifying request that identifies a transaction that contains prohibited data. The identifying request may request that the prohibited data is not to be shared, propagated, publicised, or otherwise made available. The identifying request may include proof data and / or prohibition order such as proof data 1306 and / or prohibition order 1308 as described above in relation to Figure 11.

[0105] At step S1404, the computer device obtains an identifier of the transaction for storage in a data structure whose purpose is to store such identifiers for indicating their association with transactions that store prohibited data. The obtaining may involve receiving such an identifier as part of an identifying request.

[0106] At step D1406, the computer device checks the data structure to determine whether the identifier is already present. If the identifier is not present, the computer device moves to step S1408 and adds the identifier to the data structure or requests a controlling entity of the data structure, such as server 712, to add the identifier to the data structure. The computer device may also add, or request to add, any further information about the transaction or prohibited data, such as proof data and / or demonstrative data received as part of an identifying request. If the identifier is already present, the computer device moves to step S1410 and may take no further substantive action and may discard the obtained identifier.

[0107] In this way, a data structure containingthe information necessary to identify transactions that contain or direct to prohibited data is generated, modified, and / or populated.

[0108] EXAMPLE SYSTEM OVERVIEW

[0109] Herein, we use the term "node" as meaning (but not limited to) a full node on a blockchain network unless the context determines otherwise as understood by the person skilled in the art, or specifically defined otherwise in the specification text.

[0110] Also, we may refer herein to the Bitcoin protocol / network / ledger for the sake of convenience only and because it is the most widely known of such technologies. However, the disclosure is not limited to use with Bitcoin and other ledger-based protocols / networks are intended to fall within the scope of the disclosure. "Bitcoin" is not limited to meaning any particular Bitcoin-related protocol, and any protocol or implementation flowing from, varying from or deviating from the original Bitcoin protocol is intended to fall within the scope of the disclosure. Herein, the terms 'Bitcoin' and 'blockchain' can be used interchangeably.

[0111] With reference to figures 1 to 4, we now provide, for the purposes of illustration and without limitation, various examples of computing systems which can be used to put embodiments disclosed herein into effect.

[0112] A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.

[0113] The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to time-order index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance, this may be used to store an electronic document in the blockchain, or audio or video data.

[0114] In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction. In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another 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 any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.

[0115] An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly.

[0116] Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may 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") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104.

[0117] Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. 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 disk drive.

[0118] The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.

[0119] A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.

[0120] In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

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

[0122] The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.

[0123] Any given blockchain node may 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, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations.

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

[0125] Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively.

[0126] The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action

[0127] T1 attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.

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

[0129] The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.

[0130] Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.

[0131] The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106.

[0132] An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.

[0133] Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable 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 an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an output-based transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an outputbased transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" 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) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction.

[0134] UTXO-BASED MODEL

[0135] Some blockchain protocols are designed using a "UTXO-based" model. We now provide information relating to such approaches. However, this is provided without limitation, for the purpose of illustration of one possible implementation environment that the disclosure may be put into effect with. Other protocol models may be used for this purpose and embodiments are specifically and categorically not limited to implementation with a UTXO- based blockchain or associated protocol.

[0136] Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.

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

[0138] Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled "Txi" . It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “ Txo" in Figure 2. 7 ? a nd Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.

[0139] The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour.

[0140] One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.

[0141] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions.

[0142] So in the example illustrated, UTXOo in the output 203 of Txo comprises a locking script [Checksig PA] which requires a signature Sig PA of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig PA] contains a representation (i.e. a hash) of the public key PA from a public-private key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo). The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig PA> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0143] When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria).

[0144] Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0145] Typically an input of a transaction contains a digital signature corresponding to a public key PA. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing).

[0146] The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred.

[0147] SIDE CHANNEL

[0148] As shown in Figure 1, the client application on each of Alice and Bob's computer equipment 102a, 120b, respectively, may comprise additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For instance this may be used to exchange a transaction 152 between Alice and Bob without the transaction (yet) being registered onto the blockchain network 106 or making its way onto the chain 150, until one of the parties chooses to broadcast it to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". A transaction template may lack one or more inputs and / or outputs that are required in order to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction related data, such as keys, negotiated amounts or terms, data content, etc.

[0149] The side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. Generally, the side channel 107 as referred to anywhere herein may comprise any one or more links via one or more networking technologies or communication media for exchanging data "off-chain", i.e. separately from the blockchain network 106. Where more than one link is used, then the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Note therefore that if it is said that Alice and Bob exchange certain pieces of information or data, or such like, over the side channel 107, then this does not necessarily imply all these pieces of data have to be send over exactly the same link or even the same type of network.

[0150] CLIENT SOFTWARE Figure 3A illustrates an example implementation of the client application 105 for implementing embodiments of the presently disclosed scheme. The client application 105 comprises a transaction engine 401 and a user interface ( U I ) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as to formulate transactions 152, receive and / or send transactions and / or other data over the side channel 301, and / or send transactions to one or more nodes 104 to be propagated through the blockchain network 106, in accordance with the schemes discussed above and as discussed in further detail shortly. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 comprises a function 403 that submits a request for and / or to propagate a transaction to one or more nodes 104 and receives, in return, the transaction or a redacted transaction if it is determined at the node that the requested transaction comprises material deemed undesirable or comprises a referral thereto. Details of the determination and the redaction are set out in embodiments below.

[0151] The Ul layer 402 is configured to render a user interface via a user input / output (I / O) means of the respective user's computer equipment 102, including outputting information to the respective user 103 via a user output means of the equipment 102, and receiving inputs back from the respective user 103 via a user input means of the equipment 102. For example the user output means could comprise one or more display screens (touch or non-touch screen) for providing a visual output, one or more speakers for providing an audio output, and / or one or more haptic output devices for providing a tactile output, etc. The user input means could comprise for example the input array of one or more touch screens (the same or different as that / those used for the output means); one or more cursor-based devices such as mouse, trackpad or trackball; one or more microphones and speech or voice recognition algorithms for receiving a speech or vocal input; one or more gesture-based input devices for receiving the input in the form of manual or bodily gestures; or one or more mechanical buttons, switches or joysticks, etc.

[0152] Note: whilst the various functionality herein may be described as being integrated into the same client application 105, this is not necessarily limiting and instead they could be implemented in a suite of two or more distinct applications, e.g. one being a plug-in to the other or interfacing via an API (application programming interface). For instance, the functionality of the transaction engine 401 may be implemented in a separate application than the Ul layer 402, or the functionality of a given module such as the transaction engine 401 could be split between more than one application. Nor is it excluded that some or all of the described functionality could be implemented at, say, the operating system layer. Where reference is made anywhere herein to a single or given application 105, or such like, it will be appreciated that this is just by way of example, and more generally the described functionality could be implemented in any form of software.

[0153] Figure 3B gives a mock-up of an example of the user interface (Ul) 500 which may be rendered by the Ul layer 402 of the client application 105a on Alice's equipment 102a. It will be appreciated that a similar Ul may be rendered by the client 105b on Bob's equipment 102b, or that of any other party. By way of illustration Figure 3B shows the Ul 500 from Alice's perspective. The Ul 500 may comprise one or more Ul elements 501, 502, 502 rendered as distinct Ul elements via the user output means.

[0154] For example, the Ul elements may comprise one or more user-selectable elements 501 which may be, such as different on-screen buttons, or different options in a menu, or such like. The user input means is 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 Ul element onscreen, or speaking a name of the desired option (N.B. the term "manual" as used herein is meant only to contrast against automatic, and does not necessarily limit to the use of the hand or hands). The options enable the user (Alice) to request the aforementioned transactions from one or more nodes 104.

[0155] Alternatively or additionally, the Ul elements may comprise one or more data entry fields 502, through which the user can ... These data entry fields are rendered via the user output means, e.g. on-screen, and the data can be entered into the fields through the user input means, e.g. a keyboard or touchscreen. Alternatively the data could be received orally for example based on speech recognition.

[0156] Alternatively or additionally, the Ul elements may comprise one or more information elements 503 output to output information to the user. E.g. this / these could be rendered on screen or audibly. It will be appreciated that the particular means of rendering the various Ul elements, selecting the options and entering data is not material. The functionality of these Ul elements will be discussed in more detail shortly. It will also be appreciated that the Ul 500 shown in Figure 3 is only a schematized mock-up and in practice it may comprise one or more further Ul elements, which for conciseness are not illustrated.

[0157] NODE SOFTWARE

[0158] Figure 4 illustrates an example of the node software 450 that is run on each blockchain node 104 of the network 106, in the example of a UTXO- or output-based model. Note that another entity may run node software 450 without being classed as a node 104 on the network 106, i.e. without performing the actions required of a node 104. The node software 450 may contain, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that contains one or more of: a consensus module 455C (for example, proof-of-work), a propagation module 455P and a storage module 455S (for example, a database). The consensus module 455C may contain a validation module (not shown) configured to validate transactions according to the blockchain protocol. The validation module may instead be separate from the consensus module 455C. One or more of the modules may operate in parallel. A node 104 may contain additional modules. The protocol engine 401 is typically configured to recognize the different fields of a transaction 152 and process them in accordance with the node protocol. When a transaction 152j (Txj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 152i (Txm-), then the protocol engine 451 identifies the unlocking script in Txj and passes it to the script engine 452. The protocol engine 451 also identifies and retrieves Txtbased on the pointer in the input of Txj. Txtmay be published on the blockchain 150, in which case the protocol engine may retrieve Txtfrom a copy of a block 151 of the blockchain 150 stored at the node 104. Alternatively, Txtmay yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txtfrom the ordered set 154 of unpublished transactions maintained by the nodel04. Either way, the script engine 451 identifies the locking script in the referenced output of Txtand passes this to the script engine 452. The script engine 452 thus has the locking script of Txtand the unlocking script from the corresponding input of Txj. For example, transactions labelled Tx0and Tx are illustrated in Figure 2, but the same could apply for any pair of transactions. The script engine 452 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 453 in accordance with the stack-based scripting language being used (e.g. Script).

[0159] By running the scripts together, the script engine 452 determines whether or not the unlocking script meets the one or more criteria defined in the locking script - i.e. does it "unlock" the output in which the locking script is included? The script engine 452 returns a result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result "true". Otherwise it returns the result "false".

[0160] In an output-based model, the result "true" from the script engine 452 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 451 that must be met as well; such as that the total amount of digital asset specified in the output(s) of Txj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Txthas not already been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. Only on condition that Txj is indeed validated, the decision engine 454 may select to control both of the consensus module 455C and the propagation module 455P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 455C adding Txj to the node's respective ordered set of transactions 154 for incorporating in a block 151, and the propagation module 455P forwarding Txj to another blockchain node 104 in the network 106. Optionally, in embodiments the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. E.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee.

[0161] Note also that the terms "true" and "false" herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, "true" can refer to any state indicative of a successful or affirmative outcome, and "false" can refer to any state indicative of an unsuccessful or nonaffirmative outcome. For instance in an account-based model, a result of "true" could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true).

[0162] Some embodiments above may have been described in terms of a 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 may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above.

[0163] In some but not all embodiments of the disclosure, the blockchain network 106 may the bitcoin network and nodes 104 perform at least some or all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the bitcoin network 106).

[0164] In some embodiments, the blockchain network 106 may not be a Bitcoin-based network or a UTXO-based blockchain / protocol. In these embodiments, it is not excluded that a node may 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 instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes.

[0165] Even more generally, any reference to the term "node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104 that implements any particular model of blockchain protocol.

[0166] Any reference herein to "cryptocurrency" may be replaced with "blockchain asset", "native blockchain token". Any reference to a particular blockchain protocol e.g. Bitcoin can be replaced with "blockchain" or "blockchain protocol".

[0167] Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof-of- work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of- stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof-of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator.

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

[0169] ENUMERATED CLAUSES:

[0170] We now provide, for the purposes of illustration only, the following clause sets which define possible embodiments as disclosed herein. The following clause sets are not mutually exclusive, and anyfeature(s) recited in respect of one clause or clause set can be incorporated and combined with any other feature(s) in one or more other clauses or clause sets.

[0171] In accordance with one possible wording, embodiments of the disclosure may provide computer-implemented methods and systems. These may enable and / or facilitate filtering, censoring, redacting, obfuscating or selectively pruning data in a blockchain transaction or a part of such a blockchain transaction. The transaction part may be, for example, an output, a script, a portion of metadata, a block header. The transaction, or a transaction that comprises the transaction part, may be provided within or associated with a blockchain block that is formed in accordance with a given blockchain protocol. The blockchain protocol may be any suitable blockchain protocol such as the Bitcoin protocol or a derivative thereof, the Ethereum protocol, or any alternative blockchain protocol.

[0172] The data may be preferred to as prohibited data. Thus, the transaction and / or part thereof may have been sent to at least one full (mining) node on a blockchain network. It may have been minded into a block that has been written to the ledger of the blockchain. It may have been incorporated into a candidate block by at least one full node on the blockchain network, but not yet written to the ledger. It may form part of a set of unconfirmed transactions. It may form part of mempool.

[0173] Preferably, the blockchain transaction or the part of the blockchain transaction includes a Zero Knowledge Proof (ZKP / ZNP) or a flag for the ZKP. Preferably, the ZKP or the flag for it replaces (acts as a substitute or place marker for) at least one portion of prohibited data. This may mean (i.e. indicate that, or enable interpretation that) that the at least one portion of prohibited data had been provided in a previous (e.g. original) version or form of the transaction or the part thereof. Preferably, substitution of the ZKP / flag for the at least one portion of prohibited data renders the portion(s) of prohibited data inaccessible from the transaction or the part thereof in its original form. This may mean that a third party (such as a receiver or other processor of the blockchain transaction / part thereof) is unable to view, download or otherwise process the at least one portion of prohibited data.

[0174] Embodiments may comprise the step of replacing, in the blockchain transaction or the part thereof, the at least one portion of prohibited data with at least one ZKP. Preferably, the ZKP can be used to verify the prior existence of the prohibited data in the transaction or part thereof without sharing or distributing the prohibited data itself. The ZKP proves the existence of the at least one portion of prohibited data without revealing what the prohibited portion of data is, or anything else about it. In an advantageous embodiment, this enables nodes on a blockchain network to comply with an authority's rules or other requirements e.g. company policies, contracts, licenses, court orders etc. that have the authority to restrict or otherwise control dissemination of the prohibited data, while still enabling transmission or spending of the blockchain transaction or the part thereof.

[0175] The prohibited data may comprise any form or format of digital data, and be arranged for any desired purpose. In an alternative form of wording, the prohibited data may be referred to as "(undesirable) information / content / material". This may include, for example, multimedia / video / audio content, machine readable or executable code, text, static or animated images, database or spreadsheet contents, raw data etc. Herein, the terms "referring", "reference", and "directions" are intended to encompass any information or data that teaches or directs a user where and / or how to access the prohibited data information and / or provides the means for the user to access the prohibited data. For example, the directions may include a URL / URI, a file path, access credentials to a password-protected resource, and suchlike.

[0176] A method of the disclosure may comprise the step of providing a blockchain transaction (Txi) or part thereof to at least one node on a network. The blockchain transaction (Txi) or part thereof may be referred to as a recovery transaction / part. The part may be a script (e.g. unlocking script or locking script) or an output of a blockchain transaction e.g. UTXO. The network may be a blockchain network. The at least one node may be a full e.g. mining node. The recovery blockchain transaction (Txi) or part thereof may comprise a ZKP that can be used to verify the existence of a portion of data that has been redacted (i.e. removed, replaced, obfuscated or otherwise rendered inaccessible) from an original, non-redacted version (Txo) of the blockchain transaction (Txi) or part thereof.

[0177] The recovery transaction (Txi) or part may be identified by a unique identifier. The recovery transaction (Txi) or part may be sent from a sending resource on the network to one or more receiving resources on the network. The sending resource may send a request or instruction to the at least one receiving resource to replace or substitute a stored, unredacted version or copy of the blockchain transaction or part thereof with the redacted (i.e. recovery) version of the blockchain transaction or part thereof. The request or instruction may comprise the unique identify such that the receiving resource(s) are able to identify and / or locate the stored unredacted version of the blockchain transaction / part (Txo). Additionally, or alternative, the instruction or request may request or instruct that the receiving resource(s) monitor traffic and data packets on the network for a transaction or part having the unique identifier and, if a match is detected, ignore the detected version of the transaction or part (Txo) and process the supplied (redacted) version (Txi) instead. The processing may comprise one or more of: storing, transmiting across the network or verifying the transaction / part in accordance with a blockchain protocol.

[0178] The ZKP may be provided in the recovery transaction (Txi) or part thereof, or a there may be provided a pointer, reference, link or other direction that allows the on or off-chain location of the ZKP to be determined. The at least one receiving resource or the sending resource may use the ZKP to verify the existence of the redacted prohibited data.

[0179] The request or instruction sent by the sending resource may comprise a prohibition order or other data atesting to an authorisation, rule, order and / or instruction relating to the prohibited data, the prohibition order may be provided in the recovery transaction (Txi) or part thereof, or the recovery transaction or part may comprise a pointer, reference, link or other direction that allows the on or off-chain location of the prohibition order to be determined.

[0180] Following receipt of the recovery transaction (Txi) or part thereof, the receiving node(s) may transmit the recovery transaction (Txi) or part thereof to at least one further receiving node.

[0181] The ZKP may comprise one or more of: a hash, a cryptographic hash, the output of a redaction operation, a masking or obfuscation operation or any other known technique that functions as a Zero Knowledge Proof of the existence of the redacted (i.e. prohibited) data. The terms 'pruning', 'redacting', omitting' and 'obfuscating' may all be used interchangeably herein.

[0182] In some examples, embodiments may comprise one or more of the following steps:

[0183] • sending, by a sending resource to at least one receiving resource, an original / unredacted version of a blockchain transaction and / or a part of a blockchain transaction;

[0184] • subsequently, sending, by the sending resource or at least one further sending resource to the at least one receiving resource: o a modified / redacted version of the blockchain transaction and / or a part of a blockchain transaction; and o at least one request and / or instruction to replace (in memory / storage controlled by, accessible by and / or associated with the at least one receiving resource) the blockchain transaction and / or a part of a blockchain transaction with the modified / redacted version.

[0185] The method may comprise the step of storing, by the at least one receiving resource, the original / unredacted version of the blockchain transaction and / or a part of a blockchain transaction. The original version may be stored in memory / storage controlled by, accessible by and / or associated with the at least one receiving resource. One or more of the at least one receiving resources may be a node, such as a full node, on a blockchain network.

[0186] The modified / redacted version may comprise a (ZKP) which replaces at least one portion of prohibited data.

[0187] Additionally, or alternatively, the at least one request and / or instruction may request or require the at least one receiving resource to substitute the modified / redacted version of the transaction / part thereof for the original version in any messages or electronic transmissions that require transmission of the original version of the transaction / part thereof.

[0188] Clause Set 1:

[0189] In accordance with one possible form of wording, embodiments may provide: Clause 1.1. A computer-implemented method of transmitting data across a network from a sending resource to a receiving resource, comprising: sending, from the sending resource to the receiving resource, a blockchain transaction (Txi) or a part thereof to a node on a blockchain network; or receiving, at the sending resource from the receiving resource, a blockchain transaction (Txi) or a part thereof from a node on a blockchain network; and wherein: i) the blockchain transaction (Txi) or the part thereof (i.e. a part of a blockchain transaction) includes at least one Zero Knowledge Proof (ZKP) or a flag for the Zero Knowledge Proof; and ii) the at least one Zero Knowledge Proof (ZKP) can be used to verify (i.e. enables or facilitates verification by a verifying party) that at least one prohibited portion of data has been redacted from the blockchain transaction (Txi) or the part thereof.

[0190] In other words, the ZNP enables or facilitates determination or interpretation that at least one portion of data has been redacted from the blockchain transaction or the part thereof. It may enable or facilitate determination or interpretation that at least one portion of data has been redacted from the blockchain transaction or the part thereof at a particular location.

[0191] Clause 1.2. A method according to clause 1.1, wherein the zero Knowledge proof (ZKP) or the flag for the Zero Knowledge Proof comprises one or more of: a hash of the at least one portion of prohibited data; a cryptographic hash of the at least one portion of prohibited data; the output of an obfuscation technique that has been applied to the at least one portion of prohibited data; the output of a masking operation that has been applied to the at least one portion of prohibited data.

[0192] Clause 1.3. A method according to clause 1.1 or clause 1.2, wherein: the Zero Knowledge Proof or the flag for the Zero Knowledge Proof is provided in the blockchain transaction or part thereof such that it replaces the at least one portion of prohibited data.

[0193] Clause 1.4. A method according to any preceding clause, wherein the part of the blockchain transaction is or comprises at least one of: an output of a blockchain transaction; an unspent output of a blockchain transaction; a script provided within, or in association with, a blockchain transaction; a portion of metadata provided within or in association with the blockchain transaction or the part thereof.

[0194] Clause 1.5. A method according to any preceding clause, wherein: the at least one portion of prohibited data comprises data that is specified or defined as prohibited in or by a policy, rule set, order, legal instrument, law, contract, instruction, license or other control resource.

[0195] Clause 1.6. A method according to any preceding clause, and comprising: verifying that the Zero Knowledge Proof or the flag for the Zero Knowledge Proof is a replacement of, or substitute for, the at least one portion of prohibited data in the blockchain transaction or the part thereof.

[0196] Clause 1.7. A method according to any preceding clause, wherein: the blockchain transaction or part thereof comprises a flag which indicates that the at least one portion of prohibited data has been replaced by the Zero Knowledge Proof.

[0197] Clause 1.8. A method according to any preceding clause, and comprising: using the Zero Knowledge Proof to verify that: i) a previous version (Txo) of the blockchain transaction (Txi) or the part thereof contained the at least one portion of prohibited data; or ii) the at least one portion of prohibited data exists. Clause 1.9. A method according to any preceding clause, wherein: the Zero Knowledge Proof (ZKP) or the flag for the Zero Knowledge Proof prevents access to the at least one portion of prohibited data from the blockchain transaction or the part thereof.

[0198] Clause 1.10. A method according to any preceding clause, wherein the sending resource and / or the receiving resource is or comprises: i) a node on a computer-based network; and / or ii) a node on a blockchain network; and / or iii) a computing resource arranged to process blockchain transactions; and / or iv) a digital wallet.

[0199] Clause 1.11. A method according to any preceding clause, and further comprising: using a storage resource to store at least one of: the at least one prohibited portion of data; the Zero Knowledge Proof or the flag for the Zero Knowledge Proof; a policy, rule set, order, legal instrument, instruction, contract, license or other control resource that specifies or defines the at least one portion of prohibited data as prohibited; an identifier that associates the at least one portion of prohibited data with the Zero Knowledge Proof or the flag for the Zero Knowledge Proof.

[0200] Clause 1.12. A method according to any preceding clause, wherein: verification that at least one prohibited portion of data has been omitted from the blockchain transaction or the part thereof comprises verifying that the at least one portion of prohibited data is an element in a Merkle tree having a given root.

[0201] Clause 1.13. A computer system comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores or executes code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of clauses 1.1 to 1.12.

[0202] Clause 1.14. A computer system according to clause 1.13, wherein the system further comprises one or more of: a storage or file system; a database; a component operative to interact with a blockchain network and / or a blockchain ledger; a digital wallet, preferably wherein the digital wallet is operative to process and / or generate blockchain transactions; a software component that is arranged, when executed, to execute or implement a blockchain client.

[0203] Clause 1.15. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 1.1 to 1.12.

[0204] Clause Set 2:

[0205] Additionally, or alternatively, embodiments of the present disclosure may provide methods and systems as set out in the following clauses, and substantially as illustrated in Figures 5 to 12.

[0206] In accordance with any one or more of the clauses in clause set 2, there may be provided a method (and corresponding system) of operating a network resource. The network resource may be or comprise a blockchain network or a node on a blockchain network.

[0207] There may be provided:

[0208] Clause 2.1. A computer-implemented method, comprising: i) determining whether an identifier identifying a blockchain transaction is specified in a data structure that associates blockchain transactions with portions of prohibited data; and ii) when the determination is positive, omitting at least one portion of prohibited data from the blockchain transaction and providing and / or propagating a redacted version of the blockchain transaction to at least one recipient.

[0209] The determination step may be performed in response to receiving a request for and / or to propagate a transaction. A 'positive' determination may comprise identification of the blockchain transaction in the data structure.

[0210] The redacted version of the blockchain transaction may be modified relative to an initial state of the blockchain transaction such that the at least one portion of the blockchain transaction has been omitted from the redacted version. Omission of the at least one portion of the blockchain transaction may comprise its removal and / or substitution with a respective at least one replacement element. The at least one replacement element may comprise a flag, placeholder or other indicator that is provided in the redacted version of the blockchain transaction (Txi) at the location of the respective omitted at least one portion in the original version of the blockchain transaction. Additionally, or alternatively, the at least one replacement element may comprise a proof. The proof may comprise a Zero Knowledge Proof (ZKP) or some other mechanism which facilitates / enables verification of the omission (redaction) of the at least one portion of prohibited data without revealing or communicating in any way the (e.g. unmodified) content of the at least one portion of prohibited data or other information relating to the at least one portion of prohibited data. Additionally, or alternatively, the replacement element may comprise a replacement notice.

[0211] The at least one portion of prohibited data that is omitted from the blockchain transaction in step ii) may be associated with the blockchain transaction in the data structure.

[0212] The blockchain transaction may comprise a (blockchain) transaction identifier. The data structure may associate blockchain transactions with portion(s) of prohibited data. In one or more embodiments, the data structure may store one or a plurality of prohibited portions of data, each of which are associated with at least one blockchain transaction. The association between a given transaction and a given portion of prohibited data may be recorded / implemented in the data structure using the transaction identifier. Additionally, or alternatively, the data structure may store one or a plurality of blockchain transactions and their respective identifiers.

[0213] The blockchain transaction identifier may be associated in the data structure with one or a plurality of portions of prohibited data. Conversely, each portion of prohibited data in the data structure may be associated with one or more blockchain transactions.

[0214] The blockchain transaction identifier may comprise a blockchain block header or hash thereof, or a blockchain transaction ID (TxID) as known in the art, a flag or a protocol flag, or other identifier that enables or facilitates identification of the blockchain transaction within the data structure. The at least one recipient may be a resource on a network. It may be a node on a blockchain network.

[0215] The term 'data structure' may be used interchangeably with 'storage resource' and / or 'computer-based storage facility'. The data structure may comprise software, firmware and / or hardware.

[0216] Clause 2.2. The method of clause 2.1, further comprising providing and / or propagating a proof that the blockchain transaction comprises the at least one portion of prohibited data. This step may be performed in response to the request.

[0217] Clause 2.3. The method of clause 2.2, wherein the proof comprises a hash of the at least one portion of prohibited data.

[0218] Clause 2.4. The method of clause 2.2 or clause 2.3, wherein the proof comprises a zeroknowledge proof of the at least one portion of prohibited data.

[0219] Clause 2.5. The method of any preceding clause, further comprising providing and / or propagating at least one prohibition order that demonstrates, specifies, confirms or comprises a requirement to refuse, decline, prohibit or obfuscate provision of the at least one portion of prohibited data. This step may be performed in response to the (or a new) request.

[0220] Clause 2.6. The method of clause 2.5, wherein the prohibition order comprises a court order or directions to a storage location of a court order. Such directions may comprise a weblink, such as in the form of a URL or a URL

[0221] Clause 2.7. The method of clause 2.5 or clause 2.6, wherein the prohibition order comprises a rule, law, instruction, requirement or policy or directions to the storage location of a rule, law, instruction, requirement or policy.

[0222] Clause 2.8. The method of any preceding clause, wherein the data structure associates the transaction identifiers with: i) at least one proof of the respective at least one portion of prohibited data; and / or ii) at least one requirement to refuse / decline / query / prohibit provision of the respective at least one portion of prohibited data.

[0223] Clause 2.9. The method of any preceding clause, wherein the data structure comprises a database, hash table, Distributed hash table (DHT), cloud-based storage facility or any other computer-passed storage resource arranged for storage of electronic / digital data.

[0224] Clause 2.10. The method of any preceding clause, wherein the data structure comprises a distributed hash table.

[0225] Clause 2.11. The method of any preceding clause, wherein the data structure is a centralised data structure accessible and / or modifiable by a plurality of network resources.

[0226] Clause 2.12. The method of any preceding clause, further comprising, when the at least one portion of prohibited data is contained or referred to in a spent output of the blockchain transaction, preventing visibility and / or access of a portion of the blockchain transaction that contains or refers to the at least one portion of prohibited data via a blockchain ledger. The blockchain ledger may be associated with a blockchain protocol, and the blockchain transaction may be formed in accordance with the blockchain protocol. Preventing visibility or access may comprise replacing the portion of the blockchain transaction that originally contained the at least one portion of prohibited data with a replacement element e.g. a placeholder, flag, notice or proof etc. as described above. This may provide the functionality of being able to verify the existence of the at least one portion of prohibited data within the blockchain transaction without being able to view or access it from the blockchain (ledger).

[0227] Clause 2.13. The method of clause 2.12, further comprising replacing the at least one portion of prohibited data with notice data that indicates that the at least one portion of prohibited data was previously and / or originally present in the portion of the transaction but is no longer visible / publicly accessible via the blockchain ledger.

[0228] Clause 2.14. The method of clause 2.13, wherein the notice data comprises at least one of a zero-knowledge proof of the at least one portion of prohibited data and prohibition data (that may be referred to as a prohibition order) that demonstrates a requirement to remove, omit, replace or obfuscate the at least one portion of prohibited data.

[0229] Clause 2.15. The method of any preceding clause, further comprising, when the at least one portion of prohibited data is contained in or referred to in a spent output of the transaction, identifying a subsequent blockchain transaction that spent the output.

[0230] Clause 2.16. The method of clause 2.15, further comprising adding to the data structure a subsequent blockchain transaction identifier that identifies the subsequent blockchain transaction as containing or referring to the at least one portion of prohibited data.

[0231] Clause 2.17. The method of any preceding clause, wherein the blockchain transaction identifier comprises a hash of at least a part of a blockchain transaction.

[0232] Clause 2.18. A computer-implemented method, comprising: identifying a blockchain transaction that comprises at least one portion of prohibited data, or a reference thereto; and adding, to a data structure, an identifier identifying the blockchain transaction.

[0233] The at least one portion of prohibited data may be deemed undesirable, or may be subject to a rule, law, policy or determined as censored or filtered.

[0234] Clause 2.19. Computer equipment, comprising: memory, comprising one or more memory units; and processing apparatus, comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured to cause the processing apparatus to perform the method of any of clauses 2.1 to 2.18.

[0235] Clause 2.20. The computer equipment of clause 2.19, wherein the code is further configured to cause the processing apparatus to propagate or relay a pending blockchain transaction responsive to a positive determination that the pending blockchain transaction does not contain at least one portion of prohibited data or a reference thereto.

[0236] Clause 2.21. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of clauses 2.1 to 2.18.

Claims

CLAIMS:

1. A computer-implemented method of transmitting data across a network from a sending resource to a receiving resource, comprising: sending a blockchain transaction (Txi) or a part thereof from the sending resource to the receiving resource; or receiving a blockchain transaction or a part thereof from the sending resource from the receiving resource; wherein: i) the blockchain transaction (Txi) or the part thereof includes at least one ZeroKnowledge Proof (ZKP) or a flag for the Zero Knowledge Proof; and ii) the at least one Zero Knowledge Proof (ZKP) can be used to verify that at least one prohibited portion of data has been omitted from the blockchain transaction or the part thereof.

2. A method according to claim 1, wherein the zero Knowledge proof (ZKP) or the flag for the Zero Knowledge Proof comprises one or more of: a hash of the at least one portion of prohibited data; a cryptographic hash of the at least one portion of prohibited data; the output of an obfuscation technique that has been applied to the at least one portion of prohibited data; the output of a masking operation that has been applied to the at least one portion of prohibited data.

3. A method according to claim 1 or 2, wherein: the Zero Knowledge Proof or the flag for the Zero Knowledge Proof is provided in the blockchain transaction or part thereof such that it replaces the at least one portion of prohibited data.

4. A method according to any preceding claim wherein: the network is a blockchain network; andthe sending resource and / or the receiving resource is a node on the blockchain network.

5. A method according to any preceding claim, wherein the part of the blockchain transaction is or comprises at least one of: an output of a blockchain transaction; an unspent output of a blockchain transaction; a script provided within, or in association with, a blockchain transaction; a portion of metadata provided within or in association with the blockchain transaction or the part thereof.

6. A method according to any preceding claim, wherein: the at least one portion of prohibited data comprises data that is specified or defined as prohibited in or by a policy, rule set, order, legal instrument, contract, instruction, license or other control resource.

7. A method according to any preceding claim, and comprising: verifying that the Zero Knowledge Proof or the flag for the Zero Knowledge Proof is a replacement of, or substitute for, the at least one portion of prohibited data in the blockchain transaction or the part thereof.

8. A method according to any preceding claim, wherein: the blockchain transaction or part thereof comprises a flag which indicates that the at least one portion of prohibited data has been replaced by the Zero Knowledge Proof.

9. A method according to any preceding claim, and comprising: using the Zero Knowledge Proof to verify that: i) a previous version of the blockchain transaction or the part thereof contained the at least one portion of prohibited data; or ii) the at least one portion of prohibited data exists.

10. A method according to any preceding claim, wherein:the Zero Knowledge Proof (ZKP) or the flag for the Zero Knowledge Proof prevents access to the at least one portion of prohibited data from the blockchain transaction or the part thereof.

11. A method according to any preceding claim, wherein the sending resource and / or the receiving resource is or comprises: i) a node on a computer-based network; and / or ii) a node on a blockchain network; and / or iii) a computing resource arranged to process blockchain transactions; and / or iv) a digital wallet.

12. A method according to any preceding claim, and further comprising: using a storage resource to store at least one of: the at least one prohibited portion of data; the Zero Knowledge Proof or the flag for the Zero Knowledge Proof; a policy, rule set, order, legal instrument, instruction, contract, license or other control resource that specifies or defines the at least one portion of prohibited data as prohibited; an identifier that associates the at least one portion of prohibited data with the Zero Knowledge Proof or the flag for the Zero Knowledge Proof.

13. A method according to any preceding claim, wherein: verification that at least one prohibited portion of data has been omitted from the blockchain transaction or the part thereof comprises verifying that the at least one portion of prohibited data is an element in a Merkle tree having a given root.

14. A computer system comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores or executes code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 13.

15. A computer system according to claim 14, wherein the system further comprises one or more of: a storage or file system; a database; a component operative to interact with a blockchain network and / or a blockchain ledger; a digital wallet, preferably wherein the digital wallet is operative to process and / or generate blockchain transactions; a software component that is arranged, when executed, to execute or implement a blockchain client.

16. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 13.

Images