Computer implementation method and system

Abstract

The embodiments provide computer implementations and systems for filtering, censoring, editing, obfuscating, or selectively pruning prohibited data in blockchain transactions or portions of blockchain transactions. Blockchain transactions or portions of blockchain transactions include zero-knowledge proofs (ZKPs / ZNPs) or ZKP flags that replace portions of prohibited data, making it impossible to access (view or download) the prohibited data in its original form from the transaction or portion thereof. While the prior existence of prohibited data in a transaction or portion thereof can be verified by the ZKP, sharing a transaction or portion thereof containing a ZKP or its flag does not distribute the prohibited data itself. In advantageous embodiments, this allows nodes on a blockchain network to transmit, consume, or otherwise process blockchain transactions or portions thereof while complying with the policies or other requirements of authorities authorized to restrict or control the distribution of prohibited data, such as corporate policies, contracts, licenses, court orders, etc.

Description

[Technical Field]

[0001] Embodiments described herein relate to improvements in access control to data stored, processed, and / or transmitted over a computing network. The embodiments are particularly suited to access control to data stored in relation to a blockchain, such as data stored in and / or referenced from blockchain transactions, as well as data shared or processed by nodes implementing and / or interacting with a blockchain network. Advantageously, the embodiments provide technical solutions for deleting, filtering, editing, or otherwise controlling data prohibited by at least one authority and shared over a blockchain network. [Background technology]

[0002] Blockchain transactions can store and share a wide range of data, not just digital assets (such as cryptocurrencies). For example, blockchain transactions can include various types of data such as tokenization schemes, non-fungible tokens (NFTs), smart contracts, supply chain management, and provenance management systems. As the number of blockchain-implementing applications increases, data of various types and purposes is being inserted into transactions and written to the blockchain ledger.

[0003] There are undoubtedly many advantages to writing data to a blockchain. For example, it provides an audit trail of data history (immutable, timestamped, and cryptographically protected). Some blockchain protocols allow the data written to the ledger to be made public, while others are private or permission-based.

[0004] Despite these advantages, as pointed out in Florian et al.'s "Erasing Data from Blockchain Nodes" (arXiv:1904.08901vl, April 18, 2019), there are situations where it is desirable to prune or exclude data provided in blockchain transactions. For example, illegal or infringing data may be written to the blockchain. Data may be included in a transaction despite a court order prohibiting the publication of a document or part of a document to protect an individual's identity. Contractual obligations, such as license agreements or confidentiality clauses, may prohibit the disclosure of the contents or parts of a document. Yet another example is when aesthetic works are subject to copyright, or when certain content violates an organization's policies. For example, historical documents may be of public interest, but may contain parts of material that could be considered offensive or illegal under current social, legal, and regulatory standards. Of course, there are many possible situations and motivations for data controllers or other parties to want to restrict the sharing of certain types or instances of data across the blockchain.

[0005] In the Bitcoin blockchain, nodes on the network have the option of pruning such transactions. 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 already been used. If the output has not yet been consumed, and the administrator does not use or cannot use it (for example, if they have lost the cryptographic key needed to sign and consume the output), simple transaction pruning is not possible.

[0006] Therefore, there is a need for improved solutions for pruning selected data portions from blockchain transactions. Embodiments of this disclosure address at least this technical problem. [Overview of the project]

[0007] Blockchain transactions are known to store and write various types of data to the blockchain. All kinds of data, including images, files, multimedia content, videos, audio, and text, can be inserted into a transaction, incorporated into a block, verified by a full node on the network, and then stored on-chain. The method of inserting data into a transaction varies depending on the protocol and the specific application, but typically the transaction output includes the data (or a reference to a location where the data can be accessed). For example, in a Bitcoin transaction output script, data may be inserted into the output after an OP_RETURN instruction, or it may be disguised as part of a cryptographic key or other script component, as disclosed in International Publication 2017 / 145004. Other data insertion techniques are also known and are included within the scope of this disclosure. Because this data is included in the transaction for application-oriented purposes, rather than for compliance with the blockchain protocol to which the transaction conforms, it is sometimes referred to as "metadata." However, metadata may contain illegal or undesirable content. For example, it may infringe on rights such as intellectual property rights or human rights, or violate policies, laws, rules, or other requirements set by certain competent authorities. These entities include legal authorities, organizations such as corporations, individuals such as employers, and statutory and customary laws. In some cases, data may be incorporated into blockchain transactions and sent to the network for verification and mining, but its prohibition may only become apparent later. As a result, transactions containing undesirable content may be propagated by nodes on the network, or the (unconsumed) output of such content may be held in the memory pool.

[0008] Embodiments disclosed herein provide methods and systems for controlling, preventing sharing, restricting access to, or selectively deleting (pruning) data of blockchain transactions or portions of blockchain transactions (e.g., scripts, outputs, etc.). In addition, or instead, such methods and systems may be described as providing recovery solutions for deleting, restricting, or selectively pruning (meta) data provided in blockchain transactions and / or portions of blockchain transactions.

[0009] In exemplary embodiments, a transaction containing a proof to replace prohibited data (e.g., a zero-knowledge proof (ZKP)) can be provided to one or more nodes in the (blockchain) network. In some embodiments, the transaction or part thereof may contain a flag that represents and / or indicates the presence of a ZKP, rather than directly including the ZKP itself within the transaction / part. A ZKP of prohibited data allows a verifier to prove that a transaction or part thereof previously contained prohibited data without revealing the prohibited data itself or its attributes.

[0010] A transaction or part containing a ZKP or ZKP flag is sent to one or more nodes on the network, replacing the original / previous version of the transaction / part containing the prohibited data. This transaction / part is sometimes called a “recovery transaction / part” because it allows the node to continue with the problematic transaction / part, excluding the prohibited portion. Thus, embodiments of this disclosure can be described in some form as a recovery method or system for blockchain implementations. In some scenarios, the replacement transaction containing proof may be sent to one or more network nodes after the original version has already been sent to the nodes.

[0011] Preferably, at least a portion of the prohibited data includes data designated or defined as prohibited by a policy, rule set, order, legal document, contract, directive, license, or other control resource. Control resources may be generated or authorized by a control entity or agency. For convenience, such control resources may be referred to as “prohibition orders.”

[0012] In some embodiments, a ZKP may be associated with or linked to a prohibition order that provides and / or confirms parameters and other data related to the prohibition. Such data may include details about the agency that issued the prohibition order, the date, the prohibited data, and / or the parties involved in the prohibition order. For example, a contract may include a confidentiality clause prohibiting the disclosure of documents. A contract is enforceable under the laws of a particular jurisdiction. A contract or a court order enforcing a contract may be provided as a prohibition order.

[0013] In one expression, the embodiment enables or facilitates data transmission over a network from a transmitting resource to at least one receiving resource. Such a method may include transmitting a blockchain transaction or a portion of a blockchain transaction from the transmitting resource to the receiving resource, to at least one node on the blockchain network. In addition, or instead, such a method may include the transmitting resource receiving a blockchain transaction or a portion of a blockchain transaction from the receiving resource, to the node on the blockchain network.

[0014] One or more requests or instructions may be sent from, or on behalf of, a sending resource to a receiving resource. The receiving resource may be a node on the blockchain network. One or more requests may request or instruct a node on the network to replace or substitute the original / previous version of a transaction / part containing prohibited data with a recovery transaction / part containing an edited version containing a ZKP in a storage facility. The node may have already received the original transaction / part from the sender or another sender.

[0015] Preferably, a blockchain transaction or part thereof includes at least one proof, such as a zero-knowledge proof (ZKP) or a zero-knowledge proof flag. The flag may include any form of code or identifier configured to indicate that a portion of data at a particular location within the transaction / part has been excluded and / or replaced. The flag may function as a signal or indicator of editing, exclusion, obfuscation, or replacement of the prohibited data portion. In some embodiments, nodes (participating resources) in the network may be configured to recognize and act accordingly with respect to one or more flags associated with a ZKP. Thus, the flags may be predetermined and coded into software and / or firmware provided for execution by the node. The node may operate or be configured to recognize and respond to the flags according to machine-executable instructions installed in the processor of the system performing this method.

[0016] In addition, or alternatively, at least one zero-knowledge proof (ZKP) may be configured to be used to verify (i.e., prove or testify) that at least one prohibited portion of the data has been excluded from the blockchain transaction or any part thereof.

[0017] Here, the term "excluded" may be interpreted as meaning "not accessible in its original and / or unmodified form."

