Filtering of Blockchain Transactions

Abstract

1. A computer-implemented method for processing blockchain transactions, the method being executed by a receiving party and comprising: obtaining one or more probabilistic filters, each of which encodes one of i) one or more sets of whitelisted data items or ii) one or more sets of blacklisted data items; obtaining a blockchain transaction, the obtained blockchain transaction being associated with a candidate data item that corresponds to i) one of the one or more sets of whitelisted data items or ii) one of the one or more sets of blacklisted data items; and determining whether to process the obtained blockchain transaction based on whether the candidate data item is present in at least one of the one or more probabilistic filters.

Description

Technical Field

[0001] The present disclosure relates to a method for processing blockchain transactions.

Background Art

[0002] A blockchain refers to a form of a distributed data structure, and replicated copies of the blockchain are maintained and widely publicized at each of a plurality of nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as a “blockchain network”). A blockchain includes a chain of data blocks, and each block includes one or more transactions. Each transaction other than a so-called “coinbase transaction” refers to a preceding transaction in a sequence that can span from one or more blocks to one or more coinbase transactions. The coinbase transaction will be described below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often called “mining,” which involves multiple nodes competing to perform a “proof-of-work,” i.e., solving a cryptographic puzzle based on a defined representation of a set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. Note that the blockchain can be pruned at nodes, and the publication of a block can be achieved through the publication of just the block header.

[0003] Transactions within a blockchain are used to perform one or more of the following: transfer digital assets (i.e., some digital tokens), order a set of journal entries in a ledger or registry, receive and process timestamp entries, and / or time-order index pointers. The blockchain can also be utilized to layer additional functionality on top of the blockchain. The blockchain protocol may enable the storage of additional user data or an index to data in a transaction. There is no predefined limit on the maximum data capacity that can be stored within a single transaction, and thus, more complex data can be incorporated. For example, this can be used to store electronic documents on the blockchain or store audio or video data.

[0004] Nodes in a blockchain network (often referred to as "miners") execute a decentralized transaction registration and verification process, which will be described in detail below. Briefly, during this process, transactions are validated and inserted into a block template where the node attempts to identify a valid proof-of-work solution. When a valid solution is found, a new block is propagated to other nodes in the network, enabling each node to record the new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The node that receives the transaction competes to find a proof-of-work solution that incorporates the validated transaction into a new block. Each node is configured to implement the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor incorporated into blocks. Assuming a transaction is validated and thereby accepted onto the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes within the blockchain network as an immutable public record.

[0005] The node that successfully solves the proof-of-work puzzle and creates the latest block is typically rewarded with a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., some tokens. The detection and rejection of invalid transactions serve as an action by competing nodes that act as agents of the network and are incentivized to report and prevent fraud. Due to the extensive public disclosure of information, users can continuously audit the performance of nodes. By simply publishing the block headers, participants can ensure the ongoing integrity of the blockchain.

[0006] In an “output-based” model (also sometimes called the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of digital assets derivable from a preceding sequence of transactions. Spendable outputs are sometimes called UTXOs (“unspent transaction outputs”). An output may further include a lock script that specifies the conditions for future redemption of the output. A lock script is a predicate that defines the conditions necessary for validating and transferring a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a preceding transaction and may further include an unlocking script for unlocking the lock script of the indicated output. Thus, considering a pair of transactions, they are referred to as the first transaction and the second transaction (or “target” transaction). The first transaction includes at least one output that specifies the amount of digital assets and a lock script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network, propagated, and recorded on the blockchain, one of the criteria for validity applied at each node is that the unlock script satisfies all of one or more conditions defined by the lock script of the first transaction. Another is that the output of the first transaction has not yet been redeemed by another valid transaction at another destination. A node that discovers that the target transaction is invalid according to any of these conditions will neither propagate it (although it may be propagated to register an invalid transaction) nor include it in a new block to be recorded on the blockchain.

[0008] Another type of transaction model is the account-based model. In this case, each transaction defines the amount to be transferred by referring to the absolute account balance, rather than by referring to the UTXOs of previous transactions in the sequence of past transactions. The current state of all accounts is stored separately from the blockchain by the nodes and is constantly updated. SUMMARY OF THE INVENTION

[0009] Tracking and understanding digital assets (e.g., tokens) on a blockchain can be a complex process, and in the past, criminals have used this complexity to use the blockchain for illegal activities such as settling illegal transactions. Some blockchain networks are actively working to reduce the use of the blockchain for criminal activities, thereby improving transparency and protecting users and businesses. Efforts to achieve these goals include identifying and banning malicious users and seizing their digital assets.

[0010] Therefore, it is necessary to be able to identify and prohibit or prevent transactions that are known or suspected to be related to criminals, transactions involved in illegal acts, or transactions containing illegal content. Then, the nodes of the network can freeze these transactions, that is, prevent the outputs of these transactions from being allocated (e.g., used), so that as a result, these outputs become worthless to the current owner. The nodes of the network can also refuse to serve them, for example, refuse to make some or all of the transactions available to the requesting entity.

[0011] It would also be desirable to be able to identify transactions known to be "safe" transactions, for example, to enable the assignment of transaction outputs to trusted entities.

[0012] More generally, it would be desirable to be able to whitelist or blacklist specific transactions or transaction content, or to prevent or permit the allocation of transaction outputs to specific entities.

[0013] According to one aspect disclosed in this specification, a computer-implemented method for processing blockchain transactions, the method being executed by a receiving party, the method comprising: obtaining one or more probabilistic filters, each probabilistic filter encoding one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items; obtaining a blockchain transaction, the obtained blockchain transaction being associated with candidate data items corresponding to one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items; and determining whether to process the obtained blockchain transaction based on whether the candidate data items are present in at least one of the one or more probabilistic filters.

[0014] The present invention enables a first party (e.g., a user or a blockchain node) to process a transaction based on a probabilistic membership test. A probabilistic filter includes either a set of whitelisted (i.e., permitted) items or a set of blacklisted (i.e., prohibited) items. A probabilistic filter (e.g., a Bloom filter or a Cuckoo filter) is a probabilistic data structure used to test whether an element is a member of a set. A characteristic of a probabilistic filter is that there can be false positives but no false negatives. That is, a probabilistic filter can be used to determine whether an element is definitely not in a set or whether it may be in the set. By obtaining the probabilistic filter(s), the first party can check whether the data items associated with the transaction are never allowed (in the case of whitelisted items) or are never prohibited (in the case of blacklisted items).

[0015] For example, a whitelisted item or a blacklisted item can be an allowed destination address or a prohibited destination address, respectively. Thus, a first party (e.g., a user operating a client application) can choose to allocate a certain amount of digital assets based on whether the destination address is considered allowed or prohibited. Alternatively, the item can be an allowed transaction identifier or a prohibited transaction identifier. In these examples, the first party (e.g., a blockchain node) can choose whether to supply a transaction based on whether the corresponding transaction identifier is considered allowed or prohibited. Further examples are provided below.

[0016] A whitelisted item can be an item that a second party (e.g., a trusted institution) considers allowed for one or more reasons. Similarly, a blacklisted item can be an item that the second party considers should be prohibited for one or more reasons, e.g., because it is associated with criminal activities.

[0017] The present invention improves the security of users and / or nodes by preventing them from inadvertently getting involved with illegal content, etc. For example, a blockchain node can perform a membership test to check that the node is not storing or propagating a transaction containing illegal material.

[0018] A probability filter (including references to outputs used as part of criminal activity or wrongdoing) can be provided by domestic or international tribunals. Thereby, those tribunals can freeze their outputs and block illegal off-chain content in their jurisdictions. On the other hand, since criminals can no longer assign them, they are discouraged from trading illegal goods and receiving illegal transactions. On the other hand, transactions between legitimate entities (such as users and enterprises) can be incentivized because the UTXO can convince the legitimacy of the transaction chain that leads to being assigned to or from those entities.

[0019] It should be noted that it is also desirable to prevent transactions from being supplied for non-legal reasons. As an example, a user's personal data can be stored on the blockchain regardless of whether the user gives permission. The user may wish to prevent their data from being sent to the requesting entity.

[0020] According to another aspect disclosed herein, a computer-implemented method for controlling access to some or all of the blockchain transactions, the method being executed by a sending side, and generating one or more probability filters, each probability filter encoding one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items, and transmitting the one or more probability filters to a receiving side.

Brief Description of the Drawings

[0021] To assist in the understanding of the embodiments of the present disclosure and to show how such embodiments can be implemented, reference is made to the accompanying drawings by way of mere example.

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6a

Figure 6b

Figure 7

Mode for Carrying Out the Invention

[0022] Overview of an Exemplary System FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 can typically be composed of a packet switching network 101, which is a wide area internetwork such as the Internet. The packet switching network 101 includes a plurality of blockchain nodes 104 that can be configured to form a peer-to-peer (P2P) network 106 within the packet switching network 101. Although not shown, the blockchain nodes 104 can be configured as an almost complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0024] The blockchain 150 includes a chain of data blocks 151, and each copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 within a distributed or blockchain network 160. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the entire blockchain 150. Instead, the blockchain 150 can have data pruned as long as each blockchain node 150 stores the block headers (described below) of each block 151. Each block 151 within the chain includes one or more transactions 152, and a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one specific transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output designates an amount representing a digital asset as a property, an example of which is a user 103 whose output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or used). Each input refers to an output of a previous transaction 152, thereby linking the transactions.

[0025] Each block 151 also includes a block pointer 155 that points to a previously created block 151 in the chain to define the order to the block 151. Each transaction 152 (other than the coinbase transaction) includes a pointer back to the previous transaction to define the order to the sequence of the transactions (note: the sequence of the transaction 152 can branch). The chain of blocks 151 goes all the way back to the genesis block (Gb) 153 that was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than the previous transaction.

[0026] Each of the blockchain nodes 104 is configured to forward the transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 throughout the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 that are waiting to be incorporated into the block 151. The ordered set 154 is often referred to as a "mempool". This term in this specification is not intended to be limited to any particular blockchain, protocol, or model. This refers to an ordered set of transactions that the node 104 has accepted as valid, for which the node 104 is obligated not to accept other transactions that attempt to use the same output.

