Method and System for Freezing Digital Assets

Abstract

System and computer-implemented method for freezing or thawing digital assets on a blockchain. A freezing management service may send a signed freezing request to a mining node that maintains two blacklists of digital asset identifiers, a pending blacklist and a consensus blacklist. The digital asset identifier may, in some cases, be a transaction outpoint. If accepted by the mining node, the transaction outpoints in the freezing request are added to the pending blacklist, whereby any transaction using those outpoints is rejected, but any new block containing a transaction using those outpoints is not rejected. When a consensus threshold of acceptance based on hash power is reached, the request becomes an order and the outpoints are added to the consensus blacklist, whereby any transaction or block containing a transaction using those outpoints is rejected.

Description

Technical Field

[0001] The present disclosure relates to a blockchain network, and more particularly, to methods and devices for generating and performing a freezing operation with respect to digital assets recorded on a blockchain network.

Background Art

[0002] A blockchain refers to a form of a distributed data structure, and a replicated copy of the blockchain is maintained at each of a plurality of nodes within a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely public. Transactions within a blockchain are used to perform one or more of carrying digital assets (i.e., some digital tokens), ordering a set of entries in a virtual ledger or register, receiving and processing timestamp entries, and / or ordering index pointers in chronological order.

[0003] In an "output-based" model (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 an amount of digital assets derivable from a previous sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs") or "outpoints". In some cases, the protocol may refer to sender and receiver addresses rather than "outputs" or "outpoints". An output may further include a lock script that specifies the conditions for future redemption of the output. The lock script is a predicate that defines the conditions necessary for validating and transferring digital tokens or assets. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction and may further include an unlocking script for unlocking the lock script of the indicated output.

[0004] In particular, in the cryptocurrency community, one of the main attractions of blockchain technology is its decentralized consensus-based implementation mechanism that eliminates the need for a trusted institution or intermediary for transactions. However, problems arise because there is no available mechanism to freeze digital assets or cancel or reverse transactions in stolen assets without forcing network-wide software changes and / or rollback of mined blocks in the event of fraud or theft.

Brief Description of the Drawings

[0005] Here, by way of example, reference is made to the accompanying drawings that illustrate exemplary embodiments of the present application.

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

[0006] In the drawings, like reference numerals are used to indicate like elements and features.

Modes for Carrying Out the Invention

[0007] In one aspect, a computer-implemented method for freezing digital assets at a mining node within a blockchain network may be provided. The method includes receiving and validating a freeze request message from a freeze management service, the freeze request message including one or more digital asset identifiers; adding the one or more digital asset identifiers to a pending blacklist stored at the mining node, wherein a new transaction received via the blockchain network that includes an identifier on the pending blacklist is rejected by the mining node, but a new block received via the blockchain network that includes an identifier on the pending blacklist is acceptable; receiving and validating a freeze order from the freeze management service, the freeze order identifying the freeze request message; and in response to the freeze order, adding the one or more digital asset identifiers to a consensus blacklist, wherein both a subsequent transaction that includes an identifier on the consensus blacklist and a subsequent block that includes an identifier on the consensus blacklist are rejected by the mining node.

[0008] In some implementations, the method may further include generating an acceptance message regarding the freeze request message in response to receiving and validating the freeze request message; digitally signing the acceptance message using a key associated with the mining node to generate a signed acceptance message; and sending the signed acceptance message to the freeze management service.

[0009] In some implementations, the digital asset identifier includes a transaction outpoint identifier.

[0010] In some implementations, after receiving and validating a freezing request message and before receiving and validating a freezing command, the method may further include receiving a new transaction via a blockchain network, determining that the new transaction has at least one of one or more digital asset identifiers on a pending blacklist as an input, and in response, rejecting the new transaction.

[0011] In some implementations, after receiving and validating a freezing request message and before receiving and validating a freezing command, the method may further include identifying a new block mined by another mining node, determining that at least one transaction in the new block has at least one of one or more digital asset identifiers on a pending blacklist as an input, and validating and propagating the new block according to a blockchain protocol that manages the blockchain network despite one or more digital asset identifiers on the pending blacklist.

[0012] In some implementations, the method may further include identifying any transaction having at least one of one or more digital asset identifiers as an input in response to a freezing request message and removing it from the mempool of pending transactions.

[0013] In some implementations, before receiving and validating a freezing command, the method includes receiving and validating a thawing request message from a freezing management service, where the thawing request message identifies the freezing request message and, in response, removes one or more digital asset identifiers from the pending blacklist.

[0014] In some implementations, the method may further include, after receiving and validating a freeze command, receiving and validating a thaw request message from a freeze management service, the step of identifying the thaw request message as the freeze request message, the step of sending an acceptance message regarding the thaw request message to the freeze management service, then receiving and validating a thaw command referring to the thaw request message, and in response, removing one or more digital asset identifiers from the consensus blacklist and the pending blacklist.

[0015] In another aspect, the present application discloses a computer-implemented method for freezing digital assets at a mining node within a blockchain network. The method includes generating, at a freeze management service, a freeze request message that includes one or more digital asset identifiers, sending the freeze request message to a plurality of mining nodes, receiving and validating, from a set of the plurality of mining nodes, an acceptance message as a response to the freeze request message, each acceptance message being associated with one mining node within the set of the plurality of mining nodes, determining that the set of the plurality of mining nodes represents hash power exceeding a consensus threshold amount in the blockchain network, and in response, generating and sending to the plurality of mining nodes a freeze command for causing rejection of a new block including a transaction using any of the one or more digital asset identifiers.

[0016] In some implementations, one or more digital asset identifiers include one or more transaction outpoint identifiers. Optionally, the method may further include receiving, first, from a client device, an instruction that includes one or more addresses, and identifying, using a blockchain address indexer, one or more transaction outpoint identifiers based on the one or more addresses.

[0017] In some implementations, the step of determining that a set of multiple mining nodes represents hash power exceeding a consensus threshold amount in a blockchain network includes determining that the number of blocks within a window of the most recently mined blocks mined by one of the mining nodes within the set exceeds a threshold consensus number. Optionally, the method may further include, for each acceptance message, identifying each mining node within the set by identifying each public key associated with each digital signature on the acceptance message, and detecting an association between the blocks within the window of the most recently mined blocks and one of the mining nodes within the set by matching each public key with a public key within a coinbase transaction within the block.

[0018] In some implementations, the step of determining that a set of multiple mining nodes represents hash power exceeding a consensus threshold amount in a blockchain network is triggered by receipt of a new acceptance message.

[0019] In some implementations, the step of determining that a set of multiple mining nodes represents hash power exceeding a consensus threshold amount in a blockchain network is triggered by identifying a newly mined block on the blockchain network.

[0020] In a further aspect, the present application describes a computing device having a memory, one or more processors, and computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the one or more processors to perform at least one of the methods described herein.

[0021] In yet another aspect, a computer-readable medium storing processor-executable instructions that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein may be provided.

[0022] Other exemplary embodiments of the present disclosure will become apparent to those of ordinary skill in the art upon review of the following detailed description in conjunction with the drawings.

[0023] In the present application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the recited elements, including any one of the recited elements alone, any sub-combination, or all of the elements, without necessarily excluding additional elements.

[0024] In the present application, the expression "at least one of... or..." is intended to cover any one or more of the recited elements, including any one of the recited elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements and without necessarily requiring all of the elements.

[0025] Some of the examples provided below use the Bitcoin protocol as an illustrative example to demonstrate concepts. This application is not limited to implementations using that protocol, and it should be understood that this application can be applied to other blockchain protocols such as account-based protocols including Ethereum. To the extent that specific terms are considered to be limited to UTXO-based blockchains, they should be understood to have definitions that are not protocol-specific. For example, the terms "transaction output point" or "transaction output point identifier" should be understood to refer to an identifier of a specific "spendable" or transferable digital asset resulting from a blockchain transaction. A transaction output point or transaction output point identifier typically has one or more conditions associated with the ability to use or transfer that asset, such as verification of the digital signature associated with the wallet address that the transaction output point references. The term "digital asset identifier" can be used to refer to a transaction output point, a wallet address, a public key from which a wallet address can be derived, or other identifiers that can be used in a given blockchain protocol to accurately identify the sender and recipient of a digital asset in a transaction.

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

[0027] Each blockchain node 104 includes peer computer devices, and different ones of the nodes 104 belong to different peers. Each blockchain node 104 includes one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and a processing device implemented by other devices such as application-specific integrated circuits (ASICs). Each node also includes memory, that is, computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may include one or more memory media, for example, one or more memory units employing 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.

[0028] 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 specifies an amount representing a digital asset as a property, an example of which is a user 103 where the output is cryptographically locked (requiring the 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.

[0029] 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 blocks 151. Each transaction 152 (other than the coinbase transaction) has a pointer back to the previous transaction to define the order into the sequence of transactions (note: the sequence of transactions 152 can branch). The chain of blocks 151 goes all the way back to the genesis block (Gb: genesis block) 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 a previous transaction.

[0030] 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. It 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 outputs.

[0031] In a given current transaction 152j, the input (or each input) includes a pointer that references an 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 must exist and be verified for validity for the current transaction to be valid, but the preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or when it is 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.

[0032] The input of the current transaction 152j also includes an input authorization, e.g., the signature of the user 103a whose 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 can have multiple outputs to divide the input amount among multiple users or entities, one of which can be the original user or entity 103a to give the remainder (change). In some cases, the transaction can 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.

[0033] 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 a 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, not 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 in 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 preceding transaction 152i that the new transaction allocates, 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 preceding transaction 152i. Alternatively, it may be fixed solely by the blockchain node protocol or by a combination of these.In any case, if the 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 test according to the same blockchain node protocol, 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.

[0034] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated 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 allocate or redeem has not yet been allocated / redeemed by another transaction. Similarly in this case, if it is not valid, the transaction 152j will neither be propagated (unless flagged as invalid and propagated for warning) nor recorded in the blockchain 150. This prevents double-spending where a transactor attempts to allocate the output of the same transaction multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Here too, since the transaction order is defined, the account balance is always in a single defined state.

[0035] 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, which is supported by "proof of work". At 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 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 certain 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 property of a hash function is that it has an output that is unpredictable with respect to its input. Therefore, this search can only be performed by brute force, consuming a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0036] The first blockchain node 104 to solve the puzzle publishes this fact to the network 106 and provides as proof its solution, which can later be easily checked by other blockchain nodes 104 within the network (it is easy to check if the output of a hash meets the criteria when given the solution for the hash). This first blockchain node 104 propagates the block to the threshold consensus of other nodes that accept the block and enforce the protocol rules. Next, the ordered set of transactions 154 will then be recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104. A block pointer 155 that points to the previously created block 151n-1 in the chain is also assigned to the new block 151n. The significant amount of effort, e.g., in the form of a hash, required to create the proof of work solution 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 cannot be modified. The block pointer 155 also gives an order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each blockchain node 104 within the network 106, this provides an immutable public ledger of the transactions.

[0037] Note that different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of an ordered set 154 of transactions not yet published at any given time, depending on when they started searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 are included in the next new block 151n and in what order, and the current set 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to compete to create blocks from the newly defined, unprocessed ordered set of unpublished transactions 154, and so on. There is also a protocol for resolving any "forks" that may occur when two blockchain nodes 104 solve a puzzle within a very short time of each other and opposing views of the blockchain are propagated 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.

[0038] 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 the new block 151n. The proof of work indicates the intention that the protocol rules enable the node constructing the new block to be reimbursed for this special transaction at a later time. The blockchain protocol rules may require a maturity period, for example 100 blocks, before this special transaction can be reimbursed. Often, a normal (non-coinbase) transaction 152 also specifies an additional transaction fee in one of its outputs in order 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.

[0039] 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.

[0040] The memory of each blockchain node 104 stores software configured to execute one or more of its respective roles and to process transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to blockchain node 104 may be performed by software executed on the processing device of each respective computing 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.

[0041] Each computing device 102 of a plurality of parties 103 assuming the role of 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 blockchain node 104).