[0018] A zero-knowledge proof (ZKP) or a flag for a zero-knowledge proof can include one, several, or all of the hash of at least a portion of the prohibited data, the encrypted hash of at least a portion of the prohibited data, the output of an obfuscation technique applied to at least a portion of the prohibited data, and the output of a masking operation applied to at least a portion of the prohibited data.

[0019] Such zero-knowledge proofs are readily understandable to those skilled in the art. In one or several embodiments, the zero-knowledge proof or the flag for the zero-knowledge proof is provided in a blockchain transaction or a part thereof and can replace at least a portion of the prohibited data.

[0020] In one or several embodiments, a part of a blockchain transaction can be, include, or contain any, some, or all of the output of the blockchain transaction, the unspent output of the blockchain transaction, a script provided within or in relation to the blockchain transaction, a part of the metadata provided within or in relation to the blockchain transaction, or a part thereof.

[0021] In one or several embodiments, at least a portion of the prohibited data can include data that is specified or defined as prohibited by a policy, a rule set, an instruction, a legal document, a contract, a directive, a license, or other control resources.

[0022] In one or several embodiments, the method of the present disclosure can include the step of verifying (proving) that a zero-knowledge proof or a flag for a zero-knowledge proof is a substitute or alternative for at least a portion or a part of the prohibited data within a blockchain transaction. [[ID=e20]]

[0023] In one or more embodiments, a blockchain transaction or a portion thereof may include a flag indicating that at least a portion of the prohibited data has been replaced by a zero-knowledge proof.

[0024] In one or more embodiments, the method of the present disclosure may include a step of using a zero-knowledge proof to verify (prove) that a previous (e.g., original, first, or earlier) version or part of a blockchain transaction contained at least a portion of prohibited data.

[0025] A previous version may be an earlier version of the transaction or part thereof that contained the prohibited data. In one or more embodiments, a zero-knowledge proof (ZKP) or a zero-knowledge proof flag can prevent access to at least part of the prohibited data from a blockchain transaction or part thereof. "Access" includes at least "viewing," "sharing," "downloading," "writing or overwriting," "editing," "presenting," "displaying," or other actions.

[0026] In one or more embodiments, the sending and / or receiving resources may be at least one of i) a node on a computer-based network, and / or ii) a node on a blockchain network, and / or iii) computing resources configured to process blockchain transactions, and / or iv) a digital wallet, or may include these.

[0027] In one or more embodiments, the method of the Disclosure may include using a storage resource to store at least one of the following: at least one prohibited portion of data, a zero-knowledge proof or zero-knowledge proof flag, a policy, rule set, order, legal document, instruction, contract, license or other control resource that designates or defines at least a portion of the prohibited data as prohibited, or an identifier that associates at least a portion of the prohibited data with a zero-knowledge proof or zero-knowledge proof flag.

[0028] In one or more embodiments, verification that at least one prohibited portion of data is excluded from a blockchain transaction or any part thereof includes verifying that at least one portion of the prohibited data is an element of a Merkle tree having a predetermined root. This verification step can be performed substantially in accordance with the technology and systems disclosed and claimed in the applicant's pending UK patent application GB2303996.9 filed on March 20, 2023, and all patent applications claiming priority thereunder. UK patent application GB2303996.9 and all applications claiming priority thereunder are incorporated herein in their entirety. In some embodiments, storage resources may include virtual or physical storage resources, at least one cloud-based storage resource, at least one distributed hash table (DHT), at least one database, at least one distributed, centralized, or decentralized storage resource, spreadsheets, and a file system configured to store, index, and / or retrieve data records. To aid in understanding embodiments of this disclosure and to illustrate how such embodiments are carried out, the accompanying drawings are referenced as examples. [Brief explanation of the drawing]

[0029] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2]This diagram schematically illustrates some examples of transactions that may be recorded on the blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A is a schematic mockup of an exemplary user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of several node software programs for processing transactions. [Figure 5] This is a sequence diagram illustrating communication between a requester and a node according to an exemplary embodiment of the present disclosure. [Figure 6] This is a sequence diagram illustrating communication between a requester, a node, and a server, according to an exemplary embodiment of the present disclosure. [Figure 7] This is a flowchart illustrating the steps of a method according to an exemplary embodiment of the present disclosure. [Figure 8] This is a flowchart illustrating the steps of another method according to an exemplary embodiment of the present disclosure. [Figure 9] This is a schematic diagram of a transaction to which the methods disclosed herein apply. [Figure 10] This is a schematic diagram of two transactions that may be subject to the methods disclosed herein. [Figure 11] This figure shows data structures that may be created, modified, or used by the methods disclosed herein. [Figure 12] This is a flowchart illustrating the steps of a method according to an exemplary embodiment of the present disclosure. [Modes for carrying out the invention]

[0030] As mentioned earlier, data included in blockchain transactions may need to be deleted or otherwise processed to prevent one or more parties from accessing the blockchain without specific permission. This is particularly important in public blockchains, but also applies to private and permissioned blockchains. "Access" refers to viewing, accessing, and downloading data from the blockchain. Such data may be called "prohibited data" because it is deemed undesirable, harmful, unauthorized, or illegal by one or more authorities.

[0031] Sharing prohibited data may infringe on intellectual property rights and other rights. For example, prohibited data may contain copyrighted material or subject matter, or infringe on design rights. It may also violate confidentiality restrictions imposed by contract or statutory law. From a legal standpoint, prohibited data may be subject to injunctions, provisional injunctions, or court orders prohibiting publication.

[0032] In some cases, prohibited data may be part of larger data. This part and larger portion of data is sometimes called metadata because it is data inserted into a transaction (Tx0) for application-level purposes, not because it is required by the blockchain protocol on which the transaction is formed.

[0033] In one or more examples, prohibited data may be sensitive in some way, such as data relating to an individual's medical history, national security, or commercial advantage (e.g., trade secrets). In other examples, prohibited data may include illegal or unlawful data that is contrary to the laws of a particular state or jurisdiction. Essentially, prohibited data may be data that is subject to restrictions and control by a particular agency relating to a particular context or application. The term “agency” may include any entity that has jurisdiction, governance, control, and / or authority over prohibited data. An agency may have the right to enforce sanctions or consequences arising from prohibited activities relating to prohibited data, or to initiate such enforcement by or through another party.

[0034] An institution can consist of individual entities (for example, natural persons or legal entities, or machine-based resources such as algorithms running on hardware) or groups of such entities. For example, an institution may be, or be composed of, organizations such as governments, legal or unincorporated organizations, legal or judicial bodies such as courts and law enforcement agencies, or regulatory bodies. Another example is when an institution determines, manages, or at least influences the implementation or design of blockchain protocols and related technologies. In some situations, multiple institutions may be involved with respect to the data written to the blockchain.

[0035] In some cases, a blockchain may not be a public blockchain but a private or authorized blockchain, and may be designated or implemented by a specific controlling entity that acts as an authority over the users of the blockchain.

[0036] Use case: 1. As mentioned above, there are times when it is necessary to exclude unwanted material from blockchain transactions (or at least make it inaccessible in its identifiable original form). However, it is possible for the transaction / part of the transaction containing that data to be shared or processed by nodes on the network. Even if data sharing is prohibited, it is necessary that the transaction or part of the transaction containing that data be shared or processed by nodes on the network.

[0037] Consider a scenario where metadata is provided as part of a blockchain transaction (Tx0), sent to the blockchain network, verified and mined by full nodes, and then reflected in the blockchain ledger. In some embodiments, this involves storing data in a network resource configured to hold data related to unconfirmed blockchain transactions that have not yet been included in a block. In some (but not all) embodiments, this involves an ordered set or pool 154, as mentioned in the "System Overview Example" section below.

[0038] Suppose, after a transaction has been sent to the network, it is discovered or determined that at least part of the metadata violates a rule or instruction contained in the prohibition order. An example of this use case would be when a judge orders that the identity of a particular individual not be revealed, and the metadata includes documents, text, images, etc., that could potentially identify that individual, such as a name, address, or social security number.

[0039] In response, a subsequent (recovery) transaction (Tx1) or its associated portion may request a node on the network to replace the stored copy of the original transaction or its associated portion (Tx0) with the pruned transaction or its associated portion (Tx1), and may be sent to the blockchain network. The recovery transaction or portion of the recovery transaction replaces the prohibited data with a ZKP, or a flag indicating that the prohibited data has been deleted but is verifiable via the ZKP. The recovery transaction or its associated portion may be generated by a sending resource and sent to a network node.