[0027] In a given current transaction 152j, the input (or each input) includes a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "used" in the current transaction 152j. Generally, the preceding transaction can be any transaction within the ordered set 154 or any block 151. The preceding transaction 152i needs to be present and valid for the current transaction to be valid, but the preceding transaction 152i does not necessarily need to be present when the current transaction 152j is created or sent to the network 106. Thus, "preceding" as used herein refers to the preceding one in the logical sequence linked by the pointer and does not necessarily refer to the time of creation or transmission in the time sequence, and thus does not necessarily exclude the possibility that transactions 152i, 152j are created or sent out of order (see the following explanation regarding orphan transactions). The preceding transaction 152i is also referred to as the antecedent transaction or the predecessor transaction.

[0028] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a to whom the output of the preceding transaction 152i is locked. Next, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users or entities, one of which may be the original user or entity 103a to give the change. In some cases, the transaction may also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them to one or more outputs of the current transaction.

[0029] According to an output-based transaction protocol such as Bitcoin, when an entity 103 such as a user or a machine desires to establish a new transaction 152j, the entity sends the new transaction from its computer terminal 102 to the recipient. The entity or the recipient ultimately sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which are currently typically servers or data centers but in principle could be other user terminals). It is not excluded that the entity 103 that establishes the new transaction 152j sends the transaction to one or more of the blockchain nodes 104 and in some cases does not send it to the recipient. The blockchain node 104 that receives the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain node 104 to check that the cryptographic signature within the new transaction 152j matches the expected signature that depends on the previous transaction 152i within the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches the conditions defined in the output of the previous transaction 152i that the new transaction assigns, which typically includes at least checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The conditions may be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any case, if a new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 within the blockchain network 106. These other blockchain nodes 104 apply the same tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0030] In an output-based model, the definition of whether a given output (e.g., UTXO) is assigned is whether it is validly redeemed by the input of another previous transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to assign or redeem has not yet been assigned / redeemed by another transaction. Similarly in this case, if it is not valid, the transaction 152j is neither propagated (unless flagged as invalid and propagated for warning) nor recorded in the blockchain 150. This prevents a double spend where a transactor attempts to assign the output of the same transaction multiple times. On the other hand, an account-based model prevents double spends by maintaining account balances. Here too, since the transaction order is defined, the account balance is always in a single defined state.

[0031] In addition to validating transactions, blockchain node 104 also attempts to compete to first create a block of transactions in a process generally called mining, as directed by "proof of work." At the blockchain node 104, new transactions are added to an ordered set 154 of valid transactions that do not yet appear within block 151 recorded on the blockchain 150. The blockchain node then attempts to compete to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is concatenated with and hashed with the representation of the ordered set 154 of transactions, the output of the hash meets a predetermined condition. For example, the predetermined condition could be that the output of the hash has a specific predetermined number of leading zeros. It should be noted that this is just one specific type of proof of work puzzle, and other types are not excluded. The characteristic of a hash function is that it has an output that is unpredictable for its input. Therefore, since this search can only be performed by brute force, it consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0032] The first blockchain node 104 to solve the puzzle publishes it to the network 106 and provides as proof thereof its solution, which can later be easily checked by other blockchain nodes 104 within the network (it is easy to check that the output of the hash meets the conditions when the solution for the hash is given). This first blockchain node 104 propagates the block to the threshold consensus of other nodes that accept this block and enforces the protocol rules. Subsequently, the ordered set of transactions 154 will come to be recorded as new blocks 151 within the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 is also assigned to the new block 151n that points to the previously created block 151n-1 within the chain. The significant amount of effort, e.g., in the form of a hash, required to create the proof of work indicates the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, also known as double spending. Once created, the block 151 is recognized and maintained at each of the blockchain nodes 104 within the blockchain network 106 and thus cannot be modified. The block pointer 155 also assigns an order to the block 151. The transaction 152 is recorded in the ordered blocks at each blockchain node 104 within the network 106, which provides an immutable public ledger of the transactions.

[0033] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the ordered set of transactions 154 that are not yet public, depending on when they started searching for a solution or the order in which transactions were received. Whichever node solves its respective puzzle first defines which transactions 152 are included in the next new block 151n in what order, and the current set 154 of non-public transactions is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined, unprocessed ordered set of non-public transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur if two blockchain nodes 104 solve the puzzle within a very short time of each other, causing opposing views of the blockchain to propagate between the nodes 104. In short, the longest-growing prong of the fork becomes the definitive blockchain 150. Note that this does not affect the users or agents of the network because the same transactions appear in both forks.

[0034] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate the received amount of digital assets in a new special type of transaction that distributes a defined amount of digital assets (as opposed to a transaction between agents or users transferring a certain amount of digital assets from one agent or user to another). This special type of transaction is typically called a "coinbase transaction," but may also be called an "initiation transaction." This typically forms the first transaction of a new block 151n. Proof of work indicates the intention that the protocol rules enable the node constructing the new block to later redeem this special transaction. The blockchain protocol rules may require a maturity period, e.g., 100 blocks, before this special transaction can be redeemed. Often, a normal (non-coinbase) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called the "transaction fee" and is explained below.

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

[0036] The memory of each blockchain node 104 stores software configured to execute one or more of its respective roles and to process transactions 152 according to the blockchain node protocol on the processing device of the blockchain node 104. It will be appreciated that any action attributed to the blockchain node 104 herein may be performed by software executed on the processing device of each computer device. The node software may be implemented in one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer, or any combination thereof.

[0037] Each computer device 102 of a plurality of parties 103 that act as consuming users is also connected to the network 101. These users can interact with the blockchain network, but do not participate in transaction and block validation, construction, or propagation. Some of these users or agents 103 may act as senders and receivers of transactions. Other users can 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 (e.g., obtained a copy of the blockchain from the blockchain node 104).

[0038] Some or all of the parties 103 may be connected as part of a network overlaid on a different network, such as blockchain network 106. Users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network, but these users do not perform the roles required of blockchain nodes, so they are not blockchain nodes 104. Instead, each party 103 may interact with the blockchain network 106 and utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes, namely, the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b. It will be understood that there are far more such parties 103 and their respective computer devices 102 that can exist and participate in the system 100, but for the sake of simplicity, they are not shown. Each party 103 can be an individual or an organization. By way of pure example, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but this is not limiting, and it will be understood that any reference to Alice or Bob in this specification can be replaced with "the first party" and "the second party", respectively.

[0039] The computer device 102 of each party 103 includes a respective processing device including one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computer device 102 of each party 103 further includes a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may comprise one or more memory units employing one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memories or EEPROMs, and / or optical media like optical disk drives. The memory on the computer device 102 of each party 103 stores software including respective instances of at least one client application 105 configured to be executed on the processing device. It will be understood that any action attributed to a given party 103 herein may be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. The computer device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources accessed via the user terminal.

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

[0041] The client application 105 includes at least a "wallet" function. This has two main functions. One of these enables each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104, thereby propagating the transaction 152 across the network of blockchain nodes 104 so that it is included in the blockchain 150. The other is to report to each party the amount of digital assets that the party currently owns. In an output-based system, this second function involves reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to that party.

[0042] Although various client functions may be described as integrated into a given client application 105, it is not necessarily limited to this. Instead, it should be noted that any client function described herein may be implemented, for example, in two or more separate applications that interface via an API or where one is a plugin to the other. More generally, the client function may be implemented in the application layer, a lower layer such as an operating system, or any combination thereof. Although described below with respect to the client application 105, it will be understood that it is not limited to this.

[0043] Instances of client applications or software 105 on each computer device 102 are operably coupled to at least one of the blockchain nodes 104 of network 106. Thereby, the wallet function of client 105 can send transaction 152 to network 106. Client 105 can also contact blockchain node 104 to query blockchain 150 for any transaction where each party 103 is the recipient (alternatively, in embodiments, blockchain 150 is a public facility that provides trust in transactions through its public visibility, so actually inspects the transactions of other parties in blockchain 150). The wallet function on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate transaction 152 according to a blockchain node protocol and forward transaction 152 to propagate them throughout blockchain network 106. The transaction protocol and the node protocol correspond to each other, a given transaction protocol goes with a given node protocol, and together implement a given transaction model. The same transaction protocol is used for all transactions 152 within blockchain 150. The same node protocol is used by all nodes 104 within network 106.

[0044] When a given party 103, e.g., Alice, wishes to send a new transaction 152j to be included in the blockchain 150, Alice formulates the new transaction according to the relevant transaction protocol (using the wallet function within her client application 105). Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this could be the blockchain node 104 that is best connected to Alice's computer 102. Any given blockchain node 104, upon receiving the new transaction 152j, processes it according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for it to be "valid", examples of which will be described in more detail below. In some transaction protocols, the conditions for validation may be configurable for each transaction by the script included in the transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or may be defined by a combination of the script and the node protocol.

[0045] Conditioned on the newly received transaction 152j passing a test to be considered valid (i.e., conditioned on it being "validated"), any blockchain node 104 that receives transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, any blockchain node 104 that receives transaction 152j propagates the validated transaction 152 forward to one or more other blockchain nodes 104 within the network 106. Since each blockchain node 104 applies the same protocol, assuming transaction 152j is valid, this means it is propagated immediately across the entire network 106.

[0046] Upon approval of the ordered set of transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each ordered set of transactions 154 that includes the new transaction 152 (recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different ordered sets of transactions 154, but whichever node solves it first defines the ordered set of transactions included in the latest block 151. Eventually, blockchain node 104 will solve the puzzle for a portion of the ordered set 154 that includes Alice's transaction 152j.) When proof-of-work is performed on the ordered set 154 that includes the new transaction 152j, it becomes part of one of the blocks 151 within the blockchain 150 universally. Since each transaction 152 includes a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0047] Different blockchain nodes 104 may initially receive different instances of a given transaction, and thus have conflicting views as to which instance is "valid" until one instance is published in a new block 151 (at which point all blockchain nodes 104 agree that the published instance is the only valid instance). If a blockchain node 104 accepts one instance as valid and then discovers that a different instance is recorded in the blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as invalid) the initially accepted instance (i.e., the one not published in block 151).

[0048] Alternative types of transaction protocols operated by some blockchain networks may be referred to as "account-based" protocols as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referring to the absolute account balance rather than by referring to the UTXOs of previous transactions in the sequence of past transactions. The current state of all accounts is stored and constantly updated by the nodes of the network separately from the blockchain. In such a system, transactions are ordered using the transaction tally (also called the "position") of the account during execution of the transaction. This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Additionally, optional data fields in the transaction can also be signed. This data field can indicate a previous transaction, for example, if the previous transaction ID is included in the data field.

[0049] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 contains one or more transactions 152). In the following, it will be described with reference to an output-based or "UTXO" - based protocol. However, this is not limited to all possible embodiments. The exemplary UTXO-based protocol is described with reference to Bitcoin, but note that it can be equally implemented on other exemplary blockchain networks.