[0042] Some or all of the parties 103 may be connected as part of an overlay network overlaid on a different network, such as the blockchain network 106. Users of the blockchain network (often referred to as "clients") can be said to be part of the system that includes the blockchain network, 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 thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. Two parties 103 and their respective devices 102, namely, the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that there are many more such parties 103 and their respective computer devices 102 that can 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.

[0043] The computer device 102 of each party 103 includes respective processing devices 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, 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 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 such as respective instances of at least one client application 105 arranged 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, a tablet, a smartphone, or a 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.

[0044] 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, for example, it may be downloaded from a server or provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0045] 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), and send a transaction 152 to one or more Bitcoin nodes 104, thereby propagating the transaction 152 across the network of blockchain nodes 104 and causing it to be 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.

[0046] Although various client functions can be described as integrated into a given client application 105, it is not necessarily limited to this. Instead, any client function described herein can 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, client functions can be implemented in the application layer or a lower layer such as an operating system, or any combination thereof. In the following, the client application 105 will be described, but it is understood that it is not limited to this.

[0047] 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 the network 106. Thereby, the wallet function of the client 105 can send a transaction 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction for which each party 103 is the recipient (or, in an embodiment, since the blockchain 150 is a public facility that provides trust in transactions through its public visibility, actually inspect the transactions of other parties in the blockchain 150). The wallet function on each computer device 102 is configured to formulate and send a transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to validate a transaction 152 according to a blockchain node protocol and forward the transactions 152 to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and 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 the blockchain 150. The same node protocol is used by all nodes 104 within the network 106.

[0048] 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 Alice's 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 may include 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 defined by a combination of the script and the node protocol.

[0049] Conditioned on the newly received transaction 152j passing the tests for being considered valid (i.e., conditioned on it being "validated"), any blockchain node 104 that receives transaction 152j adds the new validated transaction 152 to the ordered set 154 of transactions maintained at that blockchain node 104. Further, any blockchain node 104 that receives transaction 152j propagates the validated transaction 152 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 immediately propagated across the entire network 106.

[0050] Once admission to the ordered set of transactions 154 maintained at a given blockchain node 104 is granted, that blockchain node 104 begins to compete to solve the 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. Since each transaction 152 includes a pointer back to the previous transaction, the order of the transactions is also immutably recorded.

[0051] 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).

[0052] Alternative types of transaction protocols employed by some blockchain networks may be referred to as "account - based" protocols as part of an account - based transaction model. In an 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 preceding 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 of an account (also called a "position") in progress. 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 may also be signed. This data field may, for example, indicate a previous transaction if the previous transaction ID is included in the data field.

[0053] 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). Hereinafter, 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 it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0054] In a UTXO-based model, each transaction ("Tx") 152 is a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not been redeemed yet). 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 may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201 that may contain an indicator indicating the size of the input field(s) 202 and output field(s) 203. The header 201 may also contain the ID of the transaction. In some embodiments, the transaction ID is the hash of the transaction data (excluding the transaction ID itself).

[0055] 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" 1」 is labeled. This takes the amount of digital assets locked to Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "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 preceding (i.e., earlier) transaction that still has an unused output 203 locked to Alice.

[0056] The preceding 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 a 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 the sequence of transactions, the terms "preceding" and "subsequent" refer to the order of transactions within the sequence defined by the transaction pointers specified within a transaction (such as which transaction refers to which other transaction). They can similarly be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "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 (later transaction or "child") that refers to a preceding transaction (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 can be buffered for a specific time or discarded while waiting for the parent.

[0057] Preceding transaction Tx 0 One of one or more outputs 203 of is herein referred to as UTXO 0and is a specific UTXO labeled as such. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a lock script, and the lock script defines the conditions that the unlock script within the input 202 of a subsequent transaction must meet in order for the subsequent transaction to be valid 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 previous transaction was locked.

[0058] The lock script (commonly known as scriptPubKey) is a portion of 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 lock script appears in the output of the transaction. The unlock script (commonly known as scriptSig) is a portion of 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.