[0040] In some embodiments, a receiving node on the network already possesses a copy of the original version of the transaction or a portion thereof (Tx0), and can use a ZKP and / or a flag pointing to it to prove that the content of the recovery transaction or a portion thereof (Tx1) is the same as the original transaction (Tx0), but with certain parts excluded, and that the sender of the recovery transaction / part thereof holds the original excluded data. This verification is performed by proving only that the prohibited data exists and that the sender can prove it, without providing any knowledge of the prohibited data itself. The receiving node can identify the relevant transaction (Tx0) or a portion thereof by an identifier that uniquely identifies it. This identifier may include one or more of the following: the block header of the blockchain block containing the transaction, a blockchain transaction identifier (TxID) known in the art, an input identifier and / or an output identifier, or a user-specified identifier that is not required by the blockchain protocol but is associated with or provided within the transaction or a portion thereof.

[0041] In other embodiments, the receiving node may not have a copy of the original transaction (Tx0) stored beforehand. The sending node can instruct the receiving node to monitor incoming traffic on the network and, if it detects a transaction with a unique identifier specified by the sender, replace the pruned version (Tx1) with the detected version.

[0042] In some cases, one or more receiving nodes may examine prohibition orders and other evidence to verify that the exclusion of data is approved and justified. Prohibition orders are provided on the blockchain or on offline storage resources, from which receiving nodes can access them. In some examples, prohibition orders may be provided within or associated with a recovery transaction or a part thereof. For example, a prohibition order or a pointer to it may be provided as metadata within the output script of a recovery transaction (Tx1).

[0043] Once a node positively confirms that the prohibited data has been legitimately deleted (i.e., the ZKP validation of the prohibited data is successful), the node can replace the stored version or the discovered version or part thereof of the transaction (Tx0) with the recovery transaction (Tx1) or part thereof.

[0044] Thus, embodiments of the present invention provide a mechanism for censoring, filtering, editing, and / or updating (meta)data transmitted to one or more nodes on a blockchain network.

[0045] Example of Use: 2 Herein, with particular reference to Figures 5-12 and the set of clauses listed below, we provide illustrations of one possible embodiment of the present disclosure in use.

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

[0047] Requester 602 may include a computer device or system such as a telephone, tablet, laptop, or personal computer. Requester 602 may be a user instructing a computer device to communicate with node 604, or it may be a computer-based resource such as hardware and firmware configured to execute code that operates to perform steps according to the embodiments disclosed herein. Thus, the computing resource can automate communication with node 604. In any case, in such embodiments, node 604 receives request 606 originating from requester 602.

[0048] In this embodiment, request 606 relates to one or more blockchain transactions (hereinafter, for convenience, may be simply referred to as "transactions"). In other embodiments, request 606 may relate to one or more parts of a transaction, or data constituting said one or more parts. For example, request 606 may relate to any data in the output fields of a particular transaction, such as data in unconsumed transaction outputs included in that particular transaction. Transactions containing the requested transaction may be stored in node 604.

[0049] In response to receiving request 606, node 604 determines whether the transaction (or part thereof) requested by requester 602 contains data that is considered prohibited. In this embodiment, a data structure (for example, data structure 1300, see Figure 11) stores an identifier (for example, identifier 1302) that identifies which transaction contains data that is considered prohibited. An example of such a data structure is shown in Figure 11 and will be described in detail later.

[0050] An identifier consists of one or more of the following elements: • Transaction header data • Data relating to part or all of a blockchain block • Transaction ID (TxID) or TxID field, known in the field of blockchain technology • At least one part of the data that is typically provided in relation to a transaction specified by the blockchain protocol used in a particular implementation, or as a required or optional feature of the transaction • Or one or more hashes of the above.

[0051] An identifier is any data that can identify a particular transaction. Identifiers can consist of any form of appropriate flag or identification mechanism, such as the Transaction Identifier (TxID) known in the field of blockchain technology.

[0052] Node 604 queries a data structure (e.g., data structure 1300) to determine whether the requested transaction (or part thereof) has a corresponding identifier (e.g., identifier 1302) present in the data structure. If the identifier exists in the data structure, it indicates that the requested transaction contains at least prohibited data (e.g., prohibited data 1304). In embodiments, this query includes a determination that Node 604 is also seeking proof (e.g., proof 1306) that the requested transaction contains at least some prohibited data. In embodiments, this query includes an instruction that Node 604 is seeking empirical data (e.g., empirical data 1308) that shows a record of a request or requirement that the sharing, publication, provision, propagation, etc., of data is restricted, controlled, or prohibited in some way, regardless of how it is registered, recorded, or represented in the data structure.

[0053] Node 604, after determining that the requested transaction contains prohibited data, responds to request 606 by providing requestor 602 with the requested transaction, or the requested portion thereof (excluding at least some of the prohibited data identified by referencing the data structure). The returned transaction 610 is sometimes called the edited transaction.

[0054] Referring to Figure 7, an embodiment is shown in the form of a series of computer implementation method steps 800. This method 800 is shown to include steps performed on a node, such as node 604. In S802, the node receives a request for a blockchain transaction or a portion thereof. This request may come from a requester, such as requester 602. In S804, the node determines from the request an identifier that identifies the requested transaction. In S806, the node determines whether the identifier identified by the node from the request exists in a data structure stored in or accessible by the node, i.e., whether the presence of the identifier in the data structure indicates that the transaction contains at least a portion of prohibited data.

[0055] In D808, the node checks and determines whether the requested transaction contains at least some of the prohibited data, based on the presence or absence of identifiers in the data structure. If the determination is negative, i.e., the requested transaction does not contain any prohibited data, the node proceeds to S810 and provides the requested transaction.

[0056] On the other hand, if the determination result is positive (i.e., the requested transaction contains at least some of the prohibited data), the node proceeds to S812 and provides the requested transaction with the prohibited data removed. In other words, the node provides the requester with an edited version of the transaction. In an alternative embodiment, the node may completely refuse or decline to provide the requested transaction.

[0057] Referring to Figure 6, in another embodiment, when node 704 receives a transaction request 706 from requester 702, it queries the data structure by sending message 708A to server 712 which hosts or has access to the data structure (for example, data structure 1300). Server 712 searches the data structure for the requested transaction, determines whether the data structure identifies that the requested transaction contains at least some prohibited data, and sends a reply message 708B to node 704 informing it whether the requested transaction contains prohibited data.

[0058] Queries from node 704 to server 712 may include indications that node 704 is also seeking proof (e.g., proof 1306) that the requested transaction actually contains undesirable material, and queries may also include indications that node 704 is seeking demonstrative data (e.g., demonstrative data 1308) that demonstrates a requirement or demand that the data is prohibited and its sharing, publication, provision, propagation, etc., is restricted in some way, regardless of how it is registered, recorded, or represented in the data structure.

[0059] Node 704, after determining that the requested transaction contains prohibited data, responds to request 706 by providing requestor 702 with the requested transaction, or a portion thereof (excluding the prohibited data identified by server 712 by referring to the data structure). The returned transaction 710 can be described as an edited transaction.

[0060] Referring to Figure 8, the embodiment is shown in the form of a series of computer implementation method steps 900. This method 900 is shown to include steps performed on a node, such as node 704. In S902, the node receives a request for a transaction or a part thereof. This request may come from a requester, such as requester 702. In S904, the node determines from the request an identifier that identifies the requested transaction. In S906, the node instructs a server (such as server 712) to determine whether the identifier identified by the node from the request exists in a data structure accessible to the server, and whether the data structure associates that identifier with at least a part of the prohibited data. In S907, the node receives an acknowledgment or denial from the server. This response may be an acknowledgment or a denial and may include additional information other than an acknowledgment or denial, such as information stored in relation to the identifier in the data structure.

[0061] In D908, the node examines the response from the server and determines whether the response contains a positive instruction. A positive instruction indicates that the identifier exists in the data structure, thereby indicating that the requested transaction contains at least some of the prohibited data. If the determination is negative, i.e., that the identifier does not exist in the data structure and therefore the requested transaction does not contain any prohibited data, the node proceeds to S910 and provides the requested transaction.

[0062] If the determination is positive, i.e., if the requested transaction contains at least some of the prohibited data, the node proceeds to S912 and provides the requested transaction with at least some of the prohibited data removed. In other words, the node provides the requester with an edited transaction. In an alternative embodiment, the node may refuse to provide the requested transaction at all.

[0063] Referring to Figure 9, a schematic diagram of transaction 1000 is shown illustrating a transaction that may be requested, provided, stored, edited, and / or rejected according to other embodiments described herein.