[0050] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that contains one or more inputs 202 and one or more outputs 203. Each output 203 can include an unspent 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). A UTXO contains a value that specifies the amount of digital assets. This represents the set number of tokens on the distributed ledger. A UTXO can also include, among other information, the transaction ID of the originating transaction. The transaction data structure may also include a header 201 that can include indicators showing the sizes of the input field(s) 202 and the output field(s) 203. The header 201 can also include the ID of the transaction. In an embodiment, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

[0051] Suppose Alice 103a wishes to create a transaction 152j that transfers the amount of the digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is "Tx 1is labeled "」. This takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx 0 " in Figure 2. Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction in the blockchain 151 or that Tx 1 is the very next transaction in the pool 154. Tx 1 can refer to any previous (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0052] The previous transaction Tx 0 may already be validity - confirmed and included in the block 151 of the blockchain 150 by the time Alice creates the new transaction Tx 1 , or at least by the time Alice sends it to the network 106. It may already be included in one of the blocks 151 at that time, or still be waiting in the ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx 0 and Tx 1 can be created and sent to the network 106 together, or if the node protocol allows buffering of "orphan" transactions, Tx 0 can be Tx 1It can even be sent after. As used herein in the context of a transaction sequence, the terms "preceding" and "subsequent" refer to the order of transactions within the sequence as defined by the transaction pointers specified within a transaction (such as which transaction refers to which other transaction). They can similarly be replaced with "the preceding one" and "the subsequent one", or "the previous one" and "the next one", "parent" and "child", etc. This does not necessarily mean the order of their creation, transmission to the network 106, or arrival at any given blockchain node 104. Nevertheless, a subsequent transaction (a later transaction or "child") that refers to a preceding transaction (an earlier transaction or "parent") is not validated unless the parent transaction is validated. A child that arrives at the blockchain node 104 before the parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be buffered for a specific time or discarded while waiting for the parent.

[0053] Preceding transaction Tx 0 One of one or more outputs 203 of 0 includes a specific UTXO labeled as such herein. Each UTXO includes a value specifying the amount of the digital asset represented by the UTXO and a lock script, and the lock script defines the conditions that must be met by the unlock script within the input 202 of a subsequent transaction for the subsequent transaction to be validated and thus for the UTXO to be properly redeemed. Typically, the lock script locks that amount to a specific party (the beneficiary of the transaction in which it is included). That is, the lock script typically defines an unlock condition that includes the condition that the unlock script within the input of a subsequent transaction includes the cryptographic signature of the party to whom the preceding transaction is locked.

[0054] The lock script (commonly known as scriptPubKey) is a part of the code written in a domain-specific language recognized by the node protocol. A specific example of such a language is what is called "Script" (capital S) used by the blockchain network. The lock script specifies what information is required to use the transaction output 203, for example, the need for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (commonly known as scriptSig) is a part of the code written in a domain-specific language that provides the information necessary 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.