[0059] Therefore, in the illustrated example, the UTXO 0 in the output 203 of Tx 0 includes the lock script [Checksig P 0 that requires 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 is the public key P of Alice's public-private key pairA includes the expression (i.e., hash) of Tx. 1 The input 202 of Tx (e.g., in some embodiments, the transaction ID of the entire transaction Tx, TxID 0 which is the hash of the entire transaction) 0 by Tx 0 includes a pointer indicating Tx. 1 The input 202 of Tx 0 is a UTXO from among any other possible outputs of Tx 0 to identify the UTXO within Tx 0 includes an index identifying the UTXO within Tx. 0 The input 202 of Tx 1 further includes an unlock script <Sig P A > having Alice's cryptographic signature, created by Alice applying her private key of the key pair to a predetermined portion of the data (which may also be referred to as the "message" in cryptography). 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.

[0060] When a new transaction Tx 1 arrives at the blockchain node 104, the node applies the node protocol. This may include executing the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined by the lock script (which conditions may include one or more criteria). In some embodiments, this may include concatenating the two scripts: <Sig P A > <P A > || [Checksig P A

[0061] ​Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function executed by a lock script (in this example, a stack-based language). Equivalently, the scripts can be executed one after another using a common stack rather than concatenating the scripts. In any case, when executed together, the scripts will use the public key P of Alice, such as that included in the lock script within the output of Tx 0 to authenticate that the unlock script within the input of Tx A contains Alice's signature that signs the expected portion of the data. To perform this authentication, the expected portion of the data itself (the "message") must also be included. In some embodiments, the data to be signed includes the entire Tx 1 (i.e., since a separate element specifying the signed portion of the plaintext data already essentially exists, it need not be included). 1 Details of authentication by public - private 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 plaintext 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 this as the signature to the message, thereby enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular portion of data or a part of a transaction may, in embodiments, mean signing the hash of that portion of data or part of the transaction.

[0062] If the unlock script within Tx

[0063] Tx 1 satisfies one or more conditions specified within the lock script of Tx 0 (i.e., in the illustrated example, Alice's signature is Tx 1is provided and authenticated), 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 1 is verified and included in the blockchain 150, this defines the UTXO 0 of Tx 0 as used. Note that Tx 1 can only be valid if it uses an unspent transaction output 203. If an output already used by another transaction 152 is attempted to be used, Tx 1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the referenced UTXO within a 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 of the reasons why it is important for the blockchain 150 to impose the order defined in the 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 the blockchain 150.

[0064] 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 is neither propagated nor included in block 151.

[0065] Note that in the UTXO-based transaction model, a given UTXO must be used in its entirety. It is not possible to "leave" a portion of the amount defined as used in the UTXO and use another portion. However, the amount from a UTXO can be split 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 . Thus, 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.

[0066] 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 0can be rejected by the blockchain node 104 and thus may not be propagated and not be 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, a pointer to UTXO 0 is the only input to Tx 1 and Tx 1 is the only output UTXO 1 . Suppose the amount of the digital asset specified in UTXO 0 is greater than the amount specified in UTXO 1 . That 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.

[0067] The digital assets of Alice and Bob are composed of UTXOs locked to them in any 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 defining the total balance of a given party 103 stored. The role of the wallet function in the client application 105 is to collate together all the values of the various UTXOs locked to each party and not yet used in some subsequent transaction. This can be done by querying a copy of the blockchain 150 stored on any of the Bitcoin nodes 104.

[0068] Note that the script code is often represented schematically (i.e., without using exact language). For example, operation codes (opcodes) can be used to represent certain functions. "OP_..." refers to a specific 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.

[0069] 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 a part or all of the transaction output. The specific part 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).

[0070] 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 the transaction 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, in all applications of the blockchain 150, it is not essential 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.

[0071] As shown in FIG. 1, the client applications on each of the computer devices 102a and 120b of Alice and Bob may each include additional communication functions. With this additional functionality, Alice 103a can establish a separate side channel 301 with Bob 103b (either on the instigation of either party or a third party). The side channel 301 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 (yet) being 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 301 can be used to exchange any other transaction-related data such as keys, negotiated amounts or conditions, data content, etc.

[0072] Side channel 301 can be established via the same packet-switching network 101 as blockchain network 106. Alternatively or additionally, side channel 301 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 a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, side channel 301 as referred to herein 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, a bundle or set of off-chain links as a whole may be referred to as side channel 301. Thus, it should be noted that when it is said that Alice and Bob exchange information or a particular portion of data, etc. over side channel 301, this does not necessarily mean that all portions of these data must be transmitted over exactly the same link or the same type of network.

[0073] 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 can include a transaction engine 401 and a user interface (UI) layer 402. Transaction engine 401 is configured to implement basic transaction-related functions of client 105 to formulate, for example, transaction 152, receive and / or transmit transactions and / or other data over side channel 301, and / or transmit a transaction to one or more nodes 104 for propagation throughout blockchain network 106 according to the processes described above.

[0074] 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.

[0075] Although the various functions of this specification can be described as being integrated into the same client application 105, this is not necessarily limited thereto. Instead, it should be noted that they can be implemented, for example, in a set of two or more separate applications where one is a plugin to the other or interfaces via an API (Application Programming Interface). 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, in the operating system layer. When referring to a single or a given application 105 etc. in this specification, this is merely an example, and more generally, it will be understood that the described functions can be implemented in any form of software.

[0076] As an example, FIG. 3B gives a mockup of an example of a 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.

[0077] 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.

[0078] For example, the UI element may include one or more user-selectable elements 501, which may be different on-screen buttons or different options within a menu. The user input means is arranged such that a user 103 (in this case, Alice 103a) can select one of the options or otherwise operate by clicking or touching a 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).

[0079] Alternatively or additionally, the UI element may include one or more data input fields 502. These data input fields 502 are rendered via a user output means, such as the on-screen, and data can be input into the fields via a user input means, such as a keyboard or touch screen. Alternatively, the data may be received orally, for example, based on speech recognition.

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

[0081] It will be understood that the specific means for 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 3B is simply a schematic mock-up and, in reality, may be shown in combination with one or more outputs not shown for the sake of brevity (if both individual results are true, the overall result is considered to indicate true).

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

[0083] 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 with a reference to a blockchain network 106, a blockchain 150, and a blockchain node 104. The blockchain, blockchain network, and / or 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.

[0084] In some embodiments 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).

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

[0086] Even more generally, any reference to the term "Bitcoin node" 104 above may be replaced with the terms "node", "network entity", or "network element", and such entity / element is configured to perform some or all of the roles of block creation, publishing, 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.

[0087] Freezing of digital assets One reason for the interest in public blockchain networks for digital assets is that they can be used for untrusted transactions without permission. By eliminating the need for a central authority or trusted entity to facilitate transfers, blockchain networks enable the owners of digital assets to directly control the digital assets and the transfer of digital assets to another wallet. However, this also poses challenges to existing regulatory or legal frameworks. Without a mechanism to seize, control, or otherwise enforce transfers, it can be difficult or impossible to apply court orders to digital assets, even when attempting to address demonstrable fraud or theft.

[0088] The increasing interest and investment in other blockchain-based digital asset systems such as cryptocurrencies and NFTs have also led to a significant level of fraud and malicious behavior. There are many examples of digital assets being "stolen" through the theft of private keys or by obtaining access to private keys through theft or deception. In some cases, online exchanges have been found to be at risk or fraudulent. Governments, courts, and the financial industry are grappling with how to apply traditional enforcement or judicial means to blockchain-based digital assets.

[0089] Attempts to address real-world theft, bankruptcy, and fraud affecting blockchain-based digital assets can lead to situations where a court or other legal or government agency issues orders to a blockchain organization, a blockchain miner, or an individual blockchain code programmer. Those orders can instruct the recipient to freeze or block further transactions in identifiable digital assets and / or to hold or escrow those assets. Some blockchain software may lack the ability to implement those actions without completely forking the chain to roll back mined blocks, which not only undermines trust and confidence in the reliability of the blockchain but also causes significant confusion to users and can potentially be very costly.

[0090] It may be possible to implement a system that simply imposes on a blockchain network actions such as having a "trusted" legal institution order the seizure of digital assets, but such a system would undermine the consensus and independence principles underlying distributed ledger technology. This application provides a system and method for freezing digital assets that avoids undermining the consensus-based principles of a blockchain network, and further provides a mechanism for taking actions that affect only the identified digital assets without the need to roll out custom blockchain node software changes for each order. Since a fork operation would waste mining resources on invalid blocks, the method and system are further structured to ensure that fork operations are minimized.

[0091] First, refer to FIG. 5, which shows a simplified diagram of an exemplary system 550 for freezing digital assets. System 550 may include a freeze management service 552. The freeze management service 552 may be implemented using one or more computing devices. In some cases, the freeze management service 552 is a web service. One or more user devices 580 may be connected to the freeze management service 552 to request or manage freeze events, for example, using a web browser or a dedicated application. The user device 580 provides user credentials that are authenticated by the freeze management service 552. In some implementations, different levels of permission may be assigned to different user types.

[0092] The freeze management service 552 is configured to communicate with the mining nodes and, in particular, with a blacklist manager 554 implemented in each of the mining nodes. Each blacklist manager 554 is configured to interface with the freeze management service 552. This can be implemented on a computing device operated by a miner, but is likely to be implemented on a machine separate from an instance of blockchain mining software, which is typically implemented using a dedicated special-purpose computing device designed for blockchain mining operations. Each miner has one or more blockchain mining node instances 556. Each blockchain mining node instance 556 may have its own mempool 560 containing unconfirmed blockchain transactions. The blockchain mining node instance 556 further includes a memory 558 that stores two blacklist data structures, a pending blacklist 562 and a consensus blacklist 564. The pending blacklist 562 identifies digital assets that are the subject of a freeze request received from the freeze management service 552, and the consensus blacklist 564 identifies digital assets that are the subject of a freeze order accepted by at least a threshold number of mining nodes. The blacklist manager 554 processes communications with the freeze management service 552 and is responsible for updating the two blacklists 562, 564.

[0093] In some cases, such as when a miner operates two or more blockchain mining node instances 556, each blacklist manager 554 may have two or more associated blockchain mining node instances 556 for which it manages the blacklist. Considering the operation of consensus blacklisting digital assets based on miner acceptance, as described below, each miner should operate one blacklist manager even if the miner has two or more blockchain mining nodes.

[0094] Broadly speaking, the freeze management service 552 receives an authenticated instruction from one of the user devices 580 and issues a freeze request. The instruction may require certain features such as a court identifier or other credentials to validate the instruction. In some cases, the instruction is related to a court order, and the freeze management service 552 may, in some implementations, convert the received court order into a machine-readable representation of the court order. In some implementations, one or more digital signatures from an entity authorized to sign the court order may be verified by the freeze management service 552. The court order may specify one or more digital assets. The digital asset identifier may accurately identify a specific address, e.g., a wallet address, that is frozen as a result of the court order. In some instances, the court order may also or alternatively identify the digital asset by a transaction output point, but in many cases, the court order may identify the funds by association with a wallet address or other public key representation.

[0095] The freeze management service 552 may include an address indexer 553 configured to convert a wallet address or other public key address into one or more transaction outpoints. It will be understood that a single address may be associated with multiple digital assets, which may be identified (in the case of some blockchains) by the transaction outpoints that allocate the assets to that single address. For example, a single public key hash address may be the recipient address of many transactions that allocate digital assets such as cryptocurrencies or NFTs to that address. Each outpoint within a transaction that sends a digital asset to that address may be identified by the address indexer 553. The address indexer 553 or related services may be further configured to engage in tracking operations to track child discovery, i.e., assets that have moved from the identified address to one or more other addresses, and the related outpoints from the transactions that executed those moves. In some implementations, the address indexer 553 is implemented as part of a general blockchain indexer configured to obtain new block data and index transactions that link spent transaction outpoints to transaction inputs to enable tracking of digital assets through transactions. The blockchain indexer may connect to one or more blockchain nodes to listen for new blocks and retrieve block data.