[0064] Transaction 1000 has a header containing transaction ID (TxID0) 1002. Transaction 1000 has an input field 1004 and an output field 1006. The input field includes a first input 1008 containing a pointer to the previous transaction, an index of the previous transaction's (previous) unspent transaction output (UTXO), and an unlock script for unlocking the UTXO. Transaction 1000 is shown for illustrative purposes, but transactions with alternative structures and fields, and formed according to any appropriate blockchain protocol, are equally possible. The output field includes a first output 1010 containing an amount (in this embodiment, the amount of the digital asset), a lock script that locks control of the digital asset to a subsequent transaction using an appropriate unlock script, and data such as a URL or file path, or a reference, link, or instruction to data. In this embodiment, the data is prohibited data 1012. In this embodiment, there may be further inputs 1014 and further outputs 1016.

[0065] Transaction 1000 may be stored as part of the blockchain in nodes such as node 604 and node 704. Upon receiving a request for transaction 1000, node 604 or server 712 searches the data structure for an identifier that indicates transaction 1000 may contain at least some of the prohibited data (in this case, prohibited data 1012). In doing so, node 604 or server 712 searches the data structure using the TxID (in this case, TxID01002). If node 604 or server 712 finds TxID01002 in the data structure, node 604 or server 704 considers this a positive determination that transaction 1000 contains at least some of the prohibited data.

[0066] Referring to Figure 10, schematic diagrams of two transactions 1100 and 1200 are shown, illustrating transactions that may be requested, provided, stored, edited, and / or rejected according to other embodiments described herein. Transaction 1100 has a header containing transaction ID (TxID1) 1102. Transaction 1100 has an input field 1104 and an output field 1106. The input field contains a first input 1108 containing a pointer to the previous transaction, an index of the (previously) unconsumed transaction outputs (UTXOs) of the previous transaction, and an unlock script for unlocking the UTXOs. The output field contains a first output 1110 containing an amount (e.g., the amount of a digital asset) and an unlock script that locks control of the amount to a subsequent transaction (in this case, transaction 1200) that has the appropriate unlock script. Transaction 1100 is stored on the blockchain.

[0067] Transaction 1200 has a header containing transaction ID (TxID2) 1202. Transaction 1200 has an input field 1204 and an output field 1206. The input field contains a first input 1208 which includes a pointer to transaction 1100, an index of the unconsumed transaction output UTXO 11110 of transaction 1100, and an unlock script to release the lock on UTXO 11110. The output field contains a first output 1210 which includes an amount (in this embodiment, the amount of a digital asset), an unlock script which locks control of the amount to subsequent transactions by an appropriate unlock script, and material data, or a reference, link, or instruction to material data. In this embodiment, the data is prohibited data 1212.

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

[0069] In the embodiment, transactions 1100 and 1200 may include further inputs 1114 and 1214, and further outputs 1116 and 1216, respectively.

[0070] In Figure 10, transaction 1200 is not stored on the blockchain but is being sent for addition to the blockchain. Therefore, transaction 1200 is stored in a queue or hold area 520 for the verification and / or validation procedures required by the blockchain protocol in use. In some embodiments, the hold area 520 may be a memory pool, but not in all embodiments. Transaction 1200 may be stored in memory on a node such as node 604 or node 704.

[0071] Node 604 or Server 712, upon receiving a request for transaction 1200, a request to send transaction 1200 to the blockchain, or a request to propagate, share, or make transaction 1200 public, may use the TxID (in this case, TxID01202) to search the data structure if it is looking for an identifier that indicates transaction 1200 may contain prohibited data (in this case, prohibited data 1212). If Node 604 or Server 712 finds TxID01202 within the data structure, Node 604 or Server 712 considers this a positive determination that transaction 1200 contains at least some of the prohibited data.

[0072] Referring to Figure 11, a data structure 1300 is shown, which can be used in combination with the embodiments described herein and is shown in array form. The data structure 1300 includes a plurality of identifiers that identify a transaction. In one embodiment, the identifier is the transaction ID "TxID" i This is 1302. The data structure 1300 associates an identifier with something that has been determined or designated as prohibited data 1304 (by at least one authority). In one embodiment, each piece of data 1304 associated with each transaction identified by the identifier is stored in the data structure. In another embodiment, one or more hashes of such prohibited data are stored instead. In one embodiment, proof of what the prohibited data is and / or proof that the associated transaction contains that prohibited data is stored along with the identifier.

[0073] In one embodiment, the proof includes a zero-knowledge proof (ZKP) 1306. In one embodiment, a prohibition order 1308 is stored along with an identifier. A prohibition order, as here, includes data and / or instructions indicating an intention, purpose, request, instruction, or similar instruction that prohibited data is undesirable or not permitted for any reason and must not be distributed, disclosed, shared, or propagated. For this purpose, “prohibition order” is also referred to herein as “empirical data.” In embodiments, a prohibition order may include a court order prohibiting the sharing, distribution, etc. of material, an agreement that sets out restrictions on the sharing, distribution, etc. of prohibited data, and / or a policy that sets out restrictions on data. In other cases, prohibited data may be prohibited by some law, rule, or policy. This rule, law, or policy may be designated by at least one body, such as a court, or by an organization, such as a company or association, a public body, or a regulatory body.

[0074] The following describes examples of transaction identifiers and embodiments including the data stored in association with those identifiers. In these exemplary embodiments, the identifiers may be transaction identifiers required as characteristics defined by the blockchain protocol in which the transaction is formed. In conventional terminology, such blockchain transaction identifiers are sometimes called TxIDs.

[0075] Assume that, according to one of the embodiments described above, it has been determined that the transaction identified by the transaction identifier TxID0 contains prohibited data. In one embodiment, the data structure 1300 includes one or more records. Each record consists of a transaction ID TxID0 and an associated set of fields 1310 containing the following information:

[0076] • The hash of the prohibited data portion included in the transaction (data structure 1300 can also store the prohibited data itself, but hashing the data may be advantageous, for example, when storage space is limited, or when the prohibited data is so private, confidential, or secret that it needs to be stored in an unreadable format). A zero-knowledge proof that the transaction identified by TxID0 contains forbidden data that is hashed into the aforementioned hash. A court order stipulating that data included in a transaction is prohibited from being shared, disclosed, provided, or propagated under any circumstances. Note that in this example, the prohibited data may be prohibited data 1012, as shown in transaction 1002 in Figure 9.

[0077] Assume that the transaction identified by the transaction identifier TxID2 is determined to contain at least some prohibited data. Data structure 1300 contains the transaction ID TxID2 and an associated fieldset 1312 containing the following information: the image file "IMG_001.png" designated as prohibited data to be stored in the transaction (for example, prohibited data 1212 for the transaction shown in Figure 10), a zero-knowledge proof that the transaction identified by TxID2 contains the image file, and the contract specifying that the image file contained in the transaction is prohibited data and that sharing it would be a breach of contract (for example, if the image file infringes the copyright of the image, or if the publication of the image goes against the intentions of the creator as defined in the contract).

[0078] Transaction Identifier (TxID) A Assume that the transaction identified by is determined to contain at least some of the prohibited data. Data structure 1300 contains the transaction ID TxID AThe following fieldset 1314 is included: Username and password pairs designated as prohibited data and stored in the transaction, TxID A This is a zero-knowledge proof that a transaction identified by contains a username and password, and a policy that stipulates that disclosing this username and / or password violates the requirements of the company or institution to which the policy is associated.

[0079] Transaction Identifier (TxID) B Assume that the transaction identified by is determined to contain at least some of the prohibited data. Data structure 1300 contains the transaction ID TxID B This includes a related fieldsset 1316 containing the following information: the URL of the website where prohibited data may be found or accessed, and the TxID. B This is a zero-knowledge proof that the transaction identified by facilitates access to the material via a URL, and a court order that stipulates that the prohibited data led to by the URL contained in the transaction is prohibited data that must not be shared, disclosed, provided, propagated, etc., under any circumstances.

[0080] Referring to Figure 12, an embodiment is shown in the form of a computer implementation method step 1400. In this embodiment, a data structure such as data structure 1300 is modified, or a transaction identifier is entered which is deemed to contain prohibited data or links, addresses, or instructions thereto.

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

[0082] In step S1404, the computer device stores the identifier of a transaction in a data structure to indicate its association with the transaction that stores the prohibited data. This retrieval may include receiving the identifier as part of an identification request.