[0055] That is, in the illustrated example, the UTXO 0 within the output 203 of Tx 0 requires the lock script [Checksig P 0 including Alice's signature Sig P 0 for the UTXO A to be redeemed (strictly speaking, for the subsequent transaction attempting to redeem the UTXO A to be valid). [Checksig P A includes the representation (i.e., hash) of the public key P A of Alice's public key - private key pair. The input 202 of Tx 1 includes a pointer indicating Tx 0 (e.g., in an embodiment, the transaction ID, TxID 0 which is the hash of the entire transaction Tx 1 ). The input 202 of Tx 1 includes an index identifying the UTXO 0 within Tx 0 to identify the UTXO 0 within Tx 0 from among any other possible outputs of Tx 1The input 202 contains an unlock script <Sig P A > created by Alice applying Alice's private key of the key pair to a predetermined part of the data (which may also be called the "message" in cryptography), which contains Alice's cryptographic signature. The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0056] When a new transaction Tx 1 arrives at the blockchain node 104, the node applies the node protocol. This includes executing the lock script and the unlock script together to check whether the unlock script meets the conditions defined by the lock script (which conditions may include one or more criteria). In an embodiment, this includes concatenating the two scripts: <Sig P A > <P A > || [Checksig P A Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function composed of the lock script (a stack-based language in this example). Equally, the scripts can be executed one after another using a common stack instead of concatenating the scripts. In any case, when executed together, the scripts use the public key P 0 of Alice as included in the lock script within the output of Tx A to authenticate that the unlock script within the input of Tx 1 contains Alice's signature that signed the expected part of the data. The expected part of the data itself (the "message") also needs to be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx 1 (that is, since a separate element specifying the signed part of the plaintext data already essentially exists, it does not need to be included).

[0057] ​ The details of authentication by public - private key cryptography are well known to those skilled in the art. Basically, when Alice signs a message using her private key, given Alice's public key and the plain - text message, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging the message with this as the signature, such that any holder of the public key can verify the signature. Thus, it should be noted that any reference in this specification to signing a particular part of data or a part of a transaction may, in embodiments, mean signing the hash of that part of the data or the part of the transaction.

[0058] Tx 1 If the unlock script within Tx 0 satisfies one or more conditions specified within the lock script of Tx 1 (i.e., in the illustrated example, if Alice's signature is provided and authenticated within Tx 1 ), the blockchain node 104 considers Tx 1 to be valid. This means that the blockchain node 104 will add Tx 1 to the ordered set of transactions 154. The blockchain node 104 also forwards the transaction Tx 1 to one or more other blockchain nodes 104 within the network 106 so that the transaction Tx 1 is propagated throughout the network 106. When Tx 0 is verified and included in the blockchain 150, this defines the UTXO 0 from Tx 1 as spent. It should be noted that Tx 1will be invalid even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO within the previous transaction Tx 0 has already been used (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose the order defined in transaction 152. In practice, a given blockchain node 104 may maintain a separate database marking which UTXO203 within which transaction 152 has been used, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction within blockchain 150.

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

[0060] Note that in the UTXO-based transaction model, a given UTXO needs to be used in its entirety. Even if another part is being used, it is not possible to "leave behind" a portion of the amount defined as used in the UTXO. However, it is possible to split the amount from a UTXO among multiple outputs of the next transaction. For example, the amount defined in the UTXO 0 within Tx 0 can be split among multiple UTXOs within Tx 1 . Therefore, if Alice does not want to give all of the amount defined in the UTXO 0 to Bob, Alice can use a remainder to give the remainder to herself in the second output of Tx 1 or pay it to another party.

[0061] In practice, Alice also typically needs to include a fee for the Bitcoin node that publishes Alice's transaction 104. If Alice does not include such a fee, Tx 0 can be rejected by the blockchain node 104 and thus may not be propagated or included in the blockchain 150 even if technically valid (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount indicated by the input(s) 202 of a given transaction 152 and the total amount specified by the output(s) 203 is automatically given to the blockchain node 104 that publishes the transaction. For example, if a pointer to a UTXO 0 is the only input to Tx 1 and Tx 1 has only the output UTXO 1 Let's assume. If the amount of the digital asset specified in UTXO 0 is greater than the amount specified in UTXO 1 , the difference can be allocated by the node 104 that publishes the block containing UTXO 1 . However, alternatively or additionally, it is not necessarily excluded that the transaction fee can be explicitly specified in one of its own UTXOs 203 of the transaction 152.

[0062] The digital assets of Alice and Bob are composed of UTXOs locked to them in some transaction 152 somewhere within the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across all the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere within the blockchain 150 is the number that defines the total balance of a given party 103 stored. The role of the wallet function in the client application 105 is to collate together the values of all the various UTXOs locked to each party and not yet used in another previous transaction. To do that, it queries a copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

[0063] Note that the script code is often represented schematically (i.e., without using exact language). For example, operation codes (opcodes) may be used to represent certain functions. "OP_..." refers to a particular opcode of the script language. As an example, OP_RETURN is an opcode of the script language that can create an unusable output of a transaction that can store data within the transaction when OP_FALSE precedes it at the beginning of the lock script, thereby immutably recording the data within the blockchain 150. For example, the data can include a document that is desired to be stored on the blockchain.

[0064] Typically, the input of a transaction is the public key P AIt includes a digital signature corresponding thereto. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific portion of the data. In some embodiments, for a given transaction, the signature signs a part of the transaction input and part or all of the transaction output. The specific portion of the signed output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select which output is signed (and thus is fixed at the time of signing).

[0065] The lock script may sometimes be referred to as "scriptPubKey", typically referring to the fact that each transaction contains the public key of the party by which it is locked. The unlock script may sometimes be referred to as "scriptSig", typically referring to the fact that it supplies the corresponding signature. However, more generally, it is not essential in all applications of the blockchain 150 that the condition for the UTXO to be redeemed includes authenticating the 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.

[0066] As shown in FIG. 1, the client applications on each of the computer devices 102a and 120b of Alice and Bob can each include additional communication capabilities. With this additional functionality, Alice 103a can establish a separate side channel 107 with Bob 103b (at the instigation of either party or a third party). The side channel 107 enables the exchange of data separate from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange a transaction 152 between Alice and Bob without the transaction being (yet) registered on the blockchain network 106 or proceeding on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Sharing a transaction in this way is sometimes referred to as sharing a "transaction template". A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data such as keys, negotiated amounts or conditions, data content, etc.

[0067] Side channel 107 can be established via the same packet - switched network 101 as blockchain network 106. Alternatively or additionally, side channel 107 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even via a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, anywhere in this specification, the referenced side channel 107 can include any one or more links via one or more networking technologies or communication media that are "off - chain", i.e., separate from blockchain network 106, for exchanging data. When two or more links are used, the bundle or set of off - chain links as a whole can be referred to as side channel 107. Thus, when it is said that Alice and Bob exchange information or a particular portion of data etc. on side channel 107, it should be noted that this does not necessarily mean that all portions of these data must be transmitted on exactly the same link or the same type of network.

[0068] Client software Figure 3A shows an exemplary implementation of client application 105 for implementing an embodiment of the method of the present disclosure. Client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. Transaction engine 401 is configured to implement the basic transaction - related functions of client 105 to formulate, for example, transaction 152, receive and / or transmit transactions and / or other data on side channel 107, and / or transmit transactions to one or more nodes 104 for propagation throughout blockchain network 106, in accordance with the methods described above and as will be described more briefly in further detail.

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

[0070] Although the various functions of this specification can be described as integrated into the same client application 105, this is not necessarily limiting. Instead, they can be implemented in a set of two or more separate applications. For example, one can be a plugin to the other, or they can interface via an API (Application Programming Interface). Note that, for example, the functions of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functions of a given module such as the transaction engine 401 may be split between two or more applications. It is not excluded that some or all of the described functions may be implemented, for example, at the operating system layer. Whenever a single or a given application 105 etc. is referred to anywhere in this specification, this is merely an example, and more generally, it will be understood that the functions described can be implemented in any form of software.

[0071] As an example, FIG. 3B provides a mockup of an example user interface (UI) 500 that can be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI can be rendered on Bob's device 102b by the client 105b or on the device of any other party.

[0072] By way of example, FIG. 3B shows the UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as separate UI elements via user output means.

[0073] For example, the UI element may include one or more user-selectable elements 501, which can be different on-screen buttons or different options within a menu. The user input means is configured to enable the user 103 (in this case, Alice 103a) to select one of the options or otherwise operate by clicking or touching the UI element on the screen or by saying the name of the desired option (note: the term "manual" as used in this specification means in contrast to automatic and is not necessarily limited to the use of one or more hands). Optionally, the user (Alice) can add an item (e.g., a blockchain address) to the probabilistic filter.

[0074] Alternatively or additionally, the UI element may include one or more data input fields 502 through which the user can add an item (e.g., a blockchain address) to the probabilistic filter. These data input fields are rendered via a user output means, such as the on-screen, and data can be input into the fields through a user input means, such as a keyboard or touch screen. Alternatively, the data can be received orally, for example, based on speech recognition.

[0075] Alternatively or additionally, the UI element can include one or more information elements 503 that are output to output information to the user. For example, this / these can be rendered on the screen or audibly.

[0076] It will be understood that the specific means of rendering various UI elements, selecting options, and inputting data are not important. The functions of these UI elements will be described in more detail below. The UI 500 shown in Figure 3 is merely a schematic mock-up and may actually include one or more additional UI elements not shown for the sake of brevity.

[0077] Node software Figure 4 shows an example of node software 450 that is executed on each blockchain node 104 of network 106 in an example of a UTXO or output-based model. Note that another entity may execute node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. Node software 450 may include, but is not limited to, a set of a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and one or more blockchain-related functional modules 455. Each node 104 may execute node software that includes, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). Protocol engine 401 is typically configured to recognize different fields of transaction 152 and process them according to the node protocol. When a transaction 152j (Tx m-1 ) having an input that refers to an output (e.g., a UTXO) of a previous transaction 152i (Tx j ) is received, protocol engine 451 identifies the unlock script within Tx j and passes it to script engine 452. Protocol engine 451 also identifies and retrieves Tx j based on the pointer in the input of Tx i . Tx i may be published on blockchain 150, in which case the protocol engine may retrieve Tx i from a copy of block 151 of blockchain 150 stored at node 104. Alternatively, Tx i may not yet be published on blockchain 150. In this case, protocol engine 451 may retrieve Tx i from an ordered set 154 of unpublished transactions maintained by node 104. In any case, script engine 451 is Txi Identify the lock script in the referenced output and pass it to the script engine 452.

[0078] Thus, the script engine 452 has the lock script of Tx i and the unlock script from the corresponding input of Tx j For example, FIG. 2 shows transactions labeled Tx 0 and Tx 1 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 it according to the stack-based scripting language (e.g., Script) being used.

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

[0080] In the output-based model, a result "true" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, the total amount of digital assets specified in the output(s) of Tx j does not exceed the total amount indicated by its input, and Tx iOne or more additional protocol level conditions, such as that the indicated output of [[ID=]] is not already being used by another valid transaction, must also be satisfied as evaluated by protocol engine 451. The protocol engine 451 evaluates the result from the script engine 452 along with one or more protocol level conditions and validates the transaction Tx only if they are all true. The protocol engine 451 outputs an indication as to whether the transaction is valid to the application level decision engine 454. Only on the condition that Tx is actually validated will the decision engine 454 choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain related functions with respect to Tx. This includes the consensus module 455C adding Tx to each ordered set of transactions 154 of the node for inclusion in block 151, and the propagation module 455P forwarding Tx to another blockchain node 104 within the network 106. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish the transaction only if the transaction is valid and there is sufficient transaction fee remaining. j to be verified. The protocol engine 451 outputs an indication as to whether the transaction is valid to the application level decision engine 454. Only on the condition that Tx j is actually verified will the decision engine 454 j choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain related functions with respect to Tx. This includes the consensus module 455C adding Tx j to each ordered set of transactions 154 of the node for inclusion in block 151, and the propagation module 455P forwarding Tx j to another blockchain node 104 within the network 106. Optionally, in an embodiment, the application level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish the transaction only if the transaction is valid and there is sufficient transaction fee remaining.

[0081] The terms "true" and "false" in this specification are not necessarily limited to returning results represented only in the form of a single binary digit (bit), but it should also be noted that this is certainly one possible implementation form. More generally, "true" can refer to any state indicating a successful or positive result, and "false" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, a "true" result can be indicated by a combination of an implicit protocol-level validity check of the signature and an additional positive output of the smart contract (if both individual results are true, the overall result is considered to indicate true).

[0082] Preliminary matters A probabilistic filter is a memory-efficient data structure used to test whether an element is part of a set. False negatives can never occur, that is, if an item is added to the probabilistic filter, the filter can always distinguish whether the same item is presented again. However, false positives can occur with a false positive probability that depends on several factors (e.g., the size of the probabilistic filter). In other words, there is a trade-off between the space efficiency of the filter and the false positive rate.

[0083] The two most widely used probabilistic filters are the Bloom filter and the Cuckoo filter. Both filters are initialized to provide a target false positive rate (fpp) and an expected number of elements. One fundamental difference between these two filters is that the Bloom filter can adapt to any number of elements, but when the number of inserted elements is more than the expected number of elements, the false positive rate of the filter increases (up to 100%). Conversely, the Cuckoo filter maintains the target false positive rate, but the insertion of new elements after the expected number is not guaranteed (insertion may be rejected). That is, the maximum size of the filter is not flexible after creation, and a new filter has to be created to apply to additional elements exceeding the maximum number. Another difference between these two filters is that in the Cuckoo filter, it is possible to delete previously inserted elements, while it is not possible in the Bloom filter. Note that Bloom and Cuckoo are just two types of probabilistic filters, and the present invention is not limited to just these two examples.

[0084] The space efficiency of each of the two filters is similar, and the cost in bits per element is, in the case of the Bloom filter,

Number

Number

[0085] Cuckoo filters are more time-efficient, performing insertions, deletions, and lookups in O(1), where the notation O( ) represents the complexity of an algorithm. O(1) represents constant complexity and a fast algorithm, while O(k) represents complexity that increases with k and a slower algorithm. Bloom filters perform the same operations, except for unsupported deletions, in O(k), where k is the number of hash functions of the Bloom filter.

[0086] Filtering of Blockchain Transactions The present invention enables effective blacklisting, or conversely, whitelisting of blockchain transactions (e.g., those related to criminal activities). The present invention is not necessarily limited to completely blacklisting or whitelisting transactions. For example, specific outputs, components, or content of a transaction may be filtered. As used herein, blacklisting is an access control mechanism that filters explicitly mentioned elements (e.g., blockchain addresses) to block them or prevent anyone or anything from accessing them. The opposite of blacklisting is whitelisting, which is an access control mechanism that allows access only to specified elements.

[0087] The filtering of blockchain transactions disclosed herein includes the creation of probabilistic filters. The probabilistic filters are used to encode allowed data items (when the filter is for whitelisting) or prohibited data items (when the filter is for blacklisting). The term "data item", as used in this context, is construed to mean any item associated with a blockchain transaction. For example, a data item can be a destination address (e.g., a public key or a public key hash), a transaction identifier, an output, an output identifier (e.g., based on a transaction identifier and an output index), a token, content included in or suitable for inclusion in a transaction, and the like.

[0088] The list of data items that can be whitelisted or blacklisted can be large. Thus, to provide lightweight storage and transmission (especially to lightweight wallets), these lists are compressed using probabilistic filters that achieve up to 94% compression and provide fast lookups. The filters also enhance privacy since they encode (i.e., represent) data items rather than storing the actual data items.

[0089] An exemplary system 500 for implementing embodiments of the present invention is shown in FIG. 5. System 500 includes a receiving side 501 and a transmitting side 502. The system may include a plurality of different receiving sides 501 (not shown) and / or a plurality of different transmitting sides 502 (likewise not shown). The system may also include one or more third parties 503. As used herein, the term "transmitting side" 502 is used to refer to a party configured to generate a probabilistic filter and transmit it to one or more receiving sides 502. Similarly, the term "receiving side" 502 is used to refer to a party configured to receive a probabilistic filter for the purpose of checking the membership within the filter of one or more data candidate items associated with a blockchain transaction. The role of the third party 503 will be described later.

[0090] Each receiving side 501, sending side 502, and third party 503 operate their respective computer devices (not shown). Each computer device of the receiving side 501, sending side 502, and third party 503 includes a respective processing device that includes one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device of the receiving side 501, sending side 502, and third party 503 further includes a memory, that is, computer-readable storage in the form of one or more non-transitory computer-readable media. This memory may include one or more memory units that employ one or more memory media, such as magnetic media like hard disks, electronic media like SSDs, flash memories or EEPROMs, and / or optical media like optical disk drives. The memory on each computer device stores software that includes respective instances of at least one client application configured to be executed on the processing device. It will be understood that any action attributed to a given party herein may be performed using software executed on the processing device of each computer device. Each computer device of the receiving side 501, sending side 502, and third party 503 may include 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 device of a given party may also include one or more other networked resources such as cloud computing resources accessed via the user terminal.

[0091] In some examples, the receiving side 501 may include a user 103 (e.g., Alice 103a or Bob 103b) who operates an instance of the client application 105 described above. In other examples, the receiving side 501 may include or otherwise operate a blockchain node 104.

[0092] In some examples, the sending side 502 may include a user 103 (e.g., Alice 103a or Bob 103b) who operates an instance of the client application 105 described above. In other examples, the sending side 501 may include or otherwise operate a blockchain node 104. In other examples, the sending side 501 may be a trusted third party, such as a legal institution like a domestic or international tribunal, a certification authority, a government agency, a domestic or international police force, etc.

[0093] Although shown separately in FIG. 5, it should be noted that the receiving side 501 and the sending side 802 may actually be the same entity. That is, the receiving side 501 may generate a probabilistic filter.

[0094] In some examples, the third party 501 may include a user 103 (e.g., Alice 103a or Bob 103b) who operates an instance of the client application 105, or a blockchain node 104.

[0095] The sending side 502 is configured to generate a probabilistic filter (e.g., a Bloom filter or a Cuckoo filter). The probabilistic filter encodes either a set of whitelisted data items or a set of blacklisted data items. Here, "set" is used to refer to one or more data items of the same type, i.e., the same category. For example, the set of data items can be a set of transaction identifiers.

[0096] In some examples, the probabilistic filter may encode multiple sets of data items (i.e., multiple different categories). For example, the first set of data items can be a set of transaction identifiers, and the second set of data items can be a set of tokens. The specific types of data items will be described later.

[0097] The transmitting side 502 can generate a plurality of probability filters. One, some, or all of the plurality of filters can encode a plurality of sets (i.e., different types) of data items. One, some, or all of the plurality of filters can encode a single set (i.e., a single type) of data items.

[0098] The transmitting side 502 can update the previously generated probability filter(s) to include additional data items. For example, the transmitting side 502 can update the filter(s) periodically (e.g., in time units or in units of block 151) or on the fly when new data items become available.

[0099] The transmitting side 502 is configured to send the probability filter(s) to the receiving side 501 (and one or more other receiving sides 501). The transmitting side 502 can send all the filters together or separately. The filter(s) can be sent periodically, for example, in response to an update.

[0100] In some embodiments, at least one probability filter can encode a set of blockchain addresses. For example, the address can be a public key or a public key hash (i.e., a hash or double hash of the public key). The set of blockchain addresses can be a set of whitelisted addresses. Alternatively, the set of blockchain addresses can be a set of blacklisted addresses.

[0101] Additionally or alternatively, at least one probabilistic filter may encode a set of blockchain transaction outputs (UTXOs), or rather, the respective identifiers of the UTXOs. For example, each UTXO may be identified based on the respective transaction identifier of the transaction containing that UTXO. Each UTXO may be further identified based on the output index of that UTXO within the respective transaction. As an example, a UTXO may be identified by concatenating the transaction identifier and the output index. The set of blockchain transaction outputs may be a whitelisted set of blockchain transaction outputs. Alternatively, the set of blockchain transaction outputs may be a blacklisted set of blockchain transaction outputs.

[0102] In some embodiments, at least one probabilistic filter may encode a set of blockchain transaction identifiers (TxIDs). A TxID is generated by applying a hash function to the entire transaction. The set of TxIDs may be a whitelisted set of TxIDs. Alternatively, the set of TxIDs may be a blacklisted set of TxIDs.

[0103] In additional or alternative embodiments, at least one probabilistic filter may encode a set of block headers. A block header is generated by applying a hash function to the set of transactions within that block. The set of block headers may be a whitelisted set of block headers. Alternatively, the set of block headers may be a blacklisted set of block headers.

[0104] Additionally or alternatively, at least one probabilistic filter may encode a set of content items. For example, the content items may include one or more of audio content, image content, video content, documents, etc. The set of content items may include only one type of content or multiple different types of content. Encoding content items (and generally data items) in the filter is understood to mean including a representation (e.g., a hash) of the content item rather than the content item itself. Some data items (e.g., TxID) are already hashes and thus do not need to be hashed again, but are not precluded from being hashed again. The content items may include content included in published blockchain transactions. Additionally or alternatively, the content items may include content not included in published blockchain transactions. The set of content items may be a set of whitelisted content items. Alternatively, the set of content items may be a set of blacklisted content items.

[0105] In some embodiments, at least one probabilistic filter may encode a set of transactions that transfer tokens or token ownership. For example, the sending side is a token issuer (or institution) that issues or otherwise controls tokens. A token is a programmable digital asset hosted on an existing blockchain and is different compared to the native digital asset of that blockchain. A token is an entry (e.g., included in the output of a transaction) on a blockchain that functions as a digital record of ownership of a particular asset, such as a ticket, coupon, royalty point, access card, etc. The set of tokens may be a whitelisted set of tokens. Alternatively, the set of content items may be a blacklisted set of tokens. The existence of a natively trustworthy institution, the token issuer, makes it easy to implement blacklisting or whitelisting of tokens since there is only a single institution. The token issuer may maintain and release the filter according to custom company rules and guidelines (compared to more stringent filters released by, e.g., a court).

[0106] The receiving side 501 is configured to obtain at least one probabilistic filter from the sending side 502. In some examples, the receiving side 501 obtains a plurality of probabilistic filters from, for example, the same sending side 502 or from a plurality of different sending sides 502. The receiving side 501 may obtain the filter(s) directly from the sending side 501 or in some other way.

[0107] The receiving side 501 is also configured to obtain blockchain transactions. Obtaining a blockchain transaction may include obtaining a copy of the blockchain transaction, or a reference to the blockchain transaction, for example, obtaining the transaction identifier (TxID) of the transaction. The obtained blockchain transaction may be a transaction published in block 151. Alternatively, the blockchain transaction may be a transaction that has not yet been published. For example, the blockchain transaction may be within an ordered set of pending transactions 154 maintained at node 104, or the blockchain transaction may be a transaction template, i.e., a transaction that has not yet been submitted to the blockchain network 106. The blockchain template may be incomplete, for example, lacking one or more inputs and / or outputs and / or lacking one or more signatures.

[0108] The obtained blockchain transaction is associated with a candidate data item. The candidate data item may be a component of the blockchain transaction. That is, the blockchain transaction may include the candidate data item. The candidate data item may be a function of the blockchain transaction. That is, the candidate data item may be generated based on the candidate data item, for example, the TxID of the transaction. The candidate data item may be referenced by the transaction. For example, the transaction may include a reference to the candidate data item. Examples of candidate data items are shown below.

[0109] When one or more probabilistic filters and blockchain transactions (in any order) are obtained, the receiving side 501 determines whether to process the blockchain transaction based on whether the candidate data item exists in one, some, or all of the probabilistic filters. That is, the receiving side 501 performs a membership test on the candidate data item.

[0110] When the receiving side 501 operates the blockchain client application 105, processing the blockchain transaction may include signing the blockchain transaction with a signature associated with the receiving side 501 (e.g., using a private key owned by the receiving side 501). Additionally or alternatively, processing the blockchain transaction may include sending the (signed) transaction to one or more third parties 503 or the blockchain network 106.

[0111] When the receiving side 501 operates the blockchain node 104, processing the blockchain transaction may include publishing the transaction in the block 151 and / or propagating the transaction to other nodes 104. Or, processing the blockchain transaction may include, for example, sending the transaction to one or more third parties 503 in response to a request for the transaction. As another option, processing the blockchain transaction may include publishing or sending some but not all of the transaction. For example, some parts of the transaction may be pruned (e.g., obfuscated).

[0112] The candidate data item can be a blockchain address. The blockchain address corresponds to, i.e., maps to, the output of a transaction. More specifically, the blockchain address maps to the lock script of the output of the transaction. The blockchain address can be, for example, a public key or a public key hash when the output is a pay-to-public-key-hash (P2PKH) output.

[0113] The candidate blockchain address can be an address mapped to the output of the obtained blockchain transaction. If the set of whitelisted data items encoded by the obtained probability filter includes the set of whitelisted blockchain addresses, the receiving side 501 can process the obtained transaction only when the candidate blockchain address is one of the whitelisted addresses. If the set of blacklisted data items encoded by the obtained probability filter includes the set of blacklisted blockchain addresses, the receiving side 501 can process the obtained transaction only when the candidate blockchain address is not one of the blacklisted addresses. Here, processing the transaction can include, for example, signing the transaction and / or sending the transaction to a third party (e.g., user 103 or node 104) and / or publishing the transaction in block 151. Different options for processing the transaction are available depending on the role of the receiving side 501, e.g., whether the receiving side 501 is user 103 or node 104 (when the receiving side is node 104). As a specific example, when the receiving side is blockchain node 104, processing the transaction can include prioritizing the transaction for inclusion in block 151, i.e., making it superior to one or more other transactions in the ordered set of transactions 154.

[0114] The candidate data item can be an unspent transaction output (UTXO). That is, the obtained blockchain transaction can refer to the UTXO of the previous transaction (the previous transaction is, for example, a published transaction). The UTXO of the previous transaction is typically referenced based on the transaction identifier (TxID) of the previous transaction and the output (or outpoint) index of the output within the set of outputs of the previous transaction.

[0115] If the set of whitelisted data items encoded by the obtained probability filter includes the set of whitelisted UTXOs, the receiving side 501 can process the obtained transaction only if the candidate UTXO is one of the whitelisted UTXOs. If the set of blacklisted data items encoded by the obtained probability filter includes the set of blacklisted UTXOs, the receiving side 501 can process the obtained transaction only if the candidate UTXO is not one of the blacklisted addresses. Here, processing the transaction can include, for example, signing the transaction and / or sending the transaction to a third party (e.g., user 103 or node 104) and / or publishing the transaction in block 151 (if the receiving side is node 104). If the receiving side is the blockchain node 104, processing the transaction can include prioritizing the transaction for inclusion in block 151, that is, making it superior to one or more other transactions in the ordered set of pending transactions 154.

[0116] The candidate data item can be a transaction identifier. That is, the obtained blockchain transaction may include a transaction identifier. The transaction identifier (TxID) is generated by inputting transaction data (i.e., inputs and outputs) into a hash function. The hash function may be the SHA-256 function and may be applied twice.

[0117] If the set of whitelisted data items encoded by the obtained probabilistic filter includes the set of transaction identifiers, the receiving side 501 may process the obtained transaction only if the candidate transaction identifier is one of the whitelisted transaction identifiers. If the set of blacklisted data items encoded by the obtained probabilistic filter includes the set of blacklisted transaction identifiers, the receiving side 501 may process the obtained transaction only if the candidate transaction identifier is not one of the blacklisted transaction identifiers. Processing the obtained transaction may include making the transaction available to a third party 503, for example, by directly sending the transaction to the third party 503 or by publicly disclosing the transaction in other ways.

[0118] The candidate data item can be a content item. For example, the content item can be an image, an audio file, a document, a video file, text, etc. The content item can be associated with the obtained transaction in that the obtained transaction (which may or may not be published on the blockchain 150) includes the content item. In other examples, the content item may not yet be included in the transaction but may be suitable for inclusion in the transaction. In some examples, the content item can be a token.

[0119] If the set of white-listed data items encoded by the obtained probability filter includes the set of content items, the receiving side 501 can process the obtained transaction only if the candidate content item is one of the white-listed content items. If the set of black-listed data items encoded by the obtained probability filter includes the set of black-listed content items, the receiving side 501 can process the obtained transaction only if the candidate content item is not one of the black-listed content items. Processing the obtained transaction may include making the transaction available to a third party 503, for example, directly sending the transaction to the third party 503 or making the transaction public in other ways. In some examples, the receiving side 501 can process the transaction even if the content item is black-listed. In these examples, the receiving side 501 can make the transaction available to the third party 503 without the content item, for example, by deleting the content item or obfuscating it (e.g., hashing the content item).

[0120] Figure 7 shows an exemplary method 700 implemented by the receiving unit 501 according to some embodiments of the present invention. It will be understood that some steps of method 700 are optional and some steps may not be shown. In step 701, a probability filter is obtained (e.g., received from the transmitting side 502). In step 702, a blockchain transaction is obtained (e.g., received from the user 103). In step 703, a membership test is performed, that is, it is checked whether the candidate data item is recorded in the filter. In step 704, the transaction is processed according to the result of the membership test.

[0121] Exemplary use cases Safe wallet application A wallet application (i.e., a blockchain client application) may use the present invention for security improvement. A wallet application, hereinafter referred to as a "safe wallet", has enhanced security to support users and other entities. A safe wallet application is a blockchain application that protects the allocation of digital assets by preventing transactions to unauthorized or unapproved wallets. Two main types of safe wallets can be designed: a Blacklisting Safe Wallet and a Whitelisting Safe Wallet. The Blacklisting Safe Wallet allows digital assets to be allocated to all addresses except those inserted into a specific list of prohibited addresses called the blacklist. Conversely, the Whitelisting Safe Wallet allows digital assets to be allocated only to a list of pre-approved addresses called the whitelist. As the number of addresses included in the blacklist or whitelist increases, these lists become impractical to transfer and store on devices (e.g., mobile applications) with limited resources (due to their size). Further, searching within the list is time-consuming from a computational perspective and exposes the addresses, causing privacy issues. The present invention overcomes these problems by storing (i.e., representing) addresses in a probabilistic filter, which is a very efficient structure from both computational and storage perspectives. The probabilistic filter is lightweight and can be transmitted to lightweight nodes quickly, so multiple filters (e.g., created by different institutions) can be provided.

[0122] The blacklist can be provided and enforced by the country's various institutions. Therefore, the probabilistic filter can be jurisdiction-dependent and enable domestic courts to comply with internal regulations (e.g., for banning illegal materials). The whitelist can be created by enterprises to provide certain services and enhance security (e.g., enabling digital assets to be transferred only between corporate wallets).

[0123] Another advantage of the probabilistic filter is that the address is not explicitly remembered and transmitted (only the sending side 502 that creates the filter knows the address). This mode is beneficial when privacy is a concern. For example, an institution may be interested in blocking illegal funds without explicitly disclosing the amount of funds or the exact address.

[0124] Depending on specific applications (e.g., privacy vs. accuracy, the need to remove elements), a Bloom filter or a Cuckoo filter can be implemented in the safe wallet.

[0125] The blacklist-type safe wallet can be used to ban addresses related to fraud, illegal content, or criminal activities. A trustworthy institution 502 can create a probabilistic filter that records all blacklisted addresses. Then, the filter is sent to all secure wallet applications 501. These wallet applications then test the address before signing a transaction. If the address is blacklisted, the transaction is not signed and the transfer is rejected. This is schematically shown in Figure 6a.

[0126] In a probabilistic filter, detection failures can never occur, so if an element is not within the filter, it can always be considered safe. On the other hand, elements that match the filter may need to be double-checked to eliminate false detections. This means that a wallet application implementing a probabilistic blacklist may require quick checks (e.g., using a filter) for all outgoing transactions. A very small percentage of transactions may require further time-consuming checks (e.g., by querying an institutional database) to detect whether the address is actually blacklisted or if it is a false detection.

[0127] A whitelist-based secure wallet can be used when the wallet application should only sign transactions that assign digital assets to pre-approved addresses. An example of a possible application of a whitelist is a business wallet application that may only be permitted to send digital assets to a wallet application of a provider or other company. This prevents fraud and typing errors. Similarly, a game wallet application can set a whitelisting filter to only send transactions to addresses related to the same game. The whitelisting filter can be created by recording all addresses required for a particular service or application. The transaction is only completed if the membership test is positive. This is shown schematically in FIG. 6b.

[0128] Since probabilistic filters have false detections, in rare situations, an address not inserted into the whitelist may pass the membership test. However, the probability of accidentally (e.g., due to a typing error of the address) or intentionally (e.g., for fraud) generating an address that passes the membership test is close to zero.

[0129] Safe blockchain node The present invention can be used by node 104. An effective method of preventing fraud and confiscating illegal funds is to prevent related digital assets from being assigned to other users. A blacklisting safe node is node 104 that implements blacklisting techniques. Like blacklist-type safe wallets, they implement a probabilistic filter to prohibit transactions associated with specific addresses. The filter can be applied to incoming transactions, and when node 104 receives a transaction within the blacklist, these transactions are marked as invalid and not processed. If most of node 104 agrees to the blacklist and regards transactions coming from their wallets as invalid, the remaining node 104 is forced to discard these transactions if they desire their new block 151 to be accepted by the majority of network 106. To prevent censorship, the blacklist filter preferably needs to be provided by a domestic or international institution and approved by a court.

[0130] Using a whitelisting safe node, all incoming transactions can be filtered to accept only those coming from known addresses. Whitelisting incoming transactions can be useful when a node wants to prioritize or propagate only transactions received from a specific wallet application. As an example, node 104 can decide to sell premium services (e.g., priority confirmation of transactions, zero-fee transactions, etc.). A game with time constraints and a betting application can set up node 104 to receive information and provide it only to its customers. In contrast to a blacklisting safe node, a whitelisting safe node does not necessarily have to invalidate transactions that are not on the whitelist. Instead, these transactions can be accepted when they are published in a new block by other nodes 104. A whitelisting safe node may simply reject holding these transactions because non-whitelisted transactions within an ordered set of unpublished transactions 154 are not applicable to their business model.

[0131] Blacklisting of Transactions and Transaction Content The filtering address can be implemented at both the wallet application level and the node level. However, the reasons for which a transaction should be prohibited or permitted are not only the address. Instead, there are scenarios where a particular transaction may contain illegal content, and the prohibition should only apply to those particular transactions or the specific content contained therein. For example, an address may be linked to a transaction with illegal content, in which case only that particular transaction should be prohibited, but not all previous (legitimate) transactions linked to that address. This can be the case for addresses used to create some transactions (e.g., a list of documents or photos). If the private key of one of these addresses is stolen and used to create an illegal transaction, only those transactions should be prohibited, while older content should remain valid and available on-chain (therefore, prohibiting the address is neither effective nor fair). In other cases, specific content can be blocked regardless of the address or transaction containing it (many users may try to submit the same illegal content to bypass address- or transaction-specific filters).

[0132] To prohibit transactions having specific content inside, the transaction ID can be recorded in the probabilistic filter in the same way as the address. Since the transaction ID or the whole transaction is hashed before being recorded in the probabilistic filter (and the hash has the same format as that used to record the address), the probabilistic filter used to record the transaction may be the same as or different from that used to blacklist the address. By using this technique, not only the address but also specific transactions can be prohibited. This technique can be used at both the node level (e.g., to globally prohibit illegal content) or the wallet application level (e.g., to prohibit specific content in a business environment).

[0133] An alternative way to prohibit on-chain illegal content is to record the undesirable transaction content in a probabilistic filter (instead of the transaction ID). For example, everything after the OP_RETURN instruction can be recorded. All content included in a problematic transaction after OP_RETURN can be hashed and inserted into the probabilistic filter. Any other transaction containing the same content can be easily detected and rejected (if trying to submit a new transaction with the same content), or supplied without content after OP_RETURN (if the transaction is already public within a block). Another advantage of this technique is that it enables the detection of illegal material without explicitly storing that material (the institution can keep a record of the material and send only the probabilistic filter to nodes 104 and wallet application 105). Additionally, probabilistic filters containing problematic content identified by a public institution and not yet public on blockchain 150 can be created prophylactically, which enables prophylactic control of the content before it is published on the block (e.g., recording copyrightable material in the filter to prevent unauthorized upload to blockchain 150). To prevent simple evasion measures, such as changing only 1 bit within the content (which would result in a completely different hash not recorded in the probabilistic filter), different pre-defined parts of OP_RETURN can be hashed and recorded. For example, a basic technique could be to split the content into chunks, hash each chunk, and record those hashes in the filter. All content after OP_RETURN of a transaction can be tested chunk by chunk, and if one of them is positive, the transaction is either rejected or supplied without OP_RETURN content (e.g., published). Furthermore, the scalability of this technique can be adapted to the attempts of adversaries trying to upload illegal content.That is, if blacklisting and checking is about as efficient as an adversary generating an illegal content transaction, this may be sufficient to deter the adversary. Further, while adding new content to the filter is free, creating new transactions is costly. This discourages attackers.

[0134] Analysis and Example of Probability Filter Construction of Probability Filter The following example illustrates how to create a Bloom filter for blacklisting three addresses. The filter has a 10% false positive rate (this example uses a high false positive rate to reduce the number of hash functions and simplify the example without loss of generality).

Number

Number

Number

Number

Number

[0135] Filter Size and Scalability In the following section, we analyze how the probabilistic filter size grows with the number of elements inserted. The size of the filter is calculated as follows:

Number

[0136] The size of the filter depends only on the false positive rate (fpp), the load (for Cuckoo filters only), and the number of elements inserted. Probabilistic filters do not depend on the size of the input since these filters store only the input hash (which has a fixed size).

[0137] The filter size is compared to a list of addresses storing the same number of elements. The size of blockchain addresses in some blockchains is 25 bytes and consists of the following components:

Number

[0138] The following parameters are assumed: · False positive rate (fpp) = 0.1% · Filter load (for Cuckoo filters only) = 95%

Table 1

[0139] The above table shows the size of a list storing a given amount of addresses, the Bloom filter, and the Cuckoo filter. As the number of addresses to be stored increases, the list of addresses begins to suffer from scalability problems, especially in the case of lightweight applications (in extreme cases, they would need to receive and store 2.5 GB of data to blacklist 100 million addresses). To store transaction IDs or transaction content (e.g., everything after OP_RETURN), even more space is required, and the use of probabilistic filters becomes even more convenient. Compared to a list of transaction IDs (32 bytes each), the Bloom filter has a compression rate of 94.7%, and the Bloom filter has a compression rate of 95.4%. The compression rate is even more important when compared to a list of transaction content to be prohibited (e.g., images). For example, considering small images (e.g., 50 KB each) that can be stored on-chain, the Bloom filter can record them with a compression rate of 99.997%, i.e., it is possible to prohibit 1000 images (50 KB) by transferring only a 1.5 KB filter to a lightweight wallet.

[0140] Node 104 can experience less burden when it has to process an exemplary list size. However, the list takes time to look up and privacy cannot be guaranteed (all addresses or content may be explicitly listed). Therefore, a system for rapid membership testing is also useful for Node 104. A possible implementation on Node 104 can include holding a probabilistic filter in memory (e.g., RAM) for rapid testing and storing a list for verification of possible false detections on disk (or querying an institutional database when privacy is a concern).

[0141] Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art upon the disclosure provided herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0142] For example, some of the above embodiments have been described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150 and the above description may generally apply to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any of the above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may each be replaced by a reference to a blockchain network 106, a blockchain 150, and a blockchain node 104. The blockchain, the blockchain network, and / or the blockchain node may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 described above.

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