[0096] System 550 employs a two-phase or two-step process to implement the freezing of digital assets. Freeze management service 552 may generate a freeze request 572 based on a court order or other instruction. The freeze request 572 specifies, for example, a transaction outpoint involved in the instruction that may be identified by an address indexer 553. The freeze request 572 may be referred to as a pending freeze order or an anticipated freeze order. The freeze request 572 may be sent to a blacklist manager 554. In some cases, this may include a push transmission of the freeze request 572 or a notification of a new or updated freeze request 572. In some cases, the freeze request 572 is not sent automatically, but rather, for example, using a REST API, enables the blacklist manager 554 to download it when properly authenticated. If a miner accepts the freeze request 572, the blacklist manager 554 may generate and return an acceptance message.

[0097] The freeze management service 552 authenticates acceptance messages regarding the freeze request 572 from the blacklist manager 554 and stores them in a memory, such as a database 570, as part of the acceptance data 576 regarding the freeze request 572. If the acceptance messages are received from miners exceeding a threshold amount, the freeze management service 552 converts the freeze request 572 into a freeze order 574. The freeze order 574 may then be distributed to or made available to the blacklist manager 554, in response to which the blacklist manager 554 implements the freeze order 574 as described below.

[0098] The freeze management service 552 further stores key data 578 including its own public key and securely stored private key as well as public key data associated with registered or authenticated miners. In some cases, this may include a minerID registered on the chain and associated with a particular miner. In some cases, the key data 578 includes coinbase public key data. In some cases, the key data 578 may include delegated key data linked to the minerID or coinbase public key data.

[0099] The blacklist manager 554 receives or obtains a freeze request 572 from the freeze management service 552. The freeze request 572 is digitally signed by the freeze management service 552, and the blacklist manager 554 verifies the signature for the authenticity of the request. It will be understood that there may be many freeze management services. In some cases, the blacklist manager 554 may have a list of freeze management services (e.g., a list of their respective public keys or identifiers) that it trusts, or that it considers miners to be legitimate authorities, whether or not it is a government.

[0100] If the freeze request 572 is authenticated and determined to be from an approved freeze management service 552, the blacklist manager 554 may generate an acceptance message and send it to the freeze management service 552. The blacklist manager 554 also causes the transaction outpoints within the freeze request 572 to be added to the pending blacklist 562.

[0101] When a sufficient consensus is reached and the freeze management service 552 converts the request into a freeze order 574, and the blacklist manager 554 receives or obtains the freeze order 574, the blacklist manager 554 adds the transaction outpoint from the pending blacklist 562 to the consensus blacklist 564. In some implementations, even if the transaction outpoints are added to the consensus blacklist 564, they may not necessarily be removed from the pending blacklist 564. This can have advantages when processing multiple instructions involving the same outpoint, as will be further explained below.

[0102] The blockchain mining node instance 556 performs a two-phase freezing operation as follows. If a transaction outpoint is on the pending blacklist 562, the blockchain mining node instance 556 removes any transaction having that transaction outpoint as an input, such as a UTXO, from its mempool 560. Any new transaction received via the blockchain network from another node that uses the transaction outpoint as an input (or from another channel such as a merchant API or another source) is rejected as invalid and not included in the mempool 560. In other words, the mining node refuses to mine any transaction containing the transaction outpoint and refuses to propagate a transaction containing the transaction outpoint. However, during this "pending" phase, the mining node still accepts as valid a resolved block from another mining node even if it contains a transaction that uses the transaction outpoint. That is, the mining node itself may treat its outpoint as frozen, but there is not yet sufficient consensus among the miners to treat other legitimate blocks as invalid based on the fact that other miners did not treat the outpoint as frozen. Therefore, the blockchain mining node instance 556 validates a block received from another miner that contains the transaction outpoint despite the fact that it is on the pending blacklist 562.

[0103] In response to receiving and validating a freeze order, when the transaction outpoint is copied from the pending blacklist 562 to the consensus blacklist 564, the blockchain mining node instance 556 also rejects any block received from another miner that contains the transaction outpoint.

[0104] The digital assets frozen by this process can be thawed according to a similar process. To thaw the digital assets, the freeze management service 552 may prepare and sign a thawing request that references a previous freeze order regarding the digital assets. If a threshold number of mining nodes accept the thawing request, the freeze management service 552 issues a thawing order. As a result of the thawing order, the blacklist manager 554 removes the transaction outpoints associated with the digital assets from the blacklist.

[0105] Now, refer to FIG. 6 which shows, in flowchart form, one simplified exemplary method 600 for freezing digital assets within a blockchain network. The exemplary method 600 may be implemented using a network-connected computing device. In some cases, the computing device may be a server or a group of servers that operate an online service such as the freeze management service 552 (FIG. 5). The operations of method 600 may be executed by a computing device based on processor-executable software instructions stored in memory on the computing device. The computing device may be connected to one or more networks such as the Internet. The computing device may or may not be directly connected to the blockchain network as a node of the blockchain network. In many implementations, the computing device operates blockchain protocol software, does not form part of the blockchain network, but is configured to obtain data from one or more blockchain nodes and communicate data with one or more mining nodes on the blockchain network.

[0106] In operation 602, the computing device receives instructions regarding one or more digital assets. These instructions may be received from a user device via a secure communication channel. Various user accounts may be provided to the computing device, and each user account has a certain level of access and authentication credentials. The granting of user accounts may be based on an enrollment or vetting process in which the user is determined to be a formal representative of a government or legal authority or some other entity that purports to have issued the instructions regarding the digital assets. The government or legal authority may have a public-private key pair stored on the computing device for digitally signing messages purporting to be on its behalf. Access permissions for providing signing authority using the private key of the authority may be assigned to one or more user accounts associated with that authority.

[0107] In some instances, the received instructions may be a court order. In some cases, the court order may be in analog form and may be digitized by the computing system using optical character recognition (OCR) or other techniques. In some cases, the court order may be in digital form but may be converted to a standardized machine-readable format. The original received court order may be stored in the computing system. A hash of the original court order and / or a hash of the machine-readable court order may also be generated and stored.

[0108] The order identifies one or more digital assets to be frozen. The digital assets can be identified within the order using one or more wallet addresses or other identifiers. Optionally, the computing system can determine one or more transaction outpoints that reflect the digital assets assigned or associated with one or more wallet addresses or other identifiers based on blockchain indexing. In some cases, the order can indicate that it applies only to the wallet addresses or outpoints identified by the order at a particular point in time, or to funds moved from those addresses after the time associated with the order. As described below, in some cases, the computing system can participate in the tracking of digital assets through the link of transaction outpoints to identify the "child" transaction outpoints on the blockchain from which the assets were moved from one or more wallet addresses or other identifiers.

[0109] In operation 604, the computing system generates a freeze request message and digitally signs it. The freeze request message can identify the instruction, such as by including a hash or a complete copy of the instruction. This instruction can be encoded using an appropriate encoding scheme such as base64. The freeze request message includes the transaction outpoint that the request is related to and identifies the institution that issued the instruction, such as by its public key, digital certificate, or another identifier. The freeze request message is digitally signed by the institution that issued the instruction. That is, the user device that provided the instruction to the computing device has sufficient credentials to enable the computing device to digitally sign the freeze request message using the private key corresponding to the public key associated with the institution. In this way, the recipient of the freeze request message can verify that the message is authentic and from an instruction by the institution. In some cases, the freeze request message can be further digitally signed by the freeze management service, but in some other cases, any mining device accessing the freeze request message separately verifies that it is legitimately distributed by the freeze management service.

[0110] The signed freeze request instruction is distributed to the mining nodes that form part of the blockchain network. This distribution can, in some cases, be based on the active push transmission of the signed freeze request instruction to a set of mining nodes known to the freeze management service. In some cases, the distribution can be based on the mining nodes querying the freeze management service about new freeze messages and being provided access to the new freeze messages when authenticated by the freeze management service. In some cases, a notification of newly available freeze messages or instructions can be sent to the mining nodes, and the mining nodes can then log in to the freeze management service and download those messages or instructions.

[0111] After delivering the freeze request message, in operation 606, the freeze management service waits for acceptance messages from those mining nodes. The acceptance message identifies the freeze request it is associated with, is digitally signed by the mining node, and provides at least one identifier of the mining node. The freeze management service tracks the receipt of acceptance and, in operation 608, determines whether it has received sufficient acceptance to reach the consensus threshold. The consensus threshold can be set by the user who uploaded the instruction. The consensus threshold can follow a minimum threshold set at 50% or more. In some cases, the consensus may further be based on administrator input, that is, in some implementations, when a miner of a threshold amount accepts the freeze request, the administrator of the freeze management service or the user who provided the instruction is notified, but prior to the consensus trigger described below, further authorization is received from the administrator or the user.