[0083] In step D1406, the computer device checks the data structure to determine if the identifier already exists. If the identifier does not exist, the computer device proceeds to step S1408 to add the identifier to the data structure or requests the data structure's control entity, such as server 712, to add the identifier to the data structure. The computer device may also add or request additional information about the transaction or prohibited data, such as proof data or demonstrative data received as part of the identification request. If the identifier already exists, the computer device proceeds to step S1410 and may discard the acquired identifier without performing any further substantial action. In this way, a data structure containing the information necessary to identify transactions that contain or are directed to prohibited data is generated, modified, and / or entered.

[0084] System Overview Example In this specification, the term “node” means (but is not limited to) a complete node on a blockchain network, unless it is determined to have a different meaning in the context understood by those skilled in the art, or unless it is specifically defined otherwise in the text of this specification.

[0085] Furthermore, for convenience and because it is the most widely known of the technologies in question, this specification may refer to the Bitcoin protocol / network / ledger. However, this disclosure is not limited to use with Bitcoin, and other ledger-based protocols / networks are also included in the scope of this disclosure. "Bitcoin" is not limited to any specific Bitcoin-related protocol, and any protocol or implementation derived from, derived from, or deviating from the original Bitcoin protocol is also included in the scope of this disclosure. In this document, the terms "Bitcoin" and "blockchain" are used interchangeably.

[0086] With reference to Figures 1 to 4, various examples of computing systems that can be used to carry out the embodiments disclosed herein are provided, for illustrative purposes only and without limitation.

[0087] A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0088] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0089] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit 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 to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0090] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0091] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0092] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0093] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0094] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as 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, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0095] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0096] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0097] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

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

[0099] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0100] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0101] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0102] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, 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 include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0103] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and 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 removable optical drive.

[0104] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0105] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0106] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on the blockchain 150, since the blockchain 150 is a public body that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate it throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0107] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0108] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0109] UTXO base model Some blockchain protocols are designed using a "UTXO-based" model. This specification provides information on such approaches. However, this is merely an example of an implementation environment to which this disclosure may apply, and is not limited thereto. Other protocol models can also be used for this purpose, and embodiments are not specifically and definitively limited to implementations using UTXO-based blockchains or related protocols.

[0110] Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0111] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0112] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0113] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0114] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0115] The lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A particular example of such a language is what is called "Script" (with a capital S) used by the blockchain network. The lock script specifies what information is required to spend the transaction output 203, for example, specifying the requirements for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information required to meet the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0116] Thus, in the example shown, the UTXO0 in the output 203 of Tx0 has the lock script [Checksig P A , which requires Alice's signature Sig P A for the UTXO0 to be redeemed (strictly speaking, for a subsequent transaction attempting to redeem the UTXO0 to be valid). [Checksig P A includes the representation (i.e., the hash) of the public key P A from Alice's public key - private key pair. The input 202 of Tx1 has a pointer indicating Tx1 (e.g., indicated by the transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 has an index identifying UTXO0 within Tx^{0} to identify UTXO0 from among any other possible outputs of Tx0. The input 202 of Tx1 further has the unlock script <Sig P A> comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0117] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0118] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

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

[0120] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0121] As shown in Figure 1, the client applications on Alice and Bob's computer equipment 102a and 120b may each have additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the direction of either party or a third party). Side channel 107 enables the exchange of data independently of the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this communication may be used to exchange transaction 152 between Alice and Bob. The transaction has not (yet) been registered on the blockchain network 106 and has not been sent to chain 150. This communication continues until one of the parties chooses to broadcast it to network 106. Sharing a transaction in this way is sometimes called sharing a “transaction template.” A transaction template may be missing one or more inputs and / or outputs necessary to form a complete transaction. Alternatively or additionally, side channel 107 can be used to exchange other transaction-related data such as keys, negotiated amounts or terms, and data content.

[0122] Side channel 107 can be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, side channel 301 can be established via another network such as a mobile cellular network, a local area network (such as a local wireless network), or a direct wired or wireless link between Alice and Bob's devices 102a and 102b. Generally, as referred to herein, side channel 107 consists of one or more links via one or more network technologies or communication media for exchanging data "off-chain," separate from the blockchain network 106. When multiple links are used, the entire bundle or collection of off-chain links may be referred to as side channel 107. Therefore, it should be noted that when Alice and Bob exchange certain information or data etc. via side channel 107, this does not necessarily mean that all of this data must be transmitted via the exact same link or the same type of network.

[0123] Client software Figure 3A shows an example implementation of a client application 105 for implementing an embodiment of the method of this disclosure. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement transaction-related functions of the client 105, such as creating transaction 152, receiving and / or sending transactions and other data via side channels 301, and / or sending transactions to one or more nodes 104 propagated through the blockchain network 106, in accordance with the method described above and schemes to be described in more detail later. According to embodiments disclosed herein, the transaction engine 401 of each client 105 comprises a function 403 for sending a request for a transaction to one or more nodes 104 and / or propagating the transaction, and if a node determines that the requested transaction contains or contains references to material that is considered undesirable, it receives the transaction or an edited transaction. Details of determination and editing are described in the following embodiments.

[0124] The UI layer 402 is configured to render a user interface via user input / output (I / O) means of each user's computer equipment 102, and includes outputting information to each user 103 via user output means of equipment 102, and receiving input from each user 103 via user input means of equipment 102. For example, user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. User input means may include, for example, an input array of one or more touchscreens (same or different as those used for output means); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or speech recognition algorithms for receiving audio or voice input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, joysticks, etc.

[0125] Note: While this specification describes various functions as being integrated into a single client application 105, this is not necessarily limiting, and they could be implemented as a suite of two or more different applications, for example, one as a plug-in to the other, or interfaced via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a particular module, such as the transaction engine 401, may be divided among multiple applications. Furthermore, it is not excluded that some or all of the functions described herein may be implemented, for example, in the operating system layer. Where a single or specific application 105, etc., is referred to herein, this is merely illustrative, and more generally, it should be understood that the functions described herein can be implemented in any form of software.

[0126] Figure 3B shows a mockup of UI 500 that can be rendered by the UI (User Interface) layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI can be rendered by client 105b on Bob's device 102b, or by any other client. Figure 3B shows UI 500 from Alice's perspective as an example. UI 500 may consist of one or more UI elements 501, 502, 502 which are rendered as separate UI elements by a user output means.

[0127] For example, a UI element may include one or more user-selectable elements 501, such as different buttons on the screen or different options in a menu. User input means are configured to allow user 103 (in this case, Alice 103a) to select or act on one of the options by clicking or touching a UI element on the screen or by speaking the name of the desired option (the term "manual" as used herein is in contrast to "automatic" and is not necessarily limited to the use of hands). These options allow the user (Alice) to create a transaction 152 and send it to one or more nodes 104 for propagation through the blockchain network 106.

[0128] Alternatively or additionally, a UI element may include one or more data input fields 502 for user use. These data input fields may be rendered via user output means (e.g., on a screen), and data may be entered into the fields via user input means (e.g., a keyboard or touchscreen). Alternatively, data may be received verbally, for example, based on speech recognition.

[0129] Alternatively or additionally, a UI element may include one or more information element outputs to provide information to the user. For example, this information may be displayed on screen or audibly.

[0130] Please understand that the specific methods for rendering various UI elements, selecting options, and inputting data are not important. The functions of these UI elements will be explained in detail later. Also, UI500 shown in Figure 3 is a schematic mockup and may actually contain one or more UI elements, but these are not shown for the sake of simplicity.

[0131] Node software Figure 4 shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO-based or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes one or more of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The consensus module 455C may include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may be configured separately from the consensus module 455C. One or more modules may operate in parallel. Node 104 may include additional modules. The protocol engine 401 is typically configured to recognize different fields of transaction 152 and process them according to the node protocol. m-1 Transaction 152j(Tx) has inputs that point to the output (e.g., UTXO) of ). j When it receives ), protocol engine 451 sends Tx j Identify the unlock script within and pass it to script engine 452. Protocol engine 451 also handles Tx j Tx based on the pointer in the input i Identify and retrieve Tx i It may be publicly available on blockchain 150, in which case the protocol engine will take the transaction from a copy of block 151 of blockchain 150 stored on node 104. iYou can obtain it. Alternatively, Tx i It is possible that the transaction has not yet been published to blockchain 150. In that case, the protocol engine 451 will take the transaction from the ordered set of unpublished transactions 154 managed by node 104. i It is possible to obtain the Tx. In either case, the protocol engine 451 will obtain the referenced Tx i Identify the lock script from the output and pass it to script engine 452.

[0132] In this way, script engine 452, Tx i The lock script and the corresponding Tx j The unlock script is obtained from the input. For example, Figure 2 shows transactions labeled Tx0 and Tx1, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together as described above, which involves placing data on the stack 453 and retrieving data from the stack 453, according to the stack-based scripting language being used (e.g., Script).