[0144] In a non-preferred embodiment of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing a block 151 of the blockchain 150. For example, on other blockchain networks, the term "node" may be used to refer to a network entity configured to create and publish a block 151 but not store and / or propagate those blocks 151 to other nodes.

[0145] Even more generally, any reference to the term "Bitcoin node" 104 above may be replaced with the term "network entity" or "network element", and such entity / element is configured to perform some or all of the roles of block creation, publication, propagation, and storage. The functions of such network entity / element may be implemented in hardware in the same manner as described above with reference to the blockchain node 104.

[0146] It will be understood that the above embodiments are merely illustrative. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0147] Statement 1. A computer-implemented method for processing blockchain transactions, the method being performed by a receiving side, obtaining one or more probabilistic filters, each probabilistic filter encoding one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items, A step of obtaining a blockchain transaction, wherein the obtained blockchain transaction is associated with a candidate data item corresponding to i) one of one or more sets of whitelisted data items, or ii) one of one or more sets of blacklisted data items, and A step of determining whether to process the obtained blockchain transaction based on whether the candidate data item exists in at least one of one or more probability filters A method including.

[0148] Statement 2. The method according to statement 1, wherein one of one or more sets of whitelisted data items includes a set of whitelisted blockchain addresses, one of one or more sets of blacklisted data items includes a set of blacklisted blockchain addresses, and the candidate data item is a candidate blockchain address.