[0112] In some embodiments, the consensus threshold can be based on the miner count, i.e., the percentage of mining nodes, but this can allow the system to be exploited if there is a risk of dummy mining nodes being added to the network. To better track the block mining consensus, the consensus threshold can be based on hash power. That is, for the purpose of evaluating the consensus, only acceptances from miners who mined blocks within a time window can be counted. In one example, the threshold is based on acceptances from mining nodes representing the minimum percentage of blocks mined over a recent window such as the past 288 blocks. The percentage and window length (number of past blocks) can be settable when generating the freeze request.

[0113] When a consensus threshold is reached regarding the acceptance of a freezing request by a mining node, at operation 610, the computing device generates a freezing order and sends it to the mining node. The freezing order references the freezing request and, optionally, provides the received acceptance details and / or a copy if the mining node is configured to independently verify that the consensus threshold has been reached. The freezing order may identify the transaction outpoint to which the freezing order applies or provide an identifier for linking it to a freezing request message in which the outpoint is specified. The identifier can be a hash of the freezing request message, a hash of a court order, or some other such identifier. The freezing order can also indicate the block height at which the freezing order becomes effective. That is, the freezing order need not be configured to be implemented immediately upon generation by the computing device or receipt by the mining node, as those times can vary and can cause forks and orphan blocks. Thus, the computing device can set a future block height at which the freezing order becomes effective. The freezing order is sent to, made available to, or otherwise distributed to the mining node.

[0114] FIG. 7 shows, in flowchart form, one simplified, exemplary method 700 for implementing the freezing of digital assets on a blockchain network. Method 700 can be implemented using a network-connected computing device and, in particular, a mining node that is part of the blockchain network. Optionally, the mining node can be a server or a group of servers that operate a blacklist manager 554 (FIG. 5). The operations of method 700 can be performed by the mining node based on processor-executable software instructions stored in memory on the computing device.

[0115] In operation 702, the mining node receives or obtains a freezing request message from the freezing management service. In some implementations, the mining node is configured to periodically query the freezing management service for new freezing request messages. In some cases, the mining node receives a notification that a new freezing request message is available from the service. In some cases, the service sends a copy of the freezing request message to the mining node.

[0116] In operation 704, the mining node determines whether to accept the freezing request message. The determination of whether to accept the request may be based in part on validating the message by verifying that the message is from the freezing management service recognized by the mining node. This may be determined based on authentication data exchanged during communication with the service and / or by verifying a digital signature on the freezing request message. The mining node may also or alternatively verify that the freezing request message is based on an order from an authority that it recognizes as legitimate. This verification may be based on verifying a digital signature on the freezing request message from the authority. For example, the mining node may have a register or other data structure that stores the public key or other identifying data of an authority that it recognizes as legitimate. Examples may include specific government departments of one or more countries or quasi-national governments, or specific courts or other administrative tribunals. The miner may configure its mining node to recognize an authority such that the miner independently determines that it is legitimate. The mining node may further verify that the freezing request message meets certain predetermined requirements of format and content.

[0117] If the mining node determines that the freezing request message is valid and from a recognized institution, it may accept it; otherwise, it rejects the message as shown by operation 706. To accept the freezing request message, the mining node, particularly the blacklist manager, generates an acceptance message as shown by operation 708 and sends it to the freezing management service. The acceptance message references the freezing request message and is digitally signed by the mining node using the key pair associated with the mining node. The acceptance message may include identifying the address or public key associated with the mining node to enable the freezing management service to properly identify the blocks mined by the miner and thus its hash power or voting power in the consensus decision.

[0118] If the mining node accepts the freezing request message, in operation 710, the mining node adds the transaction outpoints specified in the freezing request message to its pending blacklist. Thereafter, if a transaction claiming to use one of the transaction outpoints as an input is received via the blockchain network, the mining node considers that transaction invalid, does not add it to the mempool, and does not propagate that transaction further on the blockchain network. The mining node also removes any pending transactions already received from its mempool if those transactions include one of the transaction outpoints as an input.

[0119] By placing transaction outpoints on the pending blacklist, the mining node will subsequently exclude transactions containing those outpoints from any candidate block being mined by the mining node and will not propagate any pending transactions containing those outpoints. However, since the freeze has not yet been implemented by consensus, the mining node will still accept a mined block as valid if the mined block is received during this time, even if the mined block contains a transaction that includes one of the transaction outpoints from the pending blacklist. During this time, any such block that is received and validated will be added to the blockchain, despite the fact that it contains transactions that use the digital assets that are expected to be the subject of the freeze.

[0120] The mining node monitors the implementation of the consensus freeze at operation 712. The consensus freeze can be notified by the freeze management service through the issuance of a signed freeze order. As described above, the freeze order can provide acceptance details received from various mining nodes. The mining node can verify that consensus has been reached as part of validating the freeze order in some implementations. The freeze order can be received from the freeze management service in some implementations via query and download by the mining node or by receiving a push transmission from the freeze management service. If the mining node determines that the freeze order is valid, at operation 714, the mining node copies the transaction outpoints from the pending blacklist to the consensus blacklist. The mining node does not remove the transaction outpoints from the pending blacklist in these examples, which can be advantageous with respect to resolving multiple freeze requests or conflicts in freeze orders.

[0121] Referring now to FIG. 8, which illustrates a further exemplary method 800 of freezing digital assets in connection with a blockchain network. Method 800 may be implemented by a computing device configured to provide a freezing management service. In operation 802, the computing device receives and authenticates an instruction regarding a digital asset. As described above, the instruction may be from an institution, and the validity of the instruction may be verified by the computing device using one or more mechanisms. The computing device generates and digitally signs a freeze request message, as shown by operation 804. The digital signature may be the digital signature of the institution that issued the instruction. Generation of the freeze request message may include determining a transaction outpoint associated with the freeze based on the digital asset identified in the instruction received from the institution. In some cases, identification of the transaction outpoint may include tracking the asset from an address used in one transaction outpoint, e.g., a pay-to-public-key-hash address, to other addresses in subsequent transactions using indexed transaction data regarding the blockchain.

[0122] Operation 804 further includes delivering the freeze request message to a mining node, specifically, a computing device network-connected at a mining node implementing a blacklist manager. Each blacklist manager may function to manage a blacklist for a single miner, but may manage blacklists at multiple mining node instances if the miner operates multiple mining node instances.

[0123] When a freeze request message is delivered to the blacklist manager, the computing device waits for an acceptance message from the blacklist manager on behalf of their respective miners. As shown by operation 806, when a new acceptance message is detected by the computing device, the computing device validates the message and stores the acceptance data in memory in operation 808. The validation may include verifying that the message is digitally signed by the mining node. In some cases, the mining node may register identification information such as minerID on the blockchain, enabling the computing device to verify that the minerID is valid and legitimate and that the minerID corresponds to the digital signature applied to the acceptance message. Other mechanisms may be used to verify that the acceptance message is digitally signed by a recognized mining node of the blockchain network. The acceptance message may include key data regarding the miner. That is, it may include a minerID, public key, or public key hash associated with the miner that enables the computing device to identify the block mined by the miner based on the secret key used to sign the acceptance message, the public key, or the public key hash. In some cases, such a block may be identified based on the address to which the block reward is allocated in the coinbase transaction within the block. The coinbase transaction may allocate the block reward to the public key hash corresponding to the public key specified in the acceptance message.

[0124] In some cases, a mining node may not wish to use its coinbase public key address in relation to this function and may instead wish to use a different key pair to sign the acceptance message, in which case, as described below, the coinbase key may be linked to the signing key pair by a key delegation operation. If so, the acceptance message may include delegation key data that enables a computing device to associate the public key hash within the coinbase transaction with a particular miner, even if the digital signature used for the acceptance message is not the corresponding private key.

[0125] In operation 810, the computing device may ensure that it can update the stored key list associated with the acceptance to track key data that links the miner and its acceptance to the block mined by that miner on the blockchain. The computing device then proceeds to operation 814 to evaluate whether the new acceptance results in reaching a consensus.

[0126] If no new acceptance is received, in operation 812, the computing device may evaluate whether a new block has been mined. If so, it may identify the mining node that mined the new block and determine the number of blocks within the most recent window of blocks mined by each mining node. Based on this, the computing device can evaluate, as indicated by operation 814, what percentage or number of blocks within the window were mined by the mining node that received the freeze request message.

[0127] The window can, in some cases, be a time window or a number of blocks. In some examples, the number of blocks can be about 288, which represents about two days of mining on the Bitcoin network considering an average time of about 10 minutes to mine a block. In other blockchain networks, different measures of mining hash power can be used to evaluate the proportion of hash power that has accepted a freeze request message.

[0128] The window can be a window of the current block or the most recent blocks looked back from the current block or current time to represent a measure of recent hash power in the blockchain network. In some cases, a longer window spanning several days or weeks may be desirable to avoid a borrowed or temporary spike in hash power from overly controlling the freeze consensus.

[0129] In some cases, the window only starts at some other time linked to the issuance of a freeze request message by a freeze management service, or the generation or upload of an instruction, or the generation or distribution of a freeze request message. The window then waits for the mining of at least a threshold number of blocks, such as 288 or another specified amount, and after reaching the threshold number of blocks, the computing device begins to evaluate whether it has reached the acceptance of the consensus threshold ratio. The window can expand to include new blocks from that point forward or can be a moving window that only considers a specified amount of the most recent blocks.