[0133] The script engine 452 executes these scripts simultaneously to determine whether the unlock script meets one or more criteria defined in the lock script; that is, whether to "unlock" the output containing the lock script. The script engine 452 returns this determination result to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns a result of "true". Otherwise, it returns a result of "false".

[0134] In an output-based model, the output "true" from script engine 452 is one of the conditions for transaction validity. Typically, one or more protocol-level conditions, evaluated by protocol engine 451, must also be met. For example, Tx j The total value of the digital assets specified in the output does not exceed the total value indicated by its input, and Tx i This includes ensuring that the output has not already been consumed by another valid transaction. The protocol engine 451 evaluates the output from the script engine 452 and one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j The protocol engine 451 outputs an instruction to the application-level decision engine 454 indicating whether the transaction is valid. j Only if it is actually verified, the decision engine 454 controls both the consensus module 455C and the propagation module 455P, and Tx j Each blockchain-related function can be executed in relation to this. This means that the consensus module 455C can perform Tx j Adding the ordered transaction set 154 of each node and incorporating it into block 151, and the propagation module 455P Tx j This includes transferring the transaction to another blockchain node 104 within the network 106. Optionally, in the embodiment, an application-level decision engine 454 may apply one or more additional conditions before triggering any or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees remain.

[0135] Furthermore, the terms "true" and "false" here are not necessarily limited to returning a result represented by a single binary number (bit), but are merely one implementation example. More generally, "true" refers to any state indicating success or a positive outcome, and "false" refers to any state indicating failure or a negative outcome. For example, in an account-based model, a "true" result could be indicated by a combination of implicit protocol-level verification of the signature and a positive output from the smart contract (the overall result is considered true if both individual results are true).

[0136] Some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0137] In some embodiments of this disclosure, the blockchain network 106 may be a Bitcoin network, and node 104 performs at least some or all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the Bitcoin network 106).

[0138] In some embodiments, the blockchain network 106 does not have to 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 more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0139] More generally, any reference to the term “node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104 implementing any particular model of the blockchain protocol.

[0140] In this specification, references to "cryptocurrency" may be replaced with "blockchain assets" or "native blockchain tokens." Similarly, references to specific blockchain protocols, such as Bitcoin, may be replaced with "blockchain" or "blockchain protocol."

[0141] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0142] It will be understood that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, or programs are provided that conform to one or more of the following enumerated clauses.

[0143] Listed Clauses: The following sets of clauses define embodiments disclosed herein, for illustrative purposes only. These sets of clauses are not mutually exclusive, and features described in one clause or set of clauses may be incorporated and combined with other features in one or more other clauses or sets of clauses.

[0144] In one expression, embodiments of this disclosure can provide computer implementation methods and systems that can enable and / or facilitate filtering, censorship, editing, obfuscation, or selective pruning of data within or in part of a blockchain transaction. Transactional parts include, for example, output, scripts, parts of metadata, and block headers. A transaction, or a transaction containing a transactional part, can be provided within or associated with a blockchain block formed according to a given blockchain protocol. The blockchain protocol can be any suitable blockchain protocol, such as the Bitcoin protocol or its derivatives, the Ethereum protocol, or other alternative blockchain protocols.

[0145] The data may be prioritized as prohibited data. Therefore, the transaction and / or part of it may have been sent to at least one full node (mining node) on the blockchain network. It may have been incorporated into a block and written to the blockchain ledger. 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 be part of an unconfirmed set of transactions. It may be part of a memory pool.

[0146] Preferably, a blockchain transaction or part of a blockchain transaction includes a zero-knowledge proof (ZKP / ZNP) or a ZKP flag. Preferably, the ZKP or flag replaces (acts as a substitute or marker positioning) at least a portion of the prohibited data. This may mean that at least a portion of the prohibited data was provided (i.e., indicates or allows interpretation of) a previous (e.g., original) version or form of the transaction or part of it. Preferably, by replacing at least a portion of the prohibited data with a ZKP / flag, the portion of the prohibited data becomes inaccessible from the original form of the transaction or part of it. This may mean that a third party (such as a recipient or other processor of the blockchain transaction / part of it) cannot view, download, or otherwise process at least a portion of the prohibited data.

[0147] The embodiment may include the step of replacing at least a portion of prohibited data with at least one ZKP in a blockchain transaction or a portion thereof.

[0148] Preferably, a ZKP can be used to verify the prior existence of prohibited data in a transaction or a portion thereof without sharing or distributing the prohibited data itself. The ZKP proves the existence of at least a portion of the prohibited data without revealing what that portion of the prohibited data is or any other information relating to it. In a favorable embodiment, this allows nodes on a blockchain network to transmit or use a blockchain transaction or a portion thereof while complying with the policies or other requirements of an authority that has the power to restrict or control the distribution of prohibited data (e.g., corporate policies, contracts, licenses, court orders, etc.).

[0149] Prohibited data consists of digital data in any form or format and may be placed for any purpose. In other words, prohibited data may also be referred to as “(unwanted) information / content / material.” This includes, for example, multimedia / video / audio content, machine-readable or executable code, text, still or animated images, database or spreadsheet contents, raw data, etc. The terms “reference,” “instruction” as used herein include any information or data that instructs a user where and / or how to access prohibited data information, or provides a means for a user to access prohibited data. For example, instructions may include URLs / URIs, file paths, and credentials for accessing password-protected resources.

[0150] The method of this disclosure may include the step of providing a blockchain transaction (Tx1) or a portion thereof to at least one node on the network. The blockchain transaction (Tx1) or a portion thereof may be referred to as a recovery transaction / part. The part may be a script (e.g., an unlock script or a lock script) or the output of a blockchain transaction (e.g., a UTXO). The network may be a blockchain network. The at least one node may be, for example, a mining node. The recovery blockchain transaction (Tx1) or a portion thereof may include a ZKP that can be used to verify the existence of a portion of data that has been edited (i.e., deleted, replaced, obfuscated, or otherwise made inaccessible) from the original unedited version (Tx0) of the blockchain transaction (Tx1) or a portion thereof.

[0151] A recovery transaction (Tx1) or a portion thereof may be identified by a unique identifier. A recovery transaction (Tx1) or a portion thereof 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 at least one receiving resource to replace or substitute an unedited version or copy of the blockchain transaction or portion thereof stored with an edited (i.e., recovered) version of the blockchain transaction or portion thereof. The request or instruction may include a unique identifier so that the receiving resource can identify and / or specify the unedited version of the blockchain transaction / part (Tx0) stored therein. In addition, or alternatively, the instruction or request may request or instruct the receiving resource to monitor network traffic and data packets, check for any transactions or parts with a unique identifier, and, if a match is found, ignore the found version of the transaction or part (Tx0) and process the provided (edited) version (Tx1) instead. Processing may include one or more of storing, sending over the network, or verifying the transaction / part according to the blockchain protocol.

[0152] A ZKP may be provided in a recovery transaction (Tx1) or as part of one, or it may be provided by a pointer, reference, link, or other instruction that can locate the ZKP on-chain or off-chain. At least one receiving or sending resource can use the ZKP to verify the presence of edited prohibited data.

[0153] Requests or instructions sent by a sending resource may include prohibition orders or other data that prove permissions, rules, orders, and / or instructions related to prohibited data, and prohibition orders may be provided in a recovery transaction (Tx1) or part thereof, and a recovery transaction or part thereof may include pointers, references, links, or other instructions that can determine the on-chain or off-chain location of the prohibition orders.

[0154] After receiving a recovery transaction (Tx1) or a portion thereof, the receiving node may send the recovery transaction (Tx1) or a portion thereof to at least one additional receiving node.

[0155] A ZKP consists of one or more of the following: hashing, cryptographic hashing, the output of an editing operation, masking or obfuscation operations, or other known techniques for zero-knowledge proof of the existence of edited (i.e., prohibited) data. The terms “pruning,” “editing,” “exclusion,” and “obfuscation” are all used interchangeably in this document.

[0156] In some examples, embodiments may include one or more of the following steps: • Send the original or unedited version and / or portion of the blockchain transaction from the sending resource to at least one receiving resource. Then, the sending resource or at least one additional sending resource sends the following to at least one receiving resource: - Modified / edited versions of blockchain transactions and / or parts of blockchain transactions. - Replace at least one request and / or instruction (within memory / storage controlled, accessible, and / or associated with at least one receiving resource) with a modified / edited version of a blockchain transaction and / or part of a blockchain transaction.

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