[0149] For example, the candidate blockchain address may be the destination address corresponding to the output of the obtained blockchain transaction. Alternatively, the candidate blockchain address may be an address associated with an output that attempts to be used by the input of the obtained blockchain transaction.

[0150] Statement 3. The method according to statement 2, wherein the step of determining whether to process the obtained blockchain transaction includes the step of determining whether to sign the obtained blockchain transaction with a digital signature associated with the receiving side.

[0151] Statement 4. The method according to statement 3, wherein i) At least one probabilistic filter encodes a set of whitelisted blockchain addresses, by signing the obtained blockchain transaction on the condition that the candidate blockchain address exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain addresses, by signing the obtained blockchain transaction on the condition that the candidate blockchain address does not exist in at least one probabilistic filter, Method.

[0152] That is, the receiving party can be a user who receives a request to sign the obtained blockchain transaction with a digital signature associated with the user.

[0153] Preferably, the obtained blockchain transaction is signed only if the candidate address does not exist in any of the filters.

[0154] Statement 5. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to accept the obtained blockchain transaction for publication in a block of the blockchain, the method described in Statement 2.

[0155] That is, the receiving party can be a blockchain node that receives a request to publish the obtained blockchain transaction in a new block of the blockchain.

[0156] Statement 6. The method described in Statement 5, wherein i) At least one probabilistic filter encodes a set of whitelisted blockchain addresses, and the method includes the step of accepting an obtained blockchain transaction on the condition that a candidate blockchain address exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain addresses, and the method includes the step of accepting an obtained blockchain transaction on the condition that a candidate blockchain address does not exist in at least one probabilistic filter. Method.