[0130] As shown in operation 816, if the threshold number or ratio of blocks within a window is associated with a miner that has received a freeze request message, the computing device, in operation 818, generates, signs, and distributes a freeze command message. The freeze command message is a freeze instruction and may specify the transaction outpoints to which it applies or may reference them by referring to the freeze request message. A mining node that receives the freeze command message, particularly the blacklist manager, adds the frozen transaction outpoints to the consensus blacklist. The freeze comment message can specify an execution time or an execution block height. When a transaction outpoint on the consensus blacklist appears in a block after the execution time or block height, that block is invalidated. Thus, when sufficient consensus is reached to issue a freeze command message, even a mining node that has not received a freeze request message is likely to enforce the freeze, or else risk wasting energy by mining invalid blocks that will be rejected by the network.

[0131] If no consensus has yet been detected in operation 816, the computing device returns to operation 806 and may wait for further acceptance and / or additional blocks within the window to evaluate the acceptance hash power.

[0132] As described, the determination of whether consensus has been reached is based on the receipt of acceptance messages signed by miners and confirmation that the miner has mined at least one block recently. In one embodiment, the process of associating a new block with a particular miner may include the following:

[0133] 1. Construct a set of public keys used in the coinbase document:

[0134] (a) If the coinbase transaction includes a single P2PKH output and none of the other outputs are payment outputs (e.g., OP_RETURN, OP_FALSE OP_RETURN, etc.), add the corresponding public key to the set. If there are multiple P2PKH outputs or other non-standard outputs, do not add the key to the set;

[0135] (b) If the coinbase transaction includes a valid MinerID, add it to the set. Also add all preMinerIDs from the start of the window of the block being evaluated (e.g., looking back 288 blocks of the chain from the current new block), where "preMinerID" is the previous MinerID linked to the current MinerID in an implementation where the miner can cycle its key.

[0136] 2. If the acceptance message public key is included in the set, the acceptance message is associated with this block.

[0137] 3. If the set includes any of the keys listed as delegating public keys within the delegation key data in the acceptance message and the public key corresponding to the signed acceptance message is one of the listed delegating public keys within the delegation key data, the acceptance message is associated with this block.

[0138] 4. Otherwise, the block is not associated with the acceptance message.

[0139] It should be noted that in step 3, only the delegated public key from the current acceptance message is considered, which means that the key delegation is only valid within the scope of this acceptance. If a mining node submits the acceptance of two different freezing requests, each acceptance message may contain a different set of keys. Even if there is a delegated key regarding that miner in one acceptance message, it is not necessarily transferred to another acceptance message from that miner unless the delegated key data specifying the delegated public key is included.

[0140] When calculating the percentage of hash power associated with an acceptance message, in some embodiments, the window looks back a set number of blocks (e.g., 288) set from the most recently mined block. This decouples the acceptance process from the mining of new blocks. A miner does not need to mine a new block to count its acceptance, provided that it mined the blocks within the window. Thus, acceptance can be collected in a short time, assuming that the past distribution of hash power is a reasonably good indicator of the current distribution of hash power.

[0141] FIG. 9 shows a further exemplary method 900 for implementing the freezing of digital assets on a blockchain network. Method 900 can be implemented by a computing device associated with a blockchain miner, in particular, by a blacklist manager operating on the computing device. The blacklist manager can be implemented by software instructions that cause the computing device to perform the described operations when executed by a processor of the computing device. The computing device can manage the freezing and thawing operations in relation to the digital assets of at least one instance of the blockchain mining node.

[0142] In operation 902, the blacklist manager obtains or receives a freezing request message from the freezing management service. The freezing request message identifies the institution that issued the order and the transaction outpoint to which the freezing request applies. It can also provide details regarding the consensus threshold and an encoded copy or representation of the order from the institution. In operation 904, the blacklist manager validates at least one digital signature on the freezing request message. This can be a digital signature associated with the institution, thereby indicating that the request is related to a legitimate order from the institution. The freezing message can also or alternatively include a digital signature from the freezing management service, which itself can be considered an institution in some implementations. If the digital signature cannot be verified using the corresponding public key, in operation 906, the request message is rejected. It can, in some cases, simply reject the request by not responding to it.

[0143] In operation 908, the blacklist manager determines whether the freezing request is acceptable. This determination can be based on several factors set within the blacklist manager and can be configurable by the administrator of the blockchain miner. The determination can be based on whether the institution is recognized as an institution by the blacklist manager. The blacklist manager can have a list or other data structure that identifies recognized institutions and, in some cases, their corresponding public key(s). In some cases, the determination can be partially based on the consensus threshold being at least a minimum percentage or number. The determination can also, in some implementations, be based on the nature of the digital asset, such as whether the digital asset is related to a cryptocurrency or is a token such as a non-fungible token (NFT), or the specific type of NFT involved. If the blacklist manager determines that the freezing request does not meet its set acceptance criteria, it rejects the request (910). It can, in some cases, simply reject the request by not responding to it.

[0144] If the request is accepted, the blacklist manager generates an acceptance message, digitally signs it, and sends the acceptance message to the freeze management service as shown by operation 912. The acceptance message references the freeze request message and includes the digital signature of the mining node. The digital signature may use the minerID key pair or other set of keys associated with the mining node. The key used corresponds to an address or identifier used or referenced in a block mined by the mining node, such as an address to which the coinbase transaction is payable, or is linked to such an identifier or address by the delegated key data. The delegated key data may be published separately or included in the acceptance message to ensure that the freeze management service can link the block mined by the mining node to the digital signature used to sign the acceptance message.

[0145] If the request is accepted, in operation 914, the blacklist manager also adds all transaction outpoints identified within the freeze request message to the pending blacklist maintained at any mining node instance with which it is associated. This can be done, for example, using a remote procedure call (RPC) function defined to edit or modify the blacklist stored in memory at a blockchain mining node instance. In some cases, the mining node instance also searches the existing pending transactions within its mempool to determine if any of them include as an input any of the transaction outpoints newly placed on the blacklist, and if so, is configured to remove them from the mempool and from any candidate blocks being mined by the mining node instance.

[0146] When a transaction outpoint is added to the pending blacklist(s), the blacklist manager waits for a consensus-based freeze order from the freeze management service or issues an "unfreeze" request that effectively cancels a previously accepted freeze request. During that time, the mining node instance continues to participate in the mining operation, searches for a proof-of-work solution for the candidate block, and validates newly received transactions and resolved blocks from other mining nodes. As shown by operation 916, when a new transaction is received by a mining node via the blockchain network, at operation 918, the mining node instance determines whether the new transaction contains a transaction outpoint on its pending blacklist or the consensus blacklist. The mining node instance may use any suitable comparison or matching process to evaluate whether the transaction input on the new transaction corresponds to a transaction outpoint on the blacklist. Otherwise, the mining node instance, as shown by operation 920, validates the new transaction as normal according to the managed blockchain protocol and adds it to the mempool of unconfirmed transactions. The mining node instance further propagates the new transaction on the blockchain network according to the blockchain protocol. However, if the new transaction contains a transaction outpoint on either the pending blacklist or the consensus blacklist, at operation 922, the mining node rejects the new transaction and excludes it from the mempool. It does not propagate the rejected transaction on the blockchain network.

[0147] In some cases, as shown by operation 924, while waiting for a consensus freeze order, a mining node may receive a newly mined block, or a message regarding a newly mined block, from another mining node. In operation 925, the mining node may evaluate whether the block contains any transaction that references a transaction outpoint that appears on the consensus blacklist, and if so, it rejects the block 926. Note that the blockchain network as a whole does not conclude that the transaction outpoint is a target of consensus freezing, so it does not reject the block if the transaction outpoint is only on the pending blacklist. If the transaction does not include an outpoint that is on the consensus blacklist, in operation 927, the block is validated and added to the blockchain according to the normal blockchain protocol. This may include adding a block that features a transaction having as input one or more transaction outpoints that appear on the pending blacklist. Nevertheless, the new block is considered valid. Even if the transaction outpoint is later added to the consensus blacklist due to reaching the consensus threshold, the newly mined block is not retroactively invalidated.

[0148] In operation 928, the blacklist manager evaluates whether a consensus freeze order regarding the freeze request message has been received. If so, it causes the mining node to copy the transaction outpoints identified in the freeze request message from the pending blacklist to the consensus blacklist. Often, the consensus freeze order specifies the block height at which the freeze is to occur, in which case the blacklist manager waits for that block height to be reached and then adds the transaction outpoints to the consensus blacklist. When the transaction outpoints are on the consensus blacklist, any subsequent new transactions or newly mined blocks containing those transaction outpoints are rejected as invalid. Previously mined blocks that were added to the blockchain before the consensus freeze order took effect and contain the transaction outpoints as inputs are not invalidated.

[0149] The method described above relates to the freezing operation regarding the specified digital asset. A similar method may be used when performing the thawing operation. The thawing operation may be regarded as the cancellation or revocation of the freeze request or freeze order. In some implementations, in order to implement the thawing request, the thawing request message is digitally signed by the same institution as the freeze request message. That is, in some examples, the freeze request or freeze order cannot be withdrawn or revoked by a different institution. In some cases, the thawing request may be signed by a key different from the freeze request, provided that the key is associated.