[0158] The corrected / edited version may include replacing at least some of the prohibited data (ZKP).

[0159] In addition, or instead, at least one request and / or instruction may request or require at least one receiving resource to replace the original version of a transaction or part thereof with a modified / edited version in any message or electronic transmission that requires the transmission of the original version of the transaction or part thereof.

[0160] Clause Set 1: According to one possible form of expression, the embodiment can provide the following: Clause 1.1. A computer implementation method for transmitting data from a transmitting resource to a receiving resource over a network, The process involves sending a blockchain transaction (Tx1) or a portion thereof from a sending resource to a receiving resource via a node on the blockchain network, The sending resource includes the step of receiving a blockchain transaction (or a portion thereof) from a receiving resource via a node on the blockchain network. Here, i) A blockchain transaction (Tx1) or a portion thereof (i.e., a portion of a blockchain transaction) includes at least one zero-knowledge proof (ZKP) or at least one flag for a zero-knowledge proof, ii) A method which may be used to verify (i.e., enable or facilitate verification by a verifier) ​​that at least one zero-knowledge proof (ZKP) has been edited from a blockchain transaction (Tx1) or any part thereof.

[0161] In other words, ZNP enables or facilitates the determination or judgment that at least one portion of the data has been compiled from a blockchain transaction or a portion thereof. It can enable or facilitate the determination or judgment that at least one portion of the data has been compiled from a blockchain transaction or a portion thereof at a particular location.

[0162] Clause 1.2. Zero-knowledge proof (ZKP) or flag for zero-knowledge proof, hashes of at least some of the prohibited data, Encryption hashes of at least some of the prohibited data, The output of obfuscation techniques applied to at least a portion of the prohibited data, and The method described in Clause 1.1, which includes one or more outputs of a masking operation applied to at least a portion of the prohibited data.

[0163] Clause 1.3. The method described in Clause 1.1 or Clause 1.2, wherein a zero-knowledge proof or a flag for a zero-knowledge proof is provided in a blockchain transaction or a portion thereof to replace at least a portion of prohibited data.

[0164] Clause 1.4. A portion of a blockchain transaction is Blockchain transaction output, Unspent output of blockchain transactions, Scripts provided during or in connection with blockchain transactions, and A portion of the metadata provided in or in connection with a blockchain transaction or a portion thereof, The method described in any of the clauses 1.1 to 1.3, which is at least one of the above, or includes at least one of these.

[0165] Clause 1.5. Any method described in any of Clauses 1.1 through 1.4, wherein at least a portion of the prohibited data includes data that is designated or defined as prohibited by a policy, rule set, order, legal document, contract, instruction, license, or other control resource.

[0166] Clause 1.6. The method according to any one of Clauses 1.1 to 1.5, comprising the step of verifying that a zero-knowledge proof or flag for a zero-knowledge proof is a substitute or replacement for at least a portion of prohibited data in a blockchain transaction or a portion thereof.

[0167] Clause 1.7. The method described in any of Clauses 1.1 to 1.6, wherein a blockchain transaction or any part thereof includes a flag indicating that at least a portion of the prohibited data has been replaced by a zero-knowledge proof.

[0168] Clause 1.8. Using zero-knowledge proofs, i) A previous version of a blockchain transaction or part thereof contains at least part of prohibited data, or ii) A method of any of the clauses 1.1 to 1.7, which includes a step of verifying that at least some of the prohibited data is present.

[0169] Clause 1.9. A zero-knowledge proof (ZKP) or flag for a zero-knowledge proof prevents access to at least some prohibited data from a blockchain transaction or a portion thereof, as described in any of Clauses 1.1 through 1.8.

[0170] Clause 1.10. The sending resource and / or receiving resource, i) Nodes on a computer-based network, and / or, ii) Nodes on the blockchain network, and / or iii) Computing resources configured to process blockchain transactions, and / or iv) Digital wallets or any method described in any of the clauses 1.1 to 1.9, including these.

[0171] Clause 1.11. Using storage resources, At least one prohibited portion of the data, Zero-knowledge proof or flag for zero-knowledge proof, A policy, rule set, order, legal document, instruction, contract, license, or other control resource that designates or defines at least some of the prohibited data as prohibited, and An identifier that associates at least a portion of prohibited data with a zero-knowledge proof or a flag for zero-knowledge proofs. The method according to any one of the clauses 1.1 to 1.10, further comprising the step of storing at least one of the following.

[0172] Clause 1.12. A method according to any one of Clauses 1.1 to 1.11, wherein verifying that at least one prohibited portion of data is excluded from a blockchain transaction or a portion thereof includes verifying that at least one portion of the prohibited data is an element of a Merkle tree having a given root.

[0173] Clause 1.13. Memory including one or more memory units, A computer system comprising a processing unit including one or more processing units, wherein memory stores or executes code configured to run on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of the clauses 1.1 to 1.12.

[0174] Clause 1.14. The computer system Storage system or file system, database, Components that operate to interact with blockchain networks and / or blockchain ledgers. Digital wallets that operate to process and / or generate blockchain transactions, and Software components configured to run or execute a blockchain client at runtime. A computer system as described in Clause 1.13, including one or more of the following.

[0175] Clause 1.15. A computer program embodied on computer-readable storage, configured to perform, when executed on one or more processors, the method described in any of Clauses 1.1 to 1.12.

[0176] Clause Set 2: In addition, or instead, embodiments of the present disclosure may provide methods and systems described in the following clauses and substantially shown in Figures 5 to 12.

[0177] According to any one or more of the provisions of Set 2, a method for operating a network resource may be provided. The network resource may be, or include, a blockchain network or a node on a blockchain network. The following may be provided:

[0178] Clause 2.1. Computer implementation method, i) A step of determining whether an identifier that identifies a blockchain transaction is specified in the data structure that associates the blockchain transaction with the prohibited data portion, ii) A method comprising the steps of, if the determination is positive, removing at least a portion of prohibited data from the blockchain transaction and providing and / or propagating an edited version of the blockchain transaction to at least one recipient.

[0179] A determination step may be performed in response to the receipt of a request and / or to propagate a transaction. A “positive” determination may include the identification of a blockchain transaction in a data structure.

[0180] An edited version of a blockchain transaction may be modified from the initial state of the blockchain transaction such that at least a portion of the blockchain transaction is excluded from the edited version. The exclusion of at least a portion of the blockchain transaction includes its removal and / or replacement with at least one substitute element. The at least one substitute element may include a flag, placeholder, or other instruction placed in the edited version of the blockchain transaction (Tx1) at the location corresponding to the at least one excluded portion in the original version of the blockchain transaction. In addition, or instead, the at least one substitute element may include a proof. The proof may include a zero-knowledge proof (ZKP) or other mechanism that facilitates / enables verification of the exclusion (editing) of at least a portion of the prohibited data, in which case the contents of at least a portion of the prohibited data (e.g., the unmodified content) or other information of at least a portion of the prohibited data is not revealed or communicated in any way. In addition, or instead, the substitute element may include a replacement notice.

[0181] At least some of the prohibited data excluded from blockchain transactions in step ii) may be associated with blockchain transactions of the data structure.

[0182] A blockchain transaction may include a (blockchain) transaction identifier. A data structure may associate a blockchain transaction with a portion of prohibited data. In one or more embodiments, a data structure stores one or more prohibited portions of data, each associated with at least one blockchain transaction. The relationship between a given transaction and a given portion of prohibited data may be recorded / implemented in the data structure using a transaction identifier. In addition, or alternatively, a data structure may store one or more blockchain transactions and their corresponding identifiers.

[0183] A blockchain transaction identifier can be associated with one or more parts of prohibited data within a data structure. Conversely, each part of prohibited data within a data structure can be associated with one or more blockchain transactions.

[0184] A blockchain transaction identifier may consist of a blockchain block header or its hash, or a blockchain transaction ID (TxID), flags or protocol flags known in the art, or other identifiers that enable or facilitate the identification of a blockchain transaction within a data structure. At least one recipient may be a resource on the network, or a node on the blockchain network.

[0185] The term “data structure” may be used interchangeably with “storage resources” and / or “computer-based storage facilities.” A data structure may include software, firmware, and / or hardware.

[0186] Clause 2.2. The method of Clause 2.1, further comprising the step of providing and / or propagating proof that a blockchain transaction contains at least a portion of prohibited data. This step may be performed upon request.

[0187] Clause 2.3. Proof is the method described in Clause 2.2, including a hash of at least a portion of the prohibited data.