[0157] Preferably, the obtained blockchain transaction is accepted only if the candidate address does not exist in any filter.

[0158] Statement 7. The step of accepting the obtained blockchain includes the step of prioritizing the obtained blockchain transaction over one or more other blockchain transactions for publication in the blocks of the blockchain, the method according to Statement 6.

[0159] Statement 8. The step of obtaining a blockchain transaction includes the step of obtaining a block containing the blockchain transaction, and the step of determining whether to process the obtained blockchain transaction includes the step of determining whether to validate the block containing the obtained blockchain transaction, the method according to Statement 2.

[0160] That is, the receiving side can be a blockchain node in the process of validating a block, such as a block published by a different blockchain node, for example, a node that does not process transactions using a filter. The receiving side can accept or reject the obtained block according to the result of the membership test.

[0161] Statement 9. The method described in Statement 8, i) At least one probabilistic filter encodes a set of whitelisted blockchain addresses, and the method includes validating the obtained block on the condition that the candidate blockchain address exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain addresses, and the method includes validating the obtained block on the condition that the candidate blockchain address does not exist in at least one probabilistic filter. Method.

[0162] Statement 10. One or more sets of whitelisted data items include a set of whitelisted unused transaction outputs, and one or more sets of blacklisted data items include a set of blacklisted unused transaction outputs, and the candidate data item is a candidate unused transaction output referenced by the obtained blockchain transaction, the method described in any of the preceding statements.

[0163] That is, the candidate unused transaction output is the output of a previous blockchain transaction referenced by the input of the obtained blockchain transaction.

[0164] Statement 11. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to sign the transaction or accept the blockchain transaction referenced for publication in the block of the blockchain, as described in Statement 10.

[0165] For example, a user may sign the transaction or a node may accept the transaction.

[0166] Statement 12. The method described in Statement 11, i) At least one probabilistic filter encodes a set of whitelisted unused transaction outputs, and the method includes the step of signing the obtained blockchain transaction or accepting the obtained blockchain transaction on the condition that a candidate unused blockchain transaction exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted unused transaction outputs, and the method includes the step of signing the obtained blockchain transaction or accepting the obtained blockchain transaction on the condition that a candidate blockchain unused transaction output does not exist in at least one probabilistic filter. Method.

[0167] Statement 13. One or more sets of whitelisted data items include a set of whitelisted blockchain transaction identifiers, one or more sets of blacklisted data items include a set of blacklisted blockchain transaction identifiers, and the candidate data item is the candidate transaction identifier of the obtained blockchain transaction, as described in any of the preceding statements.

[0168] Step 14. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to send the obtained blockchain transaction to a third party, which is the method described in Statement 13.

[0169] For example, a third party may request access to the obtained transaction.

[0170] Statement 15. The method described in Statement 14, i) At least one probabilistic filter encodes a set of whitelisted blockchain transaction identifiers, and the method includes the step of sending the obtained blockchain transaction to a third party on the condition that the candidate blockchain transaction identifier exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain transaction identifiers, and the method includes the step of sending the obtained blockchain transaction to a third party on the condition that the candidate blockchain transaction identifier does not exist in at least one probabilistic filter. Method.

[0171] Statement 16. One or more sets of whitelisted data items include a set of whitelisted transaction contents, one or more sets of blacklisted data items include a set of blacklisted transaction contents, and the candidate data item is a candidate transaction content item of the obtained blockchain transaction, which is the method described in any of the preceding statements.

[0172] For example, transaction content can be some or all of the output of a transaction (e.g., OP_RETURN output). The transaction content may include one or more of an image file, an audio file, a video file, etc.

[0173] Statement 17. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to send the obtained blockchain transaction to a third party, and is the method described in Statement 16.

[0174] Statement 18. The method described in Statement 17, i) At least one probabilistic filter encodes a set of whitelisted blockchain transaction content, and the method includes the step of sending the obtained blockchain transaction to a third party on the condition that candidate blockchain transaction content items are present in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain transaction identifiers, and the method includes the step of sending the obtained blockchain transaction to a third party on the condition that candidate blockchain transaction identifiers are not present in at least one probabilistic filter. Method.

[0175] Statement 19. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to accept the obtained blockchain transaction for publication in a block of the blockchain, and is the method described in Statement 16.