[0150] In one variation, in some implementations, if the original freezing operation is from a lower authority, the upper authority may be able to perform a thawing operation. As an example, even if a court issues an order to freeze a particular digital asset, the higher court may allow an appeal against that order and may instruct that the freezing order be reversed or canceled. In some cases, the blacklist manager may store on top of that the specified hierarchy of the relevant authorities so that it can know which authority can override which other authority. In some cases, no authority can override another authority, and thus, the appellate court may have the lower court digitally sign the thawing request message in order to enforce the appellate judgment.

[0151] If a freezing request message has been distributed and consensus has not yet been reached, upon receipt and acceptance of the corresponding thawing request message by the blacklist manager, assuming that the blacklist manager is not also involved in another different freezing request message, the blacklist manager removes the affected transaction outpoint from the pending blacklist. The interaction of different requests and orders from different authorities involving the same digital asset will be further explained below.

[0152] When consensus is reached and a freezing order occurs, the thawing request message is treated like the freezing request message in that the action must reach consensus before it can be taken. However, with the thawing request message, no immediate change to the blacklist occurs, and the mining nodes continue to maintain the transaction outpoints on both blacklists until the consensus threshold for the thawing request message is reached and the thawing order is distributed. At that point, the blacklist manager removes the transaction outpoints from both blacklists and then makes them available for use in valid transactions.

[0153] As described above, in some cases, an instruction from an institution may specify one or more specific digital assets by an address, such as a wallet address, a pay-to-public-key-hash (P2PKH) address, a pay-to-script-hash (P2SH) address, or other forms of address. In some cases, the instruction may specify a transaction outpoint in addition to, or instead of, the address. An address indexer in the freeze management service, or an address indexer to which the service has access, is configured to resolve a transaction outpoint from an address, i.e., to identify the transaction outpoint that sends the digital asset to a specific address. Further, it may be configured to track children of a transaction outpoint (TXOUT), i.e., to find the transaction outpoints used as inputs to subsequent transactions and identify the outputs of the subsequent transactions as those linked to the TXOUT as child outpoints. The indexer may be a stand-alone or separate component accessible via a REST API or similar interface. This may connect to a blockchain node instance to listen for new blocks and retrieve block data. The address indexer uses unconfirmed transactions in the mempool in addition to data from blocks on the current chain. In some other implementations, the address indexing operation may be performed at the mining node level, which means that the freeze management service may issue a freeze request message identifying the address, and the blacklist manager / mining node may perform the function of tracking the specific outpoints mapped to those addresses.

[0154] In some cases, the address indexer may be configured to receive an address and a time, and in response, provide a set of TXOUTs that can each be specified as a pair formed from a transaction identifier (TXID) and an output index (vout). This set refers to TXOUTs created in blocks having a time after the specified time.

[0155] In some cases, the address indexer may be configured to provide child data with respect to a TXOUT. In this regard, it may receive a TXOUT and provide an array or other data structure that specifies the TXOUT, and a function or API that provides a set of child TXOUTs. It may further provide information regarding the block in which the TXOUT was used to generate the child TXOUTs. Since a single TXOUT can be used multiple times in the presence of a fork, an array may be provided.

[0156] If the instruction specifies that child outpoints are also frozen in addition to any specific transaction outpoint, the address indexer can be used to track the digital assets passed to the new transaction outpoint when generating the freeze request instruction. In an exemplary implementation, this can be performed as follows: a) Scan all blocks from the TXOUT creation time to the most recent time. This is very time-consuming. Scanning the entire blockchain can take several hours and require a lot of resources; b) Use an off-the-shelf graph database or custom implementation to update the relationships as soon as new blocks arrive (more storage is required upfront); c) Perform a recursive lookup of each frozen asset using a series of calls to an existing address / output indexer (such as an ElectrumX server) and a fully indexed blockchain node. Address reuse may cause delays; or d) Construct a custom indexer component that indexes addresses and how outputs are used (and new outputs are created).

[0157] Regardless of whether the instruction specifies an address or a specific transaction outpoint, the freeze management service begins by identifying the affected transaction outpoints. It can then track any transactions that use these transaction outpoints, i.e., child outpoints, which are added to the list of transaction outpoints. Note that new addresses that assign assets to child outpoints are not added as they may be involved in other unrelated assets held by that address.

[0158] The responsibility for identifying child transaction outpoints lies with the freeze management service in these examples. This has the advantages that mining nodes can run unindexed or pruned nodes, they do not require an address indexer or child discovery tracking capabilities, the list of outpoints in the digitally signed freeze request message by the institution is static and common to all miners, thereby avoiding the risk of inconsistent freezes and chain forks. The disadvantage is that if assets are moved from the identified outpoints between generating the freeze request message and delivering it to the miners until the miners accept the request, the freeze can be avoided. If additional child outpoints are included in the freeze request after the signed freeze request message has been delivered, the freeze management service and the institution can generate and send a second or subsequent freeze request message.

[0159] As described above, TXOUT is affected by two or more freezing requests and / or freezing orders from the same authority or different institutions. The blacklist manager may be responsible for integrating the status and ensuring that the blockchain node instance has a unified view. In this regard, the blacklist manager may consider an outpoint as being on hold for freezing, i.e., on the pending blacklist, if it appears in at least one freezing request message and there is no consensus freezing order enumerating that outpoint yet. Similarly, an outpoint is considered frozen, i.e., on the consensus blacklist, if it is the subject of at least one consensus freezing order and that freezing order has not been cancelled / voided by a consensus thawing order that references the freezing order. In some implementations, if there are two consensus freezing orders from different institutions affecting a transaction outpoint and a consensus thawing order referencing that transaction outpoint is distributed later, the blacklist manager will thaw the transaction outpoint regardless of the fact that two or more freezing orders apply to it. However, in many other implementations, the thawing order is only effective to thaw the outpoint with respect to a particular relevant freezing order. That is, if an outpoint is the subject of two consensus freezing orders, a consensus thawing order that references one of those freezing orders is not sufficient to remove the outpoint from the consensus blacklist until a consensus thawing order that references the other freezing order is also distributed.

[0160] As an example, FIG. 10 schematically shows a set of transactions that are related to each other. The transactions include transactions A and D, each of which has at least one outpoint used in transaction A1, and transaction A1 has at least one outpoint used in transaction A2 and at least one outpoint used in transaction B2. Transaction C has at least one outpoint used in transaction C1, and transaction C1 has at least one transaction outpoint used in transaction B2 and at least one transaction outpoint used in transaction C2. Transaction B3 takes at least one transaction outpoint from B2 as an input. In some implementations, each of the transactions may have at least one unused transaction outpoint.

[0161] The first court order may identify the digital assets associated with transaction A and related transactions A1, A2, B2, and B3. A freeze request may be generated to identify the transaction outpoints within these transactions (A, A1, A2, B2, and B3). The second court order may identify the digital assets associated with transaction C and related transactions C1, C2, B2, and B3. The third court order may identify transaction D and related transactions A1 and A2. These court orders may be received and / or processed by one or more freeze management services at different times. Further, corresponding thaw orders may be generated later for any one or all of the court orders, which may result in conflicting orders that affect the same outpoints. For purposes of illustration, the following chart maps the processing of freeze requests, freeze orders, and thaw orders for these three exemplary court orders:

Table 1-1

Table 1-2

[0162] In some cases, different freeze or thaw commands that reference the same digital asset may specify different block heights at which the commands become effective. In such cases, in some implementations, the following rules may apply.

[0163] 1. If the same outpoint is referenced by multiple consensus freeze commands with different enforceAtHeight values, the minimum value is used to add the outpoint to the consensus blacklist.

[0164] 2. If the same outpoint is referenced by multiple consensus thaw commands with different enforceAtHeight values and those thaw commands reference the same freeze command, the minimum value is used, which means that the outpoint is removed from the consensus blacklist and the pending blacklist based on the earliest reachable enforceAtHeight.

[0165] 3. If the same outpoint is referenced by multiple consensus thaw commands with different enforceAtHeight values and those thaw commands reference different freeze commands, the outpoint may be removed from the consensus blacklist and the pending blacklist when the last of the consensus thaw commands becomes effective, provided that there are no other active consensus freeze commands affecting that outpoint.

[0166] In the above example, when the consensus threshold is reached, the freezing management service generates and distributes a freezing order (consensus activation document). In response, the mining node adds the specified transaction outpoints to the consensus blacklist, and then does not validate or propagate any block containing a transaction that uses any of those specified transaction outpoints. This is sometimes referred to as "hard consensus freeze". However, in some implementations, the mining node can be configured to implement "soft consensus freeze".

[0167] In "soft consensus freeze", the mining node still maintains a consensus blacklist that identifies the frozen transaction outpoints. When a block containing a transaction that uses one of the frozen transaction outpoints is received, the mining node still treats the block as invalid. The block is considered to be "frozen" by the mining node. Soft consensus freeze is implemented with a block count of N, which can be specified in the freezing order or pre-determined and set by the protocol. During operation, the mining node treats "invalid" blocks as frozen and considers them invalid unless more than N blocks are added to that "invalid" block. In other words, despite the fact that the outpoints are consensus frozen, not all mining nodes treat them as frozen. Some mining nodes may continue to mine as if the transactions using those outpoints were valid, and if those mining nodes are successful enough, they may succeed in building a chain of more than N blocks on top of the "invalid" block. In that case, the mining nodes that would have considered that block "invalid" reverse their decision, treat that block as valid, and treat that chain as the best tip candidate.