[0188] Clause 2.4. Proof is provided in the manner of Clause 2.2 or Clause 2.3, including zero-knowledge proof of at least a portion of the prohibited data.

[0189] Clause 2.5. Any method of any of Clauses 2.1 to 2.4, further comprising the step of providing and / or propagating at least one prohibition order which includes demonstrating, specifying, confirming, or including a requirement to refuse, decline, prohibit, or obfuscate the provision of at least a portion of the prohibited data. This step may be performed in response to a prior (or new) request.

[0190] Clause 2.6. A restraining order is a court order or a method of Clause 2.5, including instructions relating to the location of a court order. Such instructions may include web links, such as in the form of a URL or URI.

[0191] Clause 2.7. A prohibition order is a rule, law, instruction, requirement or policy, or an instruction relating to the location of any rule, law, instruction, requirement or policy, as described in Clause 2.5 or Clause 2.6.

[0192] Clause 2.8. The data structure shall include the transaction identifier, i) at least one proof of at least a portion of the prohibited data, and / or ii) In any of the manner described in any of Clauses 2.1 to 2.7, relating to at least one requirement to refuse / decline / inquire about / prohibit the provision of at least a corresponding portion of prohibited data.

[0193] Clause 2.9. Data structures include databases, hash tables, distributed hash tables (DHTs), cloud-based storage facilities, or other computer-based storage resources configured for the storage of electronic / digital data, as described in any of Clauses 2.1 through 2.8.

[0194] Clause 2.10. The data structure includes a distributed hash table, as described in any of Clauses 2.1 through 2.9.

[0195] Clause 2.11. The data structure is a centralized data structure accessible and / or modifiable by multiple network resources, as described in any of Clauses 2.1 through 2.10.

[0196] Clause 2.12. If at least a portion of prohibited data is included in or referenced in the consumed output of a blockchain transaction, the method according to any of Clauses 2.1 to 2.11 further comprises the step of preventing visibility and / or access to the portion of the blockchain transaction that includes or references at least a portion of the prohibited data via the blockchain ledger. The blockchain ledger is associated with a blockchain protocol, and blockchain transactions may be formed in accordance with the blockchain protocol.

[0197] The step of preventing visibility or access includes replacing portions of blockchain transactions that originally contained at least some prohibited data with alternative elements such as placeholders, flags, notifications, or proof, as described above. This may provide the ability to verify the presence of at least some prohibited data within a blockchain transaction without displaying or accessing it from the blockchain (ledger).

[0198] Clause 2.13. The method of Clause 2.12, further comprising the step of replacing at least a portion of prohibited data with notification data indicating that it previously and / or originally existed in that portion of the transaction but is no longer visible / publicly accessible via the blockchain ledger.

[0199] Clause 2.14. The method of Clause 2.13, wherein the notice data comprises zero-knowledge proof of at least a portion of the prohibited data and at least one of the prohibited data (also known as a prohibition order) indicating a requirement for deletion, exclusion, replacement, or obfuscation of at least a portion of the prohibited data.

[0200] Clause 2.15. The method according to any one of Clauses 2.1 to 2.14, further comprising the step of identifying a subsequent blockchain transaction that consumed the output of a transaction if at least one portion of prohibited data is included in or referenced in the consumed output of that transaction.

[0201] Clause 2.16. The method of Clause 2.15, further comprising the step of adding a subsequent blockchain transaction identifier to the data structure that identifies that the subsequent blockchain transaction contains or references at least a portion of prohibited data.

[0202] Clause 2.17. The method described in Clause 2.17, wherein the blockchain transaction identifier includes a hash of at least a portion of the blockchain transaction.

[0203] Clause 2.18. Computer implementation method, A step of identifying a blockchain transaction that includes at least one portion of prohibited data or a reference thereof, A method comprising the step of adding an identifier that identifies blockchain transactions to a data structure. At least some of the prohibited data may be deemed undesirable, subject to rules, laws, or policies, or deemed subject to censorship or filtering.

[0204] Clause 2.19. Computer equipment comprising memory including one or more memory units and a processing unit including one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to cause the processing unit to execute any of the methods described in Clauses 2.1 to 2.18.

[0205] The Code in Clause 2.20 is further configured to cause a processing unit to propagate or relay a pending blockchain transaction in response to a positive determination that the pending blockchain transaction does not contain at least some prohibited data or references to such data, as described in Clause 2.19.

[0206] Clause 2.21. A computer program that is embodied on computer-readable storage and, when executed on one or more processors, is configured to perform any of the methods described in Clauses 2.1 through 2.18. [Explanation of Symbols]

[0207] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A computer implementation method for transmitting data from a sending resource to a receiving resource over a network, A blockchain transaction (Tx) is sent from the sending resource to the receiving resource. 1 ) or a part thereof, The sending resource includes the step of receiving a blockchain transaction (or a portion thereof) from the receiving resource. i) The aforementioned blockchain transaction (Tx 1 ) or part thereof includes at least one zero-knowledge proof (ZKP) or at least one flag for such zero-knowledge proof, ii) A method which may be used to verify that at least one zero-knowledge proof (ZKP) of data has been excluded from the blockchain transaction or any part thereof.

2. The zero-knowledge proof (ZKP) or the flag for the zero-knowledge proof is hashes of at least some of the prohibited data, The encrypted hash of at least a portion of the prohibited data, The output of the obfuscation technique applied to at least a portion of the prohibited data, and Output of the masking operation applied to at least a portion of the prohibited data. The method according to claim 1, comprising one or more of the following.

3. The 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 a portion thereof to replace the prohibited data.

4. The aforementioned network is a blockchain network, The method according to any one of claims 1 to 3, wherein the transmitting resource and / or the receiving resource are nodes on the blockchain network.

5. The portion of the aforementioned blockchain transaction is Blockchain transaction output, Unspent output of blockchain transactions, Scripts provided during or in connection with blockchain transactions, and A portion of the metadata provided in or in connection with the blockchain transaction or a portion thereof, The method according to any one of claims 1 to 4, wherein the method is at least one of the or includes at least one of the above.

6. The method according to any one of claims 1 to 5, wherein at least a portion of the prohibited data includes data that is designated or defined as prohibited by a policy, rule set, order, legal document, contract, instruction, license, or other control resource.

7. The method according to any one of claims 1 to 6, comprising the step of verifying that the zero-knowledge proof or the flag for the zero-knowledge proof is a replacement or substitute for at least a portion of prohibited data in the blockchain transaction or a portion thereof.

8. The method according to any one of claims 1 to 7, wherein the blockchain transaction or a portion thereof includes a flag indicating that at least a portion of the prohibited data has been replaced by the zero-knowledge proof.

9. Using the aforementioned zero-knowledge proof, i) The blockchain transaction or a previous version of a part thereof contains at least the aforementioned portion of prohibited data, or ii) At least a portion of the prohibited data exists. The method according to any one of claims 1 to 8, comprising the step of verifying.

10. The method according to any one of claims 1 to 9, wherein the zero-knowledge proof (ZKP) or the flag for the zero-knowledge proof prevents access to at least the prohibited data from the blockchain transaction or a portion thereof.

11. The transmitting resource and / or the receiving resource, i) Nodes on a computer-based network, and / or, ii) Nodes on the blockchain network, and / or iii) Computing resources configured to process blockchain transactions, and / or iv) Digital wallets The method according to any one of claims 1 to 10, which is either or includes the same.

12. Using storage resources, The aforementioned at least one prohibited portion of the data, The zero-knowledge proof or the flag for the zero-knowledge proof, Policies, rule sets, orders, legal documents, instructions, contracts, licenses, or other control resources that designate or define as prohibited data, and An identifier that associates at least a portion of the prohibited data with the zero-knowledge proof or the flag for the zero-knowledge proof. The method according to any one of claims 1 to 11, further comprising the step of storing at least one of the following.

13. The method according to any one of claims 1 to 12, wherein verifying that the at least one prohibited portion of the data is excluded from the blockchain transaction or any part thereof includes verifying that the at least portion of the prohibited data is an element of a Merkle tree having a given root.

14. Memory including one or more memory units, A computer system comprising a processing unit including one or more processing units, wherein the memory is configured to store or execute code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 13.

15. The aforementioned computer system Storage system or file system, database, Components that operate to interact with blockchain networks and / or blockchain ledgers. Digital wallets that operate to process and / or generate blockchain transactions, and Software components configured to run or execute a blockchain client at runtime. The computer system according to claim 14, comprising one or more of the following:

16. A computer program, which is implemented on computer-readable storage and is configured to perform the method described in any one of claims 1 to 13 when executed on one or more processors.

Images