[0176] Statement 20. The method described in Statement 19, i) At least one probabilistic filter encodes a set of whitelisted blockchain transaction contents, the method including the step of accepting the obtained blockchain transaction on condition that a candidate blockchain transaction content item exists in at least one probabilistic filter, or ii) At least one probabilistic filter encodes a set of blacklisted blockchain transaction identifiers, the method including the step of accepting the obtained blockchain transaction by a third party on condition that a candidate blockchain transaction identifier does not exist in at least one probabilistic filter, A method.

[0177] Statement 21. The set of whitelisted transaction content items includes a set of whitelisted tokens, the set of blacklisted transaction content items includes a set of blacklisted tokens, and the candidate data item is a candidate token, the method as described in Statement 16 or any statement subordinate thereto.

[0178] Statement 22. A computer-implemented method for controlling access to some or all of a blockchain transaction, the method being executed by a sender, generating one or more probabilistic filters, each probabilistic filter encoding one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items, sending the one or more probabilistic filters to a receiver A method including.

[0179] Statement 23. The one or more sets of whitelisted data items are a set of whitelisted blockchain addresses, A set of whitelisted unused transaction outputs, A set of whitelisted blockchain transaction identifiers, A set of whitelisted transaction content items, and A set of whitelisted tokens including one, some, or all of: The method described in statement 22.

[0180] Statement 24. One or more sets of blacklisted data items are A set of blacklisted blockchain addresses, A set of blacklisted unused transaction outputs, A set of blacklisted blockchain transaction identifiers, A set of blacklisted transaction content items, and A set of blacklisted tokens including one, some, or all of: The method described in statement 22 or 23.

[0181] Statement 25. The sender is the first blockchain node, the method described in any of statements 22 to 24.

[0182] Statement 26. The sender is a trusted institution, the method described in any of statements 22 to 24.

[0183] For example, a trusted institution can be a legal institution or a token institution.

[0184] Statement 27. The receiver is the second blockchain node, the method described in any of statements 22 to 26.

[0185] Statement 28. A computer device, a memory comprising one or more memory units, a processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code being configured to execute the method described in any of Statements 1 to 27 when on the processing device, the processing device, comprising a computer device.

[0186] Statement 29. A computer program embodied on a computer-readable storage, the computer program being configured to execute the method described in any of Statements 1 to 27 when executed on the computer device described in Statement 28.

[0187] According to another aspect disclosed herein, a method may be provided that includes actions of a sending entity and a receiving entity.

[0188] According to another aspect disclosed herein, a system may be provided that includes computer devices of a sending entity and a receiving entity.

Claims

1. A computer-implemented method for processing blockchain transactions, the method being executed by a receiving side, obtaining one or more probabilistic filters, each probabilistic filter encoding one of: i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items; obtaining a blockchain transaction, the obtained blockchain transaction being associated with candidate data items corresponding to one of: i) one or more sets of the whitelisted data items, or ii) one or more sets of the blacklisted data items; determining whether to process the obtained blockchain transaction based on whether the candidate data items are present in at least one of the one or more probabilistic filters A method comprising the steps of:

2. The method according to claim 1, wherein one of the one or more sets of whitelisted data items comprises a set of whitelisted blockchain addresses, one of the one or more sets of blacklisted data items comprises a set of blacklisted blockchain addresses, and the candidate data items are candidate blockchain addresses.

3. The method according to claim 2, wherein the step of determining whether to process the obtained blockchain transaction comprises determining whether to sign the obtained blockchain transaction with a digital signature associated with the receiving side.

4. i) At least one probabilistic filter encodes the set of whitelisted blockchain addresses, and the method comprises signing the obtained blockchain transaction on condition that the candidate blockchain address is present in the at least one probabilistic filter, or ii) At least one of the probability filters encodes the set of the blacklisted blockchain addresses, and the method includes signing the obtained blockchain transaction on the condition that the candidate blockchain address does not exist in the at least one probability filter. The method according to claim 3.

5. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to accept the obtained blockchain transaction for publication in a block of the blockchain. The method according to claim 2.

6. i) At least one probability filter encodes the set of the whitelisted blockchain addresses, and the method includes accepting the obtained blockchain transaction on the condition that the candidate blockchain address exists in the at least one probability filter, or ii) At least one probability filter encodes the set of the blacklisted blockchain addresses, and the method includes accepting the obtained blockchain transaction on the condition that the candidate blockchain address does not exist in the at least one probability filter. The method according to claim 5.

7. The step of accepting the obtained blockchain transaction includes the step of prioritizing the obtained blockchain transaction over one or more other blockchain transactions for publication in a block of the blockchain. The method according to claim 6.

8. The step of obtaining the blockchain transaction includes the step of obtaining a block including the blockchain transaction, and the step of determining whether to process the obtained blockchain transaction includes the step of determining whether to verify the validity of the block including the obtained blockchain transaction. The method according to claim 2.

9. i) At least one probabilistic filter encodes the set of the whitelisted blockchain addresses, and the method includes validating the obtained block on the condition that the candidate blockchain address exists in the at least one probabilistic filter, or ii) At least one probabilistic filter encodes the set of the blacklisted blockchain addresses, and the method includes validating the obtained block on the condition that the candidate blockchain address does not exist in the at least one probabilistic filter, The method according to claim 8.

10. One of the one or more sets of the whitelisted data items includes a set of whitelisted unspent transaction outputs, one of the one or more sets of the blacklisted data items includes a set of blacklisted unspent transaction outputs, and the candidate data item is a candidate unspent transaction output referenced by the obtained blockchain transaction. The method according to any one of claims 1 to 9.

11. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to sign the transaction or accept the referenced blockchain transaction for publication in a block of the blockchain. The method according to claim 10.

12. i) At least one probabilistic filter encodes the set of the whitelisted unspent transaction outputs, and the method includes the step of signing the obtained blockchain transaction or accepting the obtained blockchain transaction on the condition that the candidate unspent blockchain transaction exists in the at least one probabilistic filter, or ii) At least one probabilistic filter encodes the set of the blacklisted unspent transaction outputs, and the method includes signing the obtained blockchain transaction or accepting the obtained blockchain transaction on the condition that the candidate blockchain unspent transaction output does not exist in the at least one probabilistic filter. The method according to claim 11. **Claim 13** One or more sets of the whitelisted data items include a set of whitelisted blockchain transaction identifiers, one or more sets of the blacklisted data items include a set of blacklisted blockchain transaction identifiers, and the candidate data item is a candidate transaction identifier of the obtained blockchain transaction. The method according to any one of claims 1 to 12. **Claim 14** The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to send the obtained blockchain transaction to a third party. The method according to claim 13. **Claim 15** i) At least one probabilistic filter encodes the set of the whitelisted blockchain transaction identifiers, and the method includes sending the obtained blockchain transaction to the third party on the condition that the candidate blockchain transaction identifier exists in the at least one probabilistic filter, or ii) At least one probabilistic filter encodes the set of the blacklisted blockchain transaction identifiers, and the method includes sending the obtained blockchain transaction to the third party on the condition that the candidate blockchain transaction identifier does not exist in the at least one probabilistic filter. The method according to claim 14. **Claim 16** One or more sets of the whitelisted data items include a set of whitelisted transaction contents, one or more sets of the blacklisted data items include a set of blacklisted transaction contents, and the candidate data items are candidate transaction content items of the obtained blockchain transaction. The method according to any one of claims 1 to 15.

17. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to send the obtained blockchain transaction to a third party. The method according to claim 16.

18. i) At least one probability filter encodes the set of the whitelisted blockchain transaction contents, and the method includes the step of sending the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction content item exists in the at least one probability filter, or ii) At least one probability filter encodes the set of the blacklisted blockchain transaction identifiers, and the method includes the step of sending the obtained blockchain transaction to the third party on condition that the candidate blockchain transaction identifier does not exist in the at least one probability filter. The method according to claim 17.

19. The step of determining whether to process the obtained blockchain transaction includes the step of determining whether to accept the obtained blockchain transaction for publication in a block of the blockchain. The method according to claim 16.

20. i) At least one probability filter encodes the set of the whitelisted blockchain transaction contents, and the method includes the step of accepting the obtained blockchain transaction on condition that the candidate blockchain transaction content item exists in the at least one probability filter, or ii) At least one probabilistic filter encodes the set of the blacklisted blockchain transaction identifiers, and the method includes accepting, for a third party, the obtained blockchain transaction on the condition that the candidate blockchain transaction identifier does not exist in the at least one probabilistic filter. The method according to claim 19. **Claim 21** The set of the whitelisted transaction content items includes a set of whitelisted tokens, the set of the blacklisted transaction content items includes a set of blacklisted tokens, and the candidate data item is a candidate token. The method according to any one of claim 16 or the claims dependent thereon. **Claim 22** A computer-implemented method for controlling access to some or all of blockchain transactions, the method being executed by a sending side, generating one or more probabilistic filters, each probabilistic filter encoding one of i) one or more sets of whitelisted data items, or ii) one or more sets of blacklisted data items, sending the one or more probabilistic filters to a receiving side The method comprising. **Claim 23** The one or more sets of the whitelisted data items are a set of whitelisted blockchain addresses, a set of whitelisted unspent transaction outputs, a set of whitelisted blockchain transaction identifiers, a set of whitelisted transaction content items, and a set of whitelisted tokens including one, some, or all of The method according to claim 22. **Claim 24** The one or more sets of the blacklisted data items are a set of blacklisted blockchain addresses, a set of blacklisted unspent transaction outputs, a set of blacklisted blockchain transaction identifiers, a set of blacklisted transaction content items, and a set of blacklisted tokens including one, several, or all of The method according to claim 22 or 23. **Claim 25** The method according to any one of claims 22 to 24, wherein the transmitting side is a first blockchain node. **Claim 26** The method according to any one of claims 22 to 24, wherein the transmitting side is a reliable institution. **Claim 27** The method according to any one of claims 22 to 26, wherein the receiving side is a second blockchain node. **Claim 28** A computer device, a memory comprising one or more memory units, a processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, and the code, when on the processing device, is configured to execute the method according to any one of claims 1 to 27, a processing device comprising a computer device. **Claim 29** A computer program embodied on a computer-readable storage, which, when executed on the computer device according to claim 28, is configured to execute the method according to any one of claims 1 to 27.

Images