[0168] As described in the above exemplary embodiments, various documents or message types can be exchanged between the freezing management service and the blacklist manager, or between the blacklist manager and the mining node instance. The various documents are digitally signed by institutions, the freezing management service, mining nodes, etc. The enveloped signature can be used, for example, when the original document is stored as a string within the payload field, as described by the JSON envelope specification BFRC 6a7a2dec8b17.

[0169] Examples of exemplary document structures are provided below, but it will be understood that in some implementations, variations can be made. Any particular implementation may define a document structure to enable interoperability and standardize communication. In the following examples, not all fields are necessarily required fields for a valid document.

[0170] Freezing request message

Table 2-1

Table 2-2

[0171] Listing already used transaction outputs has no effect. Blocks using such outputs are not invalidated even if the instructions are executed. Since they were created before enforceAtHeight, the validity of this output does not change even when a new node downloads the blockchain or an existing node is re-indexed. Such outputs exist on the freezing request message for completeness, so that, for example, an auditor can use them to trace unspent outputs back to the root funds identified by the institution.

[0172] Thawing request message

Table 3-1

Table 3-2

[0173] The parameter freezeHash can be the hash (such as SHA256) of the hash of the hash input into the signature function of the freeze request document. In one exemplary process:

[0174] 1. Obtain the digitally signed freeze request message (as specified, for example, by the JSON envelope specification).

[0175] 2. Calculate the hash of the payload by converting the string value to stream bytes using the encoding specified in the "encoding" field.

[0176] 3. Take the output of the previous step and hash it again.

[0177] 4. Reverse the bytes and convert them to a hex-encoded string.

[0178] Acceptance When a miner (such as a blacklist manager) determines that a freeze request (or thaw request) should be accepted, it generates an acceptance message, signs it, and sends it to the freeze management service. The acceptance is signed with the private key of the mining node. If the protocol employs a minerID or equivalent miner identifier scheme, the digital signature can use that key pair. An example of one exemplary structure of the acceptance message is as follows:

Table 4

[0179] In this example, each entry in delegatedKeys is for listing the public keys corresponding to the private keys used to sign the Acceptance document in the delegatingPublicKey array (it may be permitted to list additional public keys). In other words, the Acceptance document shall not contain a delegatedKeys document that does not give permission to sign the keys used to sign the Acceptance document.

[0180] The delegatedKeys document can be used when the mining node does not want to use the private key associated with the public key used in the coinbase transaction. The coinbase transaction is associated with valuable resources, and the mining node may not want to use the associated keys for other purposes. The delegatedKeys document is a way to link the keys used in the coinbase transaction to additional keys that can be used to sign the Acceptance document and for other purposes. The original (delegated) key can be identified by providing the entire public key or the P2PKH address of the public key. The delegatedKeys document should be signed by the key (delegated key) used in the coinbase transaction. An exemplary document may have the following structure:

Table 5

[0181] When the freeze management service determines that the consensus threshold has been reached, it generates, signs, and sends a freeze order message or an unfreeze order message. This may sometimes be called a "consensus activation" document. The document is signed using the private key associated with the public key of the institution that issued the order to freeze / unfreeze the digital asset. The format of such a document is as follows:

Table 6

[0182] Note that the freeze or thaw command (e.g., consensusActivation document) includes all acceptances from miners related to the command and details of the blocks within the window associated with the miners who signed that acceptance. This allows each mining node to independently verify that consensus has been reached. The enforceAtHeight field indicates the block height at which the transaction outpoint is added to the consensus blacklist to start enforcing the freeze / thaw. The enforceAtHeight value of the thaw command must be greater than the enforceAtHeight value of the related freeze command.

[0183] The above document structure is exemplary. It will be understood that various changes may be made to remove or add various fields, or to change the encoding or requirements of the document.

[0184] The various embodiments presented above are merely examples and are in no way intended to limit the scope of this application. Variations of the innovations described herein will be apparent to those skilled in the art, and such variations are within the intended scope of this application. In particular, alternative exemplary embodiments can be created by selecting features from one or more of the above exemplary embodiments to include sub-combinations of features that may not have been explicitly described above. Additionally, alternative exemplary embodiments can be created by selecting and combining features from one or more of the above exemplary embodiments to include combinations of features that may not have been explicitly described above. Features suitable for such combinations and sub-combinations will readily become apparent to those skilled in the art upon considering the application as a whole. The subject matter described in this specification and the claims is intended to cover and embrace all suitable changes in the art.

Claims

1. A computer-implemented method for freezing digital assets at a mining node within a blockchain network, comprising: receiving and validating a freeze request message from a freeze management service, wherein the freeze request message includes one or more digital asset identifiers; adding the one or more digital asset identifiers to a pending blacklist stored at the mining node, wherein new transactions received via the blockchain network that include identifiers on the pending blacklist are rejected by the mining node, but new blocks received via the blockchain network that include identifiers on the pending blacklist are acceptable; receiving and validating a freeze order from the freeze management service, wherein the freeze order identifies the freeze request message; in response to the freeze order, adding the one or more digital asset identifiers to a consensus blacklist, wherein both subsequent transactions that include identifiers on the consensus blacklist and subsequent blocks that include identifiers on the consensus blacklist are rejected by the mining node. A method comprising the above steps.

2. The method according to claim 1, wherein the digital asset identifier includes a transaction outpoint identifier.

3. The method according to claim 1, further comprising: generating an acceptance message regarding the freeze request message in response to receiving and validating the freeze request message; digitally signing the acceptance message using a key associated with the mining node to generate a signed acceptance message; and sending the signed acceptance message to the freeze management service.

4. After receiving and validating the freeze request message and before receiving and validating the freeze order, receiving a new transaction via the blockchain network. Determining that the new transaction has at least one of the one or more digital asset identifiers on the pending blacklist as an input; and in response thereto, Rejecting the new transaction The method according to claim 1, further comprising.

5. After receiving and validating the freeze request message and before receiving and validating the freeze order, Identifying a new block mined by another mining node; Determining that at least one transaction in the new block has at least one of the one or more digital asset identifiers on the pending blacklist as an input; Validating and propagating the new block according to the blockchain protocol that manages the blockchain network, despite the one or more digital asset identifiers on the pending blacklist The method according to claim 3, further comprising.

6. The method according to claim 1, further comprising identifying any transaction having at least one of the one or more digital asset identifiers as an input in response to the freeze request message and removing it from the mempool of the pending transactions.

7. Before receiving and validating the freeze order, receiving and validating a thaw request message from the freeze management service, the thaw request message identifying the freeze request message and in response thereto removing the one or more digital asset identifiers from the pending blacklist, the method according to claim 1, further comprising.

8. After receiving and validating the freeze order, Receiving and validating a thaw request message from the freeze management service, the thaw request message identifying the freeze request message; Sending an acceptance message regarding the thaw request message to the freeze management service; Subsequently, receiving and validating a thaw order referring to the thaw request message; and in response thereto, Removing the one or more digital asset identifiers from the consensus blacklist and the pending blacklist The method according to claim 1, further comprising

9. A computer-implemented method for freezing digital assets at a mining node within a blockchain network, comprising: generating a freezing request message at a freezing management service, the freezing request message including one or more digital asset identifiers; transmitting the freezing request message to a plurality of the mining nodes; receiving, from a set of the plurality of mining nodes, an acceptance message as a response to the freezing request message and performing a validity check, each acceptance message being associated with one of the mining nodes within the set of the plurality of mining nodes; determining that the set of the plurality of mining nodes represents hash power exceeding a consensus threshold amount in the blockchain network; in response, generating a freezing order for causing rejection of a new block including a transaction using any of the one or more digital asset identifiers and transmitting the freezing order to the plurality of mining nodes A method comprising.

10. The method according to claim 9, wherein the one or more digital asset identifiers include one or more transaction outpoint identifiers.

11. The method according to claim 10, further comprising receiving, first, a command from a client device, the command including one or more addresses, and identifying the one or more transaction outpoint identifiers based on the one or more addresses using a blockchain address indexer.

12. The step of determining that the set of the plurality of mining nodes represents hash power exceeding the consensus threshold amount in the blockchain network includes determining that the number of blocks within a window of the most recently mined blocks mined by one of the mining nodes within the set exceeds a threshold consensus number. The method according to claim 9.

13. identifying the mining nodes in the set by identifying, for each acceptance message, each public key associated with each digital signature on the acceptance message; detecting an association between a block within a window of the most recently mined blocks and one of the mining nodes in the set by matching each of the public keys with a public key within a coinbase transaction within the block; The method of claim 12, further comprising. **Claim 14** The step of determining that the set of the plurality of mining nodes represents hash power exceeding a consensus threshold amount in the blockchain network is triggered by receipt of a new acceptance message, the method of claim 9. **Claim 15** The step of determining that the set of the plurality of mining nodes represents hash power exceeding a consensus threshold amount in the blockchain network is triggered by identifying a newly mined block on the blockchain network, the method of claim 9. **Claim 16** A computing device, one or more processors, a memory, computer-executable instructions stored in the memory, and wherein the computer-executable instructions, when executed by the one or more processors, cause the processors to perform the method of any one of claims 1 to 15. A computing device. **Claim 17** A computer-readable medium storing processor-executable instructions, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 15.

Images