Method and system for freezing digital assets

Abstract

Systems and computer-implemented methods for freezing or thawing digital assets on a blockchain. The freeze management service may send a signed freeze request to a mining node that maintains two blacklists of a digital asset identifier: a pending blacklist and a consensus blacklist. In some cases, the digital asset identifier may be a transaction outbound point. If the mining node accepts the freeze request, transaction outbound points in the freeze request are added to the pending blacklist, which may result in a rejection of any transactions using these outbound points, but does not result in a rejection of any new blocks including transactions using these outbound points. If an accepted consensus threshold is reached based on the hash computing power, the request becomes a command, and the outpoints are added to a consensus blacklist, which results in a rejection of any transactions or blocks containing transactions using these outpoints.

Description

Technical Field

[0001] The present disclosure relates to a blockchain network, and in particular to a method and apparatus for generating and implementing a freezing operation for digital assets recorded on a blockchain network. Background Art

[0002] Blockchain refers to a form of distributed data structure in which a replica of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely publicized. Transactions in a blockchain are used to perform one or more of the following: transfer digital assets (i.e., some digital tokens), order a collection of journal entries in a virtualized ledger or registry, receive and process timestamped entries, and / or order index pointers in time.

[0003] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of digital assets that can be derived from the proceeding sequence of the transaction. Spendable outputs are sometimes referred to as UTXOs ("unspent transaction outputs") or "out points". In some cases, the protocol may not refer to "outputs" or "out points", but may refer to sender addresses and receiver addresses. The output may also include a locking script that specifies the conditions for future redemption of the output. The locking script is a statement that defines the conditions required to verify and transfer digital tokens or assets. Each input of a transaction (except for coin creation transactions) includes a pointer (i.e., a reference) to such an output in a prior transaction, and may also include an unlocking script for unlocking the locking script of the output pointed to.

[0004] One of the main attractions of blockchain technology, especially in the cryptocurrency community, is its distributed, consensus-based enforcement mechanism that eliminates the need for a trusted authority or intermediary for transactions. However, when fraud or theft occurs, this creates a problem in that there is no mechanism available to freeze digital assets or reverse or not conduct transactions of stolen assets without implementing network-wide software changes and / or rolling back mined blocks. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

[0006] Figure 1 An example system for implementing a blockchain is shown;

[0007] Figure 2 An example transaction protocol is shown;

[0008] Figure 3A An example implementation of a client application is shown;

[0009] Figure 3B An example of a user interface of a client application is shown;

[0010] Figure 4 Example node software for a blockchain node is shown;

[0011] Figure 5 An example system for freezing digital assets is shown;

[0012] Figure 6 A simplified example method of freezing digital assets is shown in the form of a flow chart;

[0013] Figure 7 A simplified example method for implementing freezing at a mining node is shown in flowchart form;

[0014] Figure 8 Another example method of freezing digital assets is shown in the form of a flow chart;

[0015] Fig. 9 Another example method for implementing freezing at a mining node is shown in flowchart form; and

[0016] Fig.10 Overlapping freeze commands and multiple trade-out points are shown in graphical form.

[0017] The same reference numbers are used throughout the drawings to represent the same elements and features. DETAILED DESCRIPTION

[0018] In one aspect, a computer-implemented method of freezing digital assets at a mining node in a blockchain network may be provided. The method may include receiving and confirming 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 new transactions received through the blockchain network including identifiers on the pending blacklist are rejected by the mining node, but new blocks received through the blockchain network including identifiers on the pending blacklist are acceptable; receiving and confirming a freeze command from a freeze management service, the freeze command identifying the freeze request message; and in response to the freeze command, adding the one or more digital asset identifiers to a consensus blacklist, wherein subsequent transactions including identifiers on the consensus blacklist and subsequent blocks including identifiers on the consensus blacklist are both rejected by the mining node.

[0019] In some implementations, the method may further include: in response to receiving and confirming the freeze request message, generating an acceptance message regarding 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.

[0020] In some implementations, the digital asset identifier includes a transaction-out-point identifier.

[0021] In some implementations, the method may further include: receiving a new transaction through the blockchain network after receiving and confirming the freeze request message and before receiving and confirming the freeze command; determining that the new transaction has at least one of the one or more digital asset identifiers on the pending blacklist as input, and in response to the determination, rejecting the new transaction.

[0022] In some implementations, the method may also include: after receiving and confirming the freeze request message and before receiving and confirming the freeze command: 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 input; and confirming and propagating the new block according to a blockchain protocol governing the blockchain network despite the one or more digital asset identifiers being on the pending blacklist.

[0023] In some implementations, the method may further include, in response to the freeze request message, identifying and removing from the memory pool of pending transactions any transactions having at least one of the one or more digital asset identifiers as input.

[0024] In some implementations, the method may further include: before receiving and confirming the freeze command, receiving and confirming a thaw request message from a freeze management service, the thaw request message identifying the freeze request message, and in response to receiving and confirming the thaw request message from the freeze management service, removing one or more digital asset identifiers from the pending blacklist.

[0025] In some implementations, the method may further include: after receiving and confirming the freeze command, receiving and confirming a thaw request message from a 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; later receiving and confirming a thaw command referencing the thaw request message; and in response, removing the one or more digital asset identifiers from the consensus blacklist and the pending blacklist.

[0026] In another aspect, the present application discloses a computer-implemented method for freezing digital assets at a mining node in a blockchain network. The method may include: generating a freeze request message at a freeze management service, the freeze request message including one or more digital asset identifiers; transmitting the freeze request message to a plurality of mining nodes; receiving and confirming an acceptance message from a set of a plurality of mining nodes in reply to the freeze request message, each acceptance message being associated with a mining node in the set of a plurality of mining nodes; determining that the set of a plurality of mining nodes represents a hash power in the blockchain network that exceeds a consensus threshold amount; and in response, generating and sending a freeze command to a plurality of mining nodes to reject new blocks containing transactions using any of the one or more digital asset identifiers.

[0027] In some implementations, the one or more digital asset identifiers include one or more transaction exit point identifiers. In some cases, the method may also include: first receiving a command from a client device, the command including one or more addresses, and using a blockchain address indexer to identify the one or more transaction exit point identifiers based on the one or more addresses.

[0028] In some implementations, determining that a set of multiple mining nodes represents a hash power in the blockchain network that exceeds a consensus threshold amount includes: determining that a number of blocks in a window of recently mined blocks mined by one of the mining nodes in the set exceeds a consensus threshold amount. In some cases, the method may also include: identifying the mining nodes in the set by identifying, for each acceptance message, a corresponding public key associated with a corresponding digital signature on the acceptance message; and detecting an association between a block in the window of recently mined blocks and one of the mining nodes in the set by matching the corresponding public key with a public key in a coin creation transaction in the block.

[0029] In some implementations, determining that the set of multiple mining nodes represents an amount of hash power in the blockchain network that exceeds a consensus threshold is triggered by receiving a new acceptance message.

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

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

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

[0033] Other example embodiments of the present disclosure will become apparent to those of ordinary skill in the art by reviewing the following detailed description in conjunction with the accompanying drawings.

[0034] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including any one, any subcombination or all of the listed elements alone, and does not necessarily exclude additional elements.

[0035] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one, any subcombination or all of the listed elements alone, but does not necessarily exclude any additional elements, nor does it necessarily require all elements.

[0036] Some of the examples provided below will use the Bitcoin protocol as an illustrative example to illustrate the concept. It should be understood that the present application is not limited to the implementation of the protocol, and the present application can be applied to other blockchain protocols, for example, account-based protocols, including Ethereum or other protocols. In the scope of certain terms that are considered to be limited to UTXO-based blockchains, these terms should be understood to have non-protocol-specific definitions. For example, the term "transaction out point" or "transaction out point identifier" should be understood to refer to an identifier of a specific "spendable" or transferable digital asset generated by a blockchain transaction. The transaction out point or transaction out point identifier typically has one or more conditions associated with the ability to spend or transfer the asset, such as confirming a digital signature associated with the wallet address referred to by the transaction out point. The term "digital asset identifier" can be used to refer to a transaction out 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 clearly indicate the sender of a digital asset in a transaction and the receiver of a digital asset.

[0037] Example System Overview

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

[0039] Each blockchain node 104 includes a computer device of a peer, with different nodes in the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device implemented by one or more processors (e.g., one or more central processing units (CPUs), accelerator processors, special processors, and / or field programmable gate arrays (FPGAs)), as well as other devices such as application-specific integrated circuits (ASICs). Each node also includes a memory, i.e., a computer-readable storage device in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media (e.g., magnetic media such as hard disks; electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media such as optical disk drives).

[0040] The blockchain 150 includes a chain of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed network or blockchain network 160. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Rather, the blockchain 150 may be pruned of data, as long as each blockchain node 150 stores a block header for each block 151 (discussed below). Each block 151 in the chain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain will always use a particular transaction protocol. In one common type of transaction protocol, the data structure of each transaction 152 has at least one input and at least one output. Each output specifies an amount of a digital asset representing a certain amount of property, an example of which is a user 103 to whom the output is cryptographically locked (requiring the user's signature or other solution in order to be unlocked, thereby being redeemed or spent). Each input points back to the output of a prior transaction 152, thereby chaining transactions.

[0041] Each block 151 also includes a block pointer 155 that points back to a previously created block 151 in the chain, so as to define the sequential order of blocks 151. Each transaction 152 (except for the coin creation transaction) has a pointer back to the previous transaction, so as to define the order of the transaction sequence (note that branching of the sequence of transactions 152 is allowed). The chain of blocks 151 goes all the way back to the genesis block (Gb) 153, which is the first block in the chain. One or more original transactions 152 earlier in the chain 150 point to the genesis block 153, not to the prior transaction.

[0042] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby propagating transactions 152 throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in their respective memories. Each blockchain node 104 also maintains an ordered set 154 of transactions 152 waiting to be incorporated into blocks 151. Ordered sets 154 are often referred to as "memory pools". This term is not intended to be limited to any particular blockchain, protocol, or model in this article. It refers to an ordered set of transactions that a node 104 has accepted as valid and for which the node 104 must not accept any other transaction that attempts to spend the same output.

[0043] In a given current transaction 152j, an input (or each input) includes a pointer to an output of a prior transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. In general, the prior transaction can be any transaction in the ordered set 154 or any block 151. The prior transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 106, although the prior transaction 152i will need to exist and be proven valid in order for the current transaction to be valid. Therefore, "predecessor" in this article refers to the predecessor in the logical sequence linked by pointers, not necessarily the time of creation or sending in the time sequence, and therefore does not necessarily exclude the creation or sending of transactions 152i, 152j out of order (see the discussion below about orphan transactions). The prior transaction 152i can be equivalently referred to as a predecessor transaction or a previous transaction.

[0044] The input of the current transaction 152j also includes an input authorization, such as the signature of the user 103a to whom the output of the prior transaction 152i is locked. The output of the current transaction 152j can be cryptographically locked to the new user or entity 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the prior transaction 152i to the new user or entity 103b defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to divide the input amount between multiple users or entities (one of which may be the original user or entity 103a for change). In some cases, the transaction may also have multiple inputs to aggregate the amounts of multiple outputs from one or more prior transactions and redistribute them to one or more outputs of the current transaction.

[0045] According to an output-based transaction protocol such as Bitcoin, when an entity 103 such as a user or a machine wishes to make a new transaction 152j, the entity then sends the new transaction from its computer terminal 102 to a recipient. The entity or recipient will eventually send the transaction to one or more blockchain nodes 104 of the network 106 (now usually a server or data center, but in principle it can be other user terminals). It is not excluded that the entity 103 making the new transaction 152j can send the transaction to one or more blockchain nodes 104, and in some examples, not to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol, which is applied at each blockchain node 104. The blockchain node protocol usually requires the blockchain node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which 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 condition defined in the output of the previous transaction 152i assigned by the new transaction, wherein the condition 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 condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, the condition may be simply determined by the blockchain node protocol alone, or the condition may be due to a combination of these. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, thereby forwarding the new transaction 152j to one or more additional nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0046] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated is whether it has been validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the prior transaction 152i that it attempts to allocate or redeem has not been allocated / redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated (unless marked as invalid and propagated for alerts) or recorded in the blockchain 150. This prevents double spending, whereby the transacting parties attempt to allocate the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Again, because there is a defined order of transactions, the account balance has a single, defined state at any time.

[0047] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered set 154 of valid transactions that do not already appear in a block 151 recorded on the blockchain 150. The blockchain nodes then 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 a representation of the ordered set 154 of transactions and hashed, then the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a certain predetermined number of leading zeros. Note that this is only one specific type of proof of work puzzle and does not exclude other types. The property of a hash function is that it has an output that is unpredictable relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0048] The first blockchain node 104 that solves the puzzle announces this to the network 106, providing the solution as evidence, which can then be easily checked by other blockchain nodes 104 in the network (once a hashed solution is given, it can be directly checked that the output of the hash satisfies the condition). The first blockchain node 104 propagates the block to a threshold consensus of other nodes that accept the block and thus implement the protocol rules. The ordered set of transactions 154 then becomes recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points back to the previously created block 151n-1 in the chain. The large amount of effort required to create a proof-of-work solution (e.g., in the form of a hash) demonstrates the intention of the first node 104 to follow the rules of the blockchain protocol. These rules include not accepting a transaction as valid if it allocates the same output as a previously confirmed transaction, otherwise known as a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose a sequential order on the blocks 151. Since the transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this provides an immutable public ledger of transactions.

[0049] Note that different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the ordered set 154 of transactions yet to be published at any given time, depending on when they began searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first 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 based on the newly defined unfinished ordered set 154 of unpublished transactions, and so on. There is also a protocol for resolving any "forks" that may occur, where two blockchain nodes 104 solve their puzzles within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In short, whichever branch of the fork grows the longest becomes the final blockchain 150. Note that this should not affect users or agents of the network, as the same transaction will appear in both forks.

[0050] According to the Bitcoin blockchain (and most other blockchains), nodes that successfully build a new block 104 are granted the ability to distribute the amount of digital assets received in a new special type of transaction that distributes a defined amount of digital assets (as opposed to an inter-agent or inter-user transaction that transfers a certain amount of digital assets from one agent or user to another agent or user). This special type of transaction is often referred to as a "coin creation transaction", but may also be referred to as a "genesis transaction". It usually forms the first transaction of a new block 151n. The proof of work indicates the intention of the node that built the new block to follow the protocol rules that allow the special transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-genesis) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often referred to as a "transaction fee" and will be discussed below.

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

[0052] The memory of each blockchain node 104 stores software that is configured to run on the processing device of the blockchain node 104 to perform its respective one or more roles according to the blockchain node protocol and process transactions 152. It will be understood that any action attributed herein to the blockchain node 104 can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer, or at a lower layer such as an operating system layer or a protocol layer, or any combination of these.

[0053] Also connected to the network 101 is a computer device 102 for each of multiple parties 103 in the role of consuming users. These users can interact with the blockchain network but do not participate in confirming, building, or propagating transactions and blocks. Some of these users or proxy parties 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0054] Some or all of the parties 103 may be connected as part of a different network (e.g., a network overlaid on the blockchain network 106). Users of the blockchain network (often referred to as "clients") may be said to be part of the system that includes the blockchain network; however, these users are not blockchain nodes 104 because they do not perform the roles that blockchain nodes are required to perform. Rather, 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 corresponding devices 102 are shown for illustrative purposes: a first party 103a and his / her corresponding computer device 102a, and a second party 103b and his / her corresponding computer device 102b. It will be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but they are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of illustration, herein the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference to Alice or Bob herein may be replaced with "first party" and "second party" respectively.

[0055] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, dedicated processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable storage device in the form of one or more non-transitory computer-readable media. The memory may include one or more memory units using one or more memory media (e.g., magnetic media such as hard disks; electronic media such as SSDs, flash memory or EEPROMs; and / or optical media such as optical disk drives). The memory on the computer device 102 of each party 103 stores software, for example, a corresponding instance of at least one client application 105 arranged to run on the processing device. It will be understood that any action attributed to a given party 103 herein can be performed using software running on the processing device of the corresponding 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 computer, a smartphone, or a wearable device such as a smart watch. 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 a user terminal.

[0056] The client application 105 may initially be provided to the computer device 102 of any given party 103 on one or more suitable computer-readable storage media, such as by downloading from a server, or provided on a removable storage device (e.g., a removable SSD, a flash drive, a removable EEPROM, a removable disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVDROM, or a removable optical drive, etc.).

[0057] The client application 105 includes at least a "wallet" function. This has two main functions. One of these is to enable a corresponding party 103 to create, authorize (e.g., sign), and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated throughout the network of blockchain nodes 104 and thus included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets he or she currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 that belong to the party of interest and are scattered throughout the blockchain 150.

[0058] It will be appreciated that while various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client function described herein may alternatively be implemented in a suite of two or more different applications, e.g., the applications interface via an API, or one application is a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these. The following will be described in terms of a client application 105, but it will be appreciated that this is not limiting.

[0059] An instance of a client application or software 105 on each computer device 102 is operatively coupled to at least one blockchain node 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact the blockchain node 104 in order to query the blockchain 150 for any transactions that the corresponding party 103 is a recipient of (or indeed to check the transactions of other parties in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to confirm transactions 152 according to the blockchain node protocol and forward transactions 152 to propagate transactions throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol is accompanied by a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106 .

[0060] When a given party 103 (e.g., Alice) wishes to send a new transaction 152j for inclusion in the blockchain 150, she formulates the new transaction in accordance with the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may 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 the transaction in accordance with the blockchain node protocol and its corresponding role. This may include first checking whether the newly received transaction 152j satisfies certain conditions for being "valid" (examples of which will be discussed in more detail later). In some transaction protocols, the conditions for validation may be configurable on a per-transaction basis via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or defined by a combination of the script and the node protocol.

[0061] Under the condition that the newly received transaction 152j passes the test to be considered valid (i.e., under the condition that it is "confirmed"), any blockchain node 104 that receives the transaction 152j will add the new confirmed transaction 152 to the ordered set 154 of transactions maintained at the blockchain node 104. In addition, any blockchain node 104 that receives the transaction 152j will propagate the confirmed transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, the transaction 152j is considered valid, which means that it will be propagated to the entire network 106 quickly.

[0062] Once admitted into the ordered set 154 of transactions maintained at a given blockchain node 104, that blockchain node 104 will begin competing to solve the proof-of-work puzzle on the latest version of its corresponding ordered set 154 of transactions that includes the new transaction 152 (recall that other blockchain nodes 104 may be trying to solve the puzzle based on different ordered sets 154 of transactions, but whoever gets there first will define the ordered set of transactions included in the latest block 151, and ultimately, the blockchain node 104 will solve the puzzle for the portion of the ordered set 154 that includes Alice's transaction 152j). Once the proof-of-work is completed for the ordered set 154 that includes the new transaction 152j, it immutably becomes part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer back to an earlier transaction, so the order of transactions is also immutably recorded.

[0063] Different blockchain nodes 104 may first receive different instances of a given transaction and therefore may have conflicting views about 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 second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance that it had originally accepted (i.e., the instance that has not yet been published in block 151).

[0064] An alternative type of transaction protocol run by some blockchain networks may be referred to as an "account-based" protocol as part of an account-based transaction model. In the account-based case, instead of defining the amount to be transferred by referencing the UTXO of a previous transaction in a sequence of past transactions, each transaction defines the amount to be transferred by reference to an absolute account balance. The current state of all accounts is stored by the nodes of the network, separate from the blockchain and continuously updated. In such a system, transactions are ordered using a running transaction ledger of accounts (also called a "position"). This value is signed by the sender as part of its cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also sign the transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0065] UTXO-based model

[0066] Figure 2 An example transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain 150 (each block 151 contains one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. Please note that although an example of a UTXO-based protocol is described with reference to Bitcoin, a UTXO-based protocol can also be implemented on other example blockchain networks.

[0067] In the UTXO-based model, each transaction ("Tx") 152 is a data structure with 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 of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set number of tokens on a distributed ledger. The UTXO may also contain a transaction ID of the transaction from which it came, as well as other information. The transaction data structure may also include a header 201, which may include an indicator of the size of one or more input fields 202 and one or more output fields 203. The header 201 may also include an ID for the transaction. In some embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself).

[0068] Assume that Alice 103a wishes to create a transaction 152j that transfers a certain amount of the relevant digital asset to Bob 103b. Figure 2In , Alice's new transaction 152j is labeled "Tx1". This new transaction 152j takes a certain amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least some of them to Bob. Figure 2 , the prior transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 can point back to any prior (i.e., previous) transaction that still has unspent outputs 203 locked to Alice.

[0069] When Alice creates her new transaction Tx1, or at least when she sends her new transaction Tx1 to the network 106, the prior transaction Tx0 may have been confirmed and included in the block 151 of the blockchain 150. At this point, the prior transaction Tx0 may have been included in one of the blocks 151, or may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together, or even Tx0 may be sent after Tx1 if the node protocol allows caching of "orphan" transactions. In the context of transaction sequences, the terms "previous" and "subsequent" as used herein refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points back to which other transaction, etc.). They can also be replaced by "predecessor" and "successor", or "predecessor" and "descendant", "parent" and "child", etc. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "children") pointing to a prior transaction (ancestor transaction or "parent") will not be confirmed until and unless the parent transaction is confirmed. Children that arrive at a blockchain node 104 before their parents are considered orphans. Depending on the node protocol and / or node behavior, orphans may be discarded, or cached for a certain period of time to wait for a parent.

[0070] One of the one or more outputs 203 of the prior transaction Tx0 is a specific UTXO, here marked as UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO, and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be confirmed, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction including the locking script). That is, the locking script defines the unlocking condition, which typically includes the following condition: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the prior transaction was locked.

[0071] The locking script (aka scriptPubKey) is a code snippet written in a domain-specific language recognized by the node protocol. A specific example of this language is called "Script" (capital S), which is used by the blockchain network. The locking script specifies what information is needed to spend the transaction output 203, for example, Alice's signature is required. The locking script appears in the output of the transaction. The unlocking script (aka scriptSig) is a code snippet written in a domain-specific language that provides the information required to meet the locking script standard. For example, the unlocking script can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0072] Thus, in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A In order to redeem UTXO0 (strictly speaking, in order to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains the public key P from Alice's public-private key pair A The input 202 of Tx1 includes a pointer back to Tx0 (e.g., by means of its transaction ID, TxID0, which in some embodiments is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 within Tx0 to identify UTXO0 among any other possible outputs of Tx0. The input 202 of Tx1 also includes an unlocking script <Sig P A >, the unlocking script has Alice's cryptographic signature, created by Alice applying her private key from the key pair to a predefined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the locking script, or by the node protocol, or by a combination of these.

[0073] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This may include running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In some embodiments, this may involve cascading two scripts:

[0074] <Sig P A > <P A >||[Checksig P A ]

[0075] Where "||" means concatenation, "<...>" means placing data on the stack, and "[...]" is the function executed by the locking script (a stack-based language in this example). Equivalently, the scripts can be run one after another using a common stack instead of cascading scripts. Either way, when run together, the scripts use Alice's public key P A The unlocking script in the input of Tx1 (included in the locking script in the output of Tx0) authenticates that Alice signed the expected portion of the data with her signature. In order to perform this authentication, the expected portion of the data itself (the "message") also needs to be included. In one embodiment, the signed data includes the entirety of Tx1 (so there is no need to include a separate element specifying the signed portion of the data in plaintext, as it is already inherently present).

[0076] The details of authentication by public-private cryptography are familiar to those skilled in the art. Basically, if Alice has signed a message using her private key, then 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 marking it as a signature onto the message, so that any holder of the public key can authenticate the signature. Therefore, please note that in embodiments, any reference herein to signing a portion of a particular data segment or transaction, etc., may mean signing a hash of that portion of the data segment or transaction.

[0077] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (so in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 will add Tx1 to the ordered set 154 of transactions. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that the transaction Tx1 is propagated throughout the network 106. Once Tx1 has been confirmed and included in the blockchain 150, this qualifies UTXO0 from Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the prior transaction Tx0 has been spent (i.e., whether it has formed a valid input for another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking which UTXOs 203 in which transactions 152 have been spent, but what ultimately determines whether a UTXO has been spent is whether it has formed a valid input to another valid transaction in the blockchain 150.

[0078] This is another basis for invalidity in most transaction models if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202. Therefore, such a transaction will not be propagated and will not be included in block 151.

[0079] Note that in a UTXO-based transaction model, a given UTXO needs to be spent as a whole. It cannot "leave" part of the amount defined in the UTXO to be spent while another part is spent. However, the amount from a UTXO can be divided between multiple outputs of the next transaction. For example, the amount defined in UTXO0 in Tx0 can be divided between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining part to give herself change in the second output of Tx1, or pay another party.

[0080] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 for publishing her transaction. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and thus Tx0, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept transaction 152). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by one or more inputs 202 of a given transaction 152 and the total amount specified in one or more outputs 203 is automatically given to the blockchain node 104 that published the transaction. For example, assume that a pointer to UTXO0 is the only input of Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be distributed by the node 104 that publishes the block containing UTXO1. However, it is not necessarily excluded that, alternatively or additionally, the transaction fee may be explicitly specified in the UTXO itself in the UTXO 203 of the transaction 152 .

[0081] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party's 103 assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. The role of the wallet function in the client application 105 is to collate together the values ​​of all the various UTXOs that are locked to the respective parties and have not yet been spent in another ongoing transaction. It can do this by querying a copy of the blockchain 150 stored at any Bitcoin node 104.

[0082] Note that script code is often represented schematically (i.e., without using the exact language). For example, opcodes may be used to represent specific functions. "OP_..." refers to a specific opcode of the scripting language. For example, OP_RETURN is an opcode of the scripting language that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a document that is desired to be stored in the blockchain.

[0083] Typically, the transaction inputs contain the corresponding public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In some embodiments, for a given transaction, the signature will sign part of the transaction inputs, and some or all of the transaction outputs. The specific part of the output it signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed when signing is done).

[0084] The locking script is sometimes referred to as "scriptPubKey", referring to the fact that it typically includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", referring to the fact that it typically provides a corresponding signature. However, more generally, in all applications of blockchain 150, it is not essential that the conditions for a UTXO to be redeemed include an authentication signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0085] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b, respectively, may include additional communication functions. This additional functionality enables Alice 103a to establish a separate side channel 301 with Bob 103b (at the initiation of either party or a third party). Side channel 301 enables data to be exchanged independently of the blockchain network. This communication is sometimes referred to as "off-chain" communication. For example, this can be used to exchange transactions 152 between Alice and Bob, while the transaction is not (yet) registered on the blockchain network 106 or on the way to the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0086] The side channel 301 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network (e.g., a mobile cellular network, or a local area network such as a local wireless network) or even a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 301 referenced anywhere herein may include any one or more links, via one or more network technologies or communication media, for exchanging data "off-chain" (i.e., separate from the blockchain network 106). Where more than one link is used, then the bundle or collection of off-chain links as a whole may be referred to as a side channel 301. Thus, please note that if Alice and Bob are said to exchange particular segments of information or data, etc., via the side channel 301, then this does not necessarily mean that all of these segments of data must be sent over exactly the same link or even the same type of network.

[0087] Client Software

[0088] Figure 3A An example implementation of a client application 105 for implementing an embodiment of the presently disclosed scheme is shown. The client application 105 may include a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functions of the client 105, for example, configured to formulate transactions 152 according to the process discussed above, receive and / or send transactions and / or other data through the side channel 301, and / or send transactions to one or more nodes 104 for propagation through the blockchain network 106.

[0089] The UI layer 402 is configured to present a user interface via a user input / output (I / O) device of the corresponding user's computer device 102, including outputting information to the corresponding user 103 via the user output device of the device 102, and receiving input back from the corresponding user 103 via the user input device of the device 102. For example, the user output device 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 tactile output devices for providing tactile output, etc. The user input device may include, for example, an input array of one or more touch screens (the same or different from the one / those touch screens used for the output device); one or more cursor-based devices (e.g., a mouse, trackpad, or trackball); one or more microphones and voice or voice recognition algorithms for receiving voice or sound 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.

[0090] Note that while various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting, and rather they may be implemented in a suite of two or more different applications (e.g., one application is a plug-in to another application, or interfaces via an API (application programming interface)). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module such as the transaction engine 401 may be split between more than one application. It is also not excluded that some or all of the described functionality may be implemented at, for example, the operating system layer. Where reference is made anywhere herein to a single or given application 105 or the like, it will be appreciated that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

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

[0092] By way of explanation, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are presented as different UI elements via a user output device.

[0093] For example, the UI elements may include one or more user-selectable elements 501, which may be, for example, different on-screen buttons or different options in a menu, etc. The user input device is arranged to enable the user 103 (in this case Alice 103a) to select or otherwise operate one of the options, for example by clicking or touching the UI element on the screen, or speaking the name of the desired option (note that the term "manual" is used herein only to contrast with automatic, and is not necessarily limited to the use of one or two hands).

[0094] Alternatively or additionally, the UI element may include one or more data input fields 502. These data input fields 502 are presented on, for example, a screen via a user output device, and data may be entered into these fields via a user input device (e.g., a keyboard or a touch screen). Alternatively, data may be received verbally, for example based on speech recognition.

[0095] 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 presented on a screen or in an audible manner.

[0096] It will be appreciated that the specific means of presenting the various UI elements, selecting options, and inputting data are not important. The functionality of these UI elements will be discussed in more detail later. It will also be appreciated that Figure 3B The UI 500 shown in FIG. 5 is only a schematic model and in practice it may include one or more other UI elements, which are not shown for the sake of brevity.

[0097] Node software

[0098] Figure 4 An example of node software 450 running on each blockchain node 104 of the network 106 in an example of a UTXO-based or output-based model is shown. Note that another entity may run the node software 450 without being classified as a node 104 on the network 106 (i.e., without performing the actions required of the node 104). The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection 455 of one or more blockchain-related functional modules. Each node 104 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process them according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j Pointer identification and obtaining Tx in the input i .Tx i can be published on blockchain 150, in which case the protocol engine can obtain Tx from the copy of block 151 of blockchain 150 stored at node 104 i . Or, Tx i may not have been published on blockchain 150. In this case, protocol engine 451 can obtain Tx from the ordered set 154 of unpublished transactions maintained by node 104. i Either way, the script engine 451 is in Tx i The locking script is identified in the output of the reference and passed to the script engine 452.

[0099] Therefore, the script engine 452 has Tx i The locking script and thej For example, transactions labeled Tx0 and Tx1 are in Figure 2 , but this applies equally to any trading pair. As discussed above, the script engine 452 runs two scripts together, which will include placing data on and getting data from the stack 453 according to the stack-based scripting language being used (e.g., Script Script).

[0100] By running the scripts together, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script—that is, does it “unlock” the output including the locking script? The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, it returns a result of “true”. Otherwise, it returns a result of “false”.

[0101] In the output-based model, a "true" result from the script engine 452 is one of the conditions for transaction validity. There are usually one or more other protocol-level conditions evaluated by the protocol engine 451 that must also be met; for example, Tx j The total amount of digital assets specified in one or more outputs of a Tx does not exceed the total amount of digital assets pointed to by its inputs, and i The output pointed to by has not been spent by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and only if all of them are true, the protocol engine 451 confirms the transaction Tx j The protocol engine 451 outputs an indication to the application-level decision engine 454 whether the transaction is valid. j If it is indeed confirmed, the decision engine 454 can choose to control both the consensus module 455C and the propagation module 455P to execute their respective j This can include consensus module 455C adding Tx j The corresponding transaction ordered set 154 to the node is incorporated into the block 151, and the propagation module 455P sends Tx j Forwarded to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish the transaction only if the transaction is valid and there is enough transaction fee left.

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

[0103] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the disclosure is not limited by the described embodiments but only by the appended claims.

[0104] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it will be appreciated that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description may be generally applicable to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

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

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

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

[0108] Freeze digital assets

[0109] One of the reasons for interest in public blockchain networks for digital assets is that they can be used for permissionless, trustless transactions. By eliminating the need for a central authority or trusted entity to facilitate transfers, blockchain networks enable holders of digital assets to directly control and move digital assets to another wallet. However, this also creates challenges for existing regulatory or legal frameworks. In the absence of a mechanism to seize, control, or otherwise force the transfer of assets, it is difficult or impossible to impose a court order on digital assets, even when attempting to resolve clearly provable fraud or theft.

[0110] The growth of interest and investment in cryptocurrencies and other blockchain-based digital asset systems (e.g., NFTs) has also given rise to a large number of fraudulent and malicious acts. There have been many cases where digital assets have been "stolen" by stealing private keys or gaining access to private keys through trickery or deception. In several cases, online transactions have been compromised or found to be fraudulent. Governments, courts, and the financial industry are grappling with how to apply conventional law enforcement or judicial tools to blockchain-based digital assets.

[0111] Attempts to respond to real-world theft, bankruptcy, and fraud affecting blockchain-based digital assets may result in courts or other legal or governmental entities issuing orders to blockchain organizations, blockchain miners, or individual blockchain code programmers. These orders may instruct the recipient to freeze or prevent further transactions in identifiable digital assets and / or to place such assets into safekeeping or escrow. Some blockchain software may lack the ability to implement these actions without completely forking the chain to roll back mined blocks, which would be extremely disruptive to users and could result in huge losses, in addition to undermining confidence and trust in the reliability of the blockchain.

[0112] While it is possible to implement a system that allows a "trusted" legal entity to simply take action on a blockchain network (e.g., force the confiscation of digital assets), such a system would undermine the consensus and independence principles on which distributed ledger technology is based. The present application provides a system and method for freezing digital assets that avoids compromising the consensus-based principles of a blockchain network, and also provides a mechanism for taking measures that only affect identified digital assets without having to roll out customized blockchain node software changes for each command. The present method and system are also constructed to ensure that forking operations are minimized, as forking operations can result in mining resources being wasted on invalid blocks.

[0113] First reference Figure 5 , which shows a simplified diagram of an example system 550 for freezing digital assets. System 550 may include a freeze management service 552. Freeze management service 552 may be implemented using one or more computing devices. In some cases, freeze management service 552 is a network service. One or more user devices 580 may connect to freeze management service 552, for example, using a web browser or a dedicated application, in order to request or manage a freeze event. User device 580 provides user credentials authenticated by freeze management service 552. In some implementations, different levels of permissions may be assigned to different user types.

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

[0115] In some cases, each blacklist manager 554 may have more than one associated blockchain mining node instance 556 for which it is managing blacklists, e.g., a miner operates more than one blockchain mining node instance 556. As described below, in view of the operation of consensus blacklisting of digital assets based on miner acceptance, each miner should operate a blacklist manager even if the miner has more than one blockchain mining node.

[0116] In general, the freeze management service 552 receives an authenticated instruction from one of the user devices 580 to issue a freeze request. The instruction may require certain features (e.g., a court identifier or other credentials) to confirm the instruction. In some cases, the instruction is related to a court order, and in some implementations, the freeze management service 552 can convert the received court order into a machine-readable representation of the court order. In some implementations, the freeze management service 552 can verify one or more digital signatures from an entity authorized to sign a court order. The court order may specify one or more digital assets. The digital asset identifier can clearly indicate a specific address, such as a wallet address, that will be frozen due to a court order. In some cases, a court order may also or alternatively identify a digital asset by a transaction out point; however, in many cases, a court order may identify funds by the association of funds with a wallet address or other public key representation.

[0117] 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 out-points. It will be understood that a single address may be associated with multiple digital assets, which (in the case of certain blockchains) may be identified by the transaction out-points that assign the asset to the single address. For example, a single public key hash address may be the recipient address of many transactions that assign digital assets (e.g., cryptocurrency or NFT) to the address. Each out-point in a transaction that sends a digital asset to the address may be identified by the address indexer 553. The address indexer 553 or an associated service may also be configured to participate in sub-discovery (i.e., tracking operations) to track assets that have been moved from an identified address to one or more other addresses and the associated out-points from the transactions that performed the moves. In some implementations, the address indexer 553 is implemented as part of a general blockchain indexer that is configured to obtain new block data and index transactions that link spent transaction out-points to transaction inputs to enable tracking of digital assets through transactions. A blockchain indexer can connect to one or more blockchain nodes to listen for new blocks and obtain block data.

[0118] The system 550 uses a two-stage or two-level process to implement the freezing of digital assets. The freezing management service 552 can generate a freezing request 572 based on a court order or other instructions. The freezing request 572 specifies the transaction exit point involved in the order, such as the transaction exit point that may have been identified by the address indexer 553. The freezing request 572 can be referred to as a pending freezing order or an expected freezing order. The freezing request 572 can be sent to the blacklist manager 554. In some cases, this can include a push transmission of the freezing request 572 or a notification of a new or updated freezing request 572. In some cases, the freezing request 572 is not sent unsolicited, but is made available for download by the blacklist manager 554, for example, when properly authenticated using a REST API. If the miner accepts the freezing request 572, the blacklist manager 554 can generate and return an acceptance message.

[0119] The freeze management service 552 authenticates the acceptance message associated with the freeze request 572 from the blacklist manager 554 and stores it in a memory (e.g., database 570) as part of the acceptance data 576 associated with the freeze request 572. If acceptance messages are received from more than a threshold number of miners, the freeze management service 552 converts the freeze request 572 into a freeze command 574. The freeze command 574 may then be distributed or made available to the blacklist manager 554, in response to which the blacklist manager 554 implements the freeze command 574 as described below.

[0120] The freeze management service 552 also stores key data 578, including its own public key and securely stored private key, as well as public key data associated with registered or certified miners. In some cases, this may include a miner ID (minerID) registered on the chain and associated with a particular miner. In some cases, the key data 578 includes coin generation public key data. In some cases, the key data 578 may include delegated key data linked to a miner ID or coin generation public key data.

[0121] 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 to confirm the authenticity of the request. It will be appreciated 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 freeze management services' respective public keys or identifiers) that the blacklist manager 554 trusts or that are considered by the miner to be a legitimate authority (whether a government agency or other agency).

[0122] If freeze request 572 is authenticated and determined to be from an accepted freeze management service 552, blacklist manager 554 may generate and send an acceptance message to freeze management service 552. Blacklist manager 554 also causes the transaction out-point in freeze request 572 to be added to pending blacklist 562.

[0123] If sufficient consensus is reached, and the freeze management service 552 converts the request into a freeze command 574, and if the blacklist manager 554 receives or obtains the freeze command 574, the blacklist manager 554 adds the transaction-out point from the pending blacklist 562 to the consensus blacklist 564. In some implementations, even if the transaction-out points are added to the consensus blacklist 564, they are not necessarily removed from the pending blacklist 564. This may have advantages when processing multiple commands involving the same exit point, as will be further described below.

[0124] The blockchain mining node instance 556 implements the following two-stage freezing operation. When the transaction out-point is on the pending blacklist 562, the blockchain mining node instance 556 removes any transaction (e.g., UTXO) with the transaction out-point in the input from its memory pool 560. Any new transaction received from another node (or from other channels, such as merchant APIs or other sources) through the blockchain network using the transaction out-point as input will be rejected as invalid and will not be included in the memory pool 560. In other words, the mining node refuses to mine any transactions involving the transaction out-point and refuses to propagate transactions involving the transaction out-point. However, in this "pending" stage, the mining node will still accept the solved block from another mining node as valid, even if the solved block includes a transaction that spends the transaction out-point. That is, although the mining node itself can regard the out-point as frozen, there is not enough consensus among miners to regard the originally legal block as invalid based on other miners not considering the out-point as frozen. Therefore, the blockchain mining node instance 556 will confirm a block from another miner that includes the transaction out-point, even though the transaction out-point is on the pending blacklist 562.

[0125] Once the transaction-out point is copied from the pending blacklist 562 to the consensus blacklist 564 in response to receipt and confirmation of a freeze command, the blockchain mining node instance 556 will also reject any blocks received from another miner that include the transaction-out point.

[0126] Digital assets frozen by this process can also be unfrozen according to a similar process. To unfreeze a digital asset, the freeze management service 552 can prepare and sign a unfreeze request that references a previous freeze command associated with the digital asset. If a threshold number of mining nodes accept the unfreeze request, the freeze management service 552 issues the unfreeze command. As a result of the unfreeze command, the blacklist manager 554 causes the transaction out-point associated with the digital asset to be removed from the blacklist.

[0127] Now refer to Figure 6 , which shows a simplified example method 600 for freezing digital assets in a blockchain network in the form of a flowchart. The example method 600 can be implemented using a network-connected computing device. In some cases, the computing device can be a computer that operates an online service (e.g., a freezing management service 552 ( Figure 5 )) of a server or server group. The operations of method 600 may be performed by a computing device based on software instructions executed by a processor stored in a 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 a blockchain network as a node of the blockchain network. In many implementations, the computing device does not operate blockchain protocol software and does not constitute part of the blockchain network, but is configured to obtain data from one or more blockchain nodes and send and receive data with one or more mining nodes on the blockchain network.

[0128] In operation 602, a computing device receives a command related to one or more digital assets. The command may be received from a user device via a secure communication channel. Various user accounts may be provided to the computing device, each with a certain level of access rights and authentication credentials. Granting a user account may be based on a subscription or review process, in which it is determined that the user is an authorized representative of a government or legal agency or some other authority claiming to issue commands related to digital assets. The government or legal agency may have one or more identifiers (e.g., public-private keys) stored on the computing device, which are used to digitally sign messages claiming to represent the government or legal agency. Access permissions that provide signing authority using the authority's private key may be assigned to one or more user accounts associated with the authority.

[0129] In some examples, the received order may be a court order. In some cases, the court order may be in analog form and may be digitized by a 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 value of the original court order and / or a hash value of the machine-readable court order may also be generated and stored.

[0130] The command identifies one or more digital assets to be frozen. One or more wallet addresses or other identifiers may be used to identify the digital assets in the command. If desired, the computing system may determine one or more transaction out points based on the blockchain index, which reflect the digital assets assigned to or associated with one or more wallet addresses or other identifiers. In some cases, the command may indicate that the command applies only to wallet addresses or out points identified at a certain point in time, or to funds moved from these addresses after the time associated with the command. As described below, in some cases, the computing system may track digital assets by linking transaction out points to identify the "child" transaction out points on the blockchain to which the assets have been moved from one or more wallet addresses or other identifiers.

[0131] In operation 604, the computing system generates a freeze request message and digitally signs it. The freeze request message may identify the command, for example, by including a hash value of the command or including a complete copy of the command. The command may be encoded using a suitable encoding scheme (e.g., base64, etc.). The freeze request message includes the transaction exit point involved in the request and identifies the authority that issued the command, for example, by its public key, digital certificate, or other identifier. The freeze request message is digitally signed by the authority that issued the command. That is, the user device that provides the command to the computing device has sufficient credentials to enable the computing device to digitally sign the freeze request message using a private key corresponding to the public key associated with the authority. In this way, the recipient of the freeze request message can verify that the message is authentic and originates from the command of the authority. In some cases, the freeze request message may also be digitally signed by the freeze management service; however, in certain other cases, any mining device that accesses the freeze request message has separately confirmed that the freeze request message is legally distributed by the freeze management service.

[0132] The signed freeze request command is distributed to mining nodes that form part of the blockchain network. In some cases, the distribution can be based on actively pushing the signed freeze request command 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 for new freeze messages, and once authenticated by the freeze management service, being provided access to the new freeze messages. In some cases, notifications of newly available freeze messages or commands can be sent to mining nodes, which can then log into the freeze management service and download these messages or commands from the freeze management service.

[0133] In operation 606, after distributing the freeze request message, the freeze management service waits to receive acceptance messages from the mining nodes. The acceptance message identifies the freeze request to which it is associated, 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 acceptances and determines in operation 608 whether sufficient acceptances have been received to reach a consensus threshold. The consensus threshold can be set by the user who uploaded the command. The consensus threshold can be subject to a minimum threshold, which can be set to 50% or higher. In some cases, consensus can also be based on administrator input; that is, in some implementations, once a threshold number of miners accept the freeze request, this results in notification to the administrator of the freeze management service or the user who provided the command, but further authorization is received from the administrator or user before the consensus described below is triggered.

[0134] In some implementations, the consensus threshold can be based on a count of miners, i.e., a percentage of mining nodes; however, this may open the system to abuse if virtual mining nodes may be added to the network. To better track block mining consensus, the consensus threshold can be based on hash power. That is, only acceptances from miners that have mined blocks within a certain time window can be counted for the purpose of evaluating consensus. In one example, the threshold is based on acceptances from mining nodes that represent a minimum percentage of blocks mined within a recent window (e.g., the past 288 blocks). The percentage and window length (number of past blocks) can be configurable when generating a freeze request.

[0135] Once the consensus threshold is reached in terms of the mining node accepting the freeze request, in operation 610, the computing device generates a freeze command and sends the freeze command to the mining node. The freeze command references the freeze request, and in some cases, if the mining node is configured to independently verify that the consensus threshold is reached, the freeze command provides details and / or a copy of the received acceptance. The freeze command may identify the transaction exit point to which the freeze command applies, or an identifier may be provided to link it to the freeze request message in which the exit point is specified. The identifier may be a hash value of the freeze request message, a hash value of the court order, or other such identifier. The freeze command may also indicate the block height at which the freeze command will take effect. That is, the freeze command may not be configured to be implemented immediately after the computing device generates the freeze command or the mining node receives the freeze command, because these times may vary and may result in forks and orphaned blocks. Therefore, the computing device may set the future block height at which the freeze command takes effect. The freeze command is transmitted to the mining node, making the freeze command available to the mining node, or otherwise distributing the freeze command to the mining node.

[0136] Figure 7A simplified example method 700 for implementing a freeze of a digital asset on a blockchain network is shown in the form of a flow chart. The method 700 may be implemented using a network-connected computing device, in particular a mining node that is part of a blockchain network. In some cases, the mining node may be an operating blacklist manager 554 ( Figure 5 The operations of method 700 may be performed by a mining node based on software instructions executed by a processor stored in a memory on a computing device.

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

[0138] In operation 704, the mining node determines whether to accept the freeze request message. The determination of whether to accept the request can be based in part on confirming the message by confirming that the message originates from a freeze management service identified by the mining node. This can be determined based on authentication data exchanged during communication with the service and / or by verifying a digital signature on the freeze request message. The mining node can also or alternatively verify that the freeze request message is based on a command from an authority that it identifies as legitimate. The verification can be based on verifying the digital signature on the freeze request message from the authority. For example, the mining node can have a register or other data structure that stores the public key or other identification data of the authority it identifies as legitimate. Examples can include certain government departments from one or more national or local governments, or certain courts or other administrative tribunals. Miners can configure their mining nodes to identify such authorities that the miners independently determine to be legitimate. The mining node can also verify that the freeze request message meets certain specified format and content requirements.

[0139] If the mining node determines that the freeze request message is legitimate and comes from an identified authority, the mining node may accept the freeze request message; otherwise, it may reject the message, as shown in operation 706. To accept the freeze request message, the mining node, and in particular the blacklist manager, generates an acceptance message and sends the acceptance message to the freeze management service, as shown in operation 708. The acceptance message references the freeze request message and is digitally signed by the mining node using a key pair associated with the mining node. The acceptance message may include an identification address or public key associated with the mining node to enable the freeze management service to correctly identify the blocks mined by the miner, thereby identifying its hash power or voting power in the consensus determination.

[0140] If the mining node accepts the freeze request message, it adds the transaction out-point specified in the freeze request message to its pending blacklist in operation 710. If a transaction is subsequently received over the blockchain network that claims to use one of these transaction out-points as an input, the mining node will consider the transaction invalid, will not add it to the memory pool, and will not propagate the transaction further on the blockchain network. If any pending transactions that have been received include one of these transaction out-points as an input, the mining node also removes these transactions from its memory pool.

[0141] By placing transaction out-points into the pending blacklist, mining nodes subsequently exclude transactions involving these out-points from any candidate blocks being mined by the mining node, and do not propagate any pending transactions involving these out-points. However, because the freeze has not yet been achieved by consensus, if a mined block is received during this period, the mining node will still accept the mined block as valid, even though the mined block includes a transaction that includes one of the transaction out-points from the pending blacklist as an input. During this period, any such block received and confirmed is added to the blockchain, despite the fact that it involves a transaction using the digital asset that is subject to the intended freeze.

[0142] In operation 712, the mining node monitors the implementation of the consensus freeze. The consensus freeze can be indicated by the freeze management service by issuing a signed freeze command. As described above, the freeze command can provide details of the acceptance received from each mining node. In some implementations, the mining node can verify that a consensus has been reached as part of confirming the freeze command. In some implementations, the freeze command can be received from the freeze management service by querying and downloading by the mining node or by receiving a push transmission from the freeze management service. If the mining node determines that the freeze command is valid, then in operation 714, the mining node copies the transaction out point from the pending blacklist to the consensus blacklist. In these examples, the mining node does not remove the transaction out point from the pending blacklist, which may be beneficial when resolving multiple freeze requests or freeze command conflicts.

[0143] Now refer to Figure 8, which shows another example method 800 for freezing digital assets associated with a blockchain network. Method 800 can be implemented by a computing device configured to provide a freezing management service. In operation 802, the computing device receives and authenticates a command about a digital asset. As described above, the command can originate from an authority, and the computing device can use one or more mechanisms to verify the legitimacy of the command. The computing device generates a freeze request message and digitally signs it, as shown in operation 804. The digital signature can be a digital signature of the authority that issued the command. The generation of the freeze request message may include determining a transaction exit point involved in the freeze based on the digital asset identified in the command received from the authority. In some cases, the identification of the transaction exit point may include tracking assets from an address used in a transaction exit point (e.g., a payment to a public key hash address) to other addresses in subsequent transactions using indexed transaction data about the blockchain.

[0144] Operation 804 also includes distributing the freeze request message to the mining nodes, and in particular to the network-connected computing devices at the mining nodes implementing the blacklist manager. Each blacklist manager can be used to manage the blacklist of a single miner, but if the miner operates multiple mining node instances, each blacklist manager can manage the blacklists at multiple mining node instances.

[0145] Once the freeze request message has been distributed to the blacklist managers, the computing device waits to receive an acceptance message from these blacklist managers on behalf of their respective miners. If the computing device detects a new acceptance message, as shown in operation 806, then in operation 808, the computing device confirms the message and stores the acceptance data in the memory. Confirmation may include verifying that the message is digitally signed by the mining node. In some cases, the mining node may have an identity (e.g., a miner ID) registered on the blockchain, which enables the computing device to verify that the miner ID is valid and legal and corresponds to the digital signature applied to the acceptance message. Other mechanisms may also be used to verify that the acceptance message is digitally signed by the identified mining node of the blockchain network. The acceptance message may include key data related to the miner. That is, it may include a miner ID, a public key, or a public key hash value associated with the miner, which enables the computing device to identify the block mined by the miner based on the miner ID, public key, or public key hash value corresponding to the private key used to sign the acceptance message. In some cases, such blocks can be identified based on the address to which the block reward is allocated in the coin creation transaction within the block. A coin creation transaction can assign the block reward to the public key hash corresponding to the public key specified in the accept message.

[0146] In some cases, a mining node may not want to use its genesis public key address in conjunction with this functionality, but may instead wish to use a different key pair to sign the accept message, in which case it may link the genesis key to the signing key pair via a key delegation operation, as described below. If so, the accept message may include delegated key data that enables a computing device to associate the public key hash value in the genesis transaction with a particular miner, even if the digital signature used to sign the accept message is not the corresponding private key.

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

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

[0149] In some cases, the window can be a time window, or a number of blocks. In some examples, the number of blocks can be approximately 288, which represents approximately two days of mining time on the Bitcoin network, given that the average time to mine a block is approximately 10 minutes. In other blockchain networks, different measures of mining hash power can be used to assess the percentage of hash power that has accepted the freeze request message.

[0150] The window can be a window of recent blocks from the current block or the current time back to represent a measure of recent hash power in the blockchain network. In some cases, longer windows spanning days or weeks may be desirable to avoid rented or temporary hash power surges from exerting too much control over frozen consensus.

[0151] In some cases, the window begins only when the freeze management service issues a freeze request message, or some other time associated with command generation or upload or freeze request message generation or distribution. The window then waits for at least a threshold number of blocks (e.g., 288 or other specified number) to be mined, and after the threshold number of blocks is reached, the computing device then begins evaluating whether a consensus threshold percentage acceptance has been reached. The window can expand to include new blocks from that point on, or can be a moving window that only considers a specified number of recent blocks.

[0152] As shown in operation 816, if a threshold number or percentage of blocks in the window are associated with miners that accept the freeze request message, then in operation 818, the computing device generates, signs, and distributes a freeze command message. The freeze command message is a freeze command and may specify a transaction exit point to which it applies, or may reference a transaction exit point by referencing a freeze request message. The mining node, particularly the blacklist manager, that receives the freeze command message adds the frozen transaction exit point to the consensus blacklist. The freeze annotation message may specify an implementation time or an implementation block height. Transaction exit points on the consensus blacklist that appear in a block after the implementation time or block height cause the block to be invalid. Therefore, once sufficient consensus is reached to issue a freeze command message, even mining nodes that have not accepted the freeze request message may implement the freeze, otherwise they risk wasting energy mining invalid blocks that will be rejected by the network.

[0153] If consensus has not been detected in operation 816, the computing device may return to operation 806 to await further acceptances and / or additional blocks in the window to evaluate the accepting hash power.

[0154] As described above, determining whether consensus has been reached is based on receiving an acceptance message signed by a miner and confirming that the miner has recently mined at least one block. In one embodiment, the process of associating a new block with a specific miner may include:

[0155] 1. Build the public key set used in the coin creation document:

[0156] (a) If the coin creation transaction contains a single P2PKH output, and all other outputs are not payment outputs (e.g., OP_RETURN, OP_FALSEOP_RETURN, etc.), then the corresponding public key is added to the set. If there are multiple P2PKH outputs or other non-standard outputs, then no key is added to the set;

[0157] (b) If the coin creation transaction contains a valid miner ID, add it to the set. Also add all pre-miner IDs from the beginning of the block window being evaluated (e.g., 288 blocks back in the chain from the current new block), where, in implementations where miners can rotate their keys, a “pre-miner ID” is a previous miner ID linked to the current miner ID.

[0158] 2. If the set contains the public key of the acceptance message, the acceptance message is associated with the block.

[0159] 3. If the set contains any key listed as a delegate public key in the delegate key data within the accept message, and the public key corresponding to the signed accept message is among the delegate public keys listed in the delegate key data, then the accept message is associated with the block.

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

[0161] Note that in step 3, only the delegated public keys from the current accept message are considered, which means that the key delegation is only valid within the scope of that acceptance. If a mining node submits acceptances for two different freeze requests, each acceptance message may contain a different set of keys, and the presence of a delegated key in one accept message pertaining to that miner does not necessarily transfer to another accept message from that miner unless it contains delegation key data specifying that delegated public key.

[0162] In some embodiments, when calculating the percentage of hash power associated with an acceptance message, the window looks back a set number of blocks (e.g., 288) from the most recently mined block. This decouples the acceptance process from mining new blocks. As long as a miner mines a block within the window, it does not need to mine a new block in order for its acceptance to be counted. Therefore, acceptances can be collected over a short period of time, assuming that the past hash power distribution is a fairly good indicator of the current hash power distribution.

[0163] Fig. 9 Another example method 900 for implementing a digital asset freeze on a blockchain network is shown. The method 900 can be implemented by a computing device associated with a blockchain miner, and in particular by a blacklist manager operating on the computing device. The blacklist manager can be implemented by software instructions that, when executed by a processor of the computing device, cause the computing device to perform the operations described. The computing device can manage freezing and thawing operations related to digital assets for at least one instance of a blockchain mining node.

[0164] In operation 902, the blacklist manager obtains or receives a freeze request message from a freeze management service. The freeze request message identifies the authority that issued the command and the transaction exit point to which the freeze request applies. The freeze request message may also provide detailed information about the consensus threshold and an encoded copy or representation of the command from the authority. In operation 904, the blacklist manager confirms at least one digital signature on the freeze request message. This may be a digital signature associated with an authority, thereby indicating that the request is related to a legitimate command from an authority. The freeze message may also or alternatively include a digital signature from a freeze management service, which in some implementations may itself be considered an authority. If the digital signature cannot be verified using the corresponding public key, the request message is rejected in operation 906. In some cases, the request may be rejected by simply not responding to the request.

[0165] In operation 908, the blacklist manager determines whether to accept the freeze request. The determination may be based on multiple factors set within the blacklist manager and may be configurable by the management of the blockchain miner. The determination may be based on whether the authority is recognized as an authority by the blacklist manager. The blacklist manager may have a list or other data structure that identifies the identified authority (and in some cases, identifies its corresponding (one or more) public keys). In some cases, the determination may be based in part on the consensus threshold being at least a minimum percentage or amount. In some implementations, the determination may also be based on the nature of the digital asset, such as whether the digital asset is related to a cryptocurrency or is a token (e.g., a non-fungible token (NFT), or a specific type of NFT involved). If the blacklist manager determines that the freeze request does not meet the acceptance criteria it has set, it rejects the request 910. In some cases, it may reject the request by simply not responding to the request.

[0166] If the request is accepted, the blacklist manager generates and digitally signs an acceptance message and transmits the acceptance message to the freeze management service, as shown in operation 912. The acceptance message references the freeze request message and includes the digital signature of the mining node. The digital signature may use a miner ID key pair, or other key set associated with the mining node. The key used corresponds to an address or identifier used or referenced in the block mined by the mining node, such as an address to which a coin creation transaction can be paid, or is linked to such an identifier or address through a 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 when signing the acceptance message.

[0167] If the request is accepted, then in operation 914, the blacklist manager also adds all transaction out-points identified in the freeze request message to a pending blacklist maintained at any mining node instance associated with the freeze request message. The blacklist manager may accomplish this using, for example, a remote procedure call (RPC) function defined to edit or modify a blacklist stored in a memory at a blockchain mining node instance. In some cases, the mining node instance is also configured to search existing pending transactions in its memory pool to determine whether these existing pending transactions involve any newly blacklisted transaction out-points as input, and if so, remove them from the memory pool and from any candidate blocks being mined by the mining node instance.

[0168] Once the transaction exit point is added to the pending blacklist(s), the blacklist manager waits for the freeze management service to issue a consensus-based freeze command, or a "thaw" request that effectively cancels the previously accepted freeze request. Meanwhile, the mining node instance continues mining operations, searches for proof-of-work solutions for candidate blocks, and confirms newly received transactions and solved blocks from other mining nodes. As shown in operation 916, if the mining node receives a new transaction through the blockchain network, then in operation 918, the mining node instance determines whether the new transaction involves a transaction exit point on its pending blacklist or consensus blacklist. The mining node instance can use any suitable comparison or matching process to evaluate whether the transaction input on the new transaction corresponds to a transaction exit point on the blacklist. If not, the mining node instance confirms the new transaction as usual according to the management blockchain protocol and adds it to the memory pool of unconfirmed transactions, as shown in operation 920. The mining node instance also propagates the new transaction on the blockchain network according to the blockchain protocol. However, if the new transaction involves a transaction exit point on the pending blacklist or consensus blacklist, then in operation 922, the mining node rejects the new transaction and excludes it from the memory pool. Mining nodes do not propagate rejected transactions on the blockchain network.

[0169] In some cases, as shown in operation 924, while waiting for the consensus freeze command, the mining node may receive a newly mined block or a message about a newly mined block from another mining node. In operation 925, the mining node may evaluate whether the block contains any transactions that reference transaction out-points that appear on the consensus blacklist, and if so, reject the block 926. Note that if the transaction out-points are only on the pending blacklist, the mining node will not reject the block because the entire blockchain network has not yet concluded that these out-points are subject to consensus freeze. If the transaction does not involve any out-points on the consensus blacklist, then in operation 927, the block is confirmed and added to the blockchain according to the usual blockchain protocol. This can include adding blocks featuring the following transactions: These transactions have one or more transaction out-points that appear on the pending blacklist as input. Despite this, the new block will still be considered valid. Even if the transaction out-point is later added to the consensus blacklist due to reaching the consensus threshold, the newly mined block will not be retroactively invalidated.

[0170] In operation 928, the blacklist manager evaluates whether a consensus freeze command has been received in connection with the freeze request message. If so, the blacklist manager causes the mining node to copy the transaction exit points identified in the freeze request message from the pending blacklist to the consensus blacklist. In many cases, the consensus freeze command specifies the block height at which the freeze occurs, in which case the blacklist manager waits for that block height to be achieved before adding the transaction exit points to the consensus blacklist. Once the transaction exit points are on the consensus blacklist, any subsequent new transactions or newly mined blocks involving these transaction exit points will be rejected as invalid. Any previously mined blocks added to the blockchain before the consensus freeze command took effect and involving these transaction exit points as input are not invalidated.

[0171] The above method relates to a freezing operation for a specified digital asset. A similar method can be used when performing an unfreeze operation. The unfreeze operation can be regarded as canceling or revoking a freeze request or a freeze command. In some implementations, in order to make the unfreeze request effective, the unfreeze request message is digitally signed by the same authority as the freeze request message. That is, in some examples, the freeze request or freeze command cannot be withdrawn or revoked by a different authority. In some cases, if the key is related, the unfreeze request can be signed by a key different from the freeze request.

[0172] In one variation, in some implementations, a higher authority can implement and unfreeze operations, where the original freeze operation was initiated by a lower authority. For example, a court may issue an order to freeze certain digital assets, but a higher court may allow an appeal against the order and direct that the freeze order be revoked or cancelled. In some cases, the blacklist manager may have stored on it a hierarchy of designated relevant authorities so as to know which authorities can override which other authorities. In some cases, no one authority can override another, so the appellate court must have the lower court digitally sign the unfreeze request message in order for the appeal decision to be effective.

[0173] If a freeze request message has been distributed but consensus has not yet been reached, the corresponding unfreeze request message received and accepted by the blacklist manager will cause the blacklist manager to remove the affected transaction exit points from the pending blacklist, provided that these transaction exit points are not also implicated by another different freeze request message. The interaction of different requests and commands from different authorities involving the same digital asset will be further discussed below.

[0174] If consensus has been reached and a freeze command has been generated, the unfreeze request message is considered just like the freeze request message and must reach consensus before action can be taken. However, for unfreeze request messages, the blacklists do not change immediately; mining nodes continue to maintain transaction exit points on both blacklists until a consensus threshold is reached on the unfreeze request message and the unfreeze command is distributed. At this point, the blacklist manager causes the transaction exit points to be removed from both blacklists, making them available for valid transactions thereafter.

[0175] As described above, in some cases, the command from the authority may specify one or more specific digital assets by an address (e.g., a wallet address, a pay-to-public-key-hash (P2PKH) address, a pay-to-script-hash (P2SH) address, or other forms of addresses). In some cases, in addition to or instead of specifying an address, the command may specify a transaction out-point. The address indexer at the freeze management service or an address indexer accessible to the freeze management service is configured to resolve a transaction out-point from an address, i.e., identify a transaction out-point that sends a digital asset to a specific address. The address indexer may also be configured to track the children of a transaction out-point (TXOUT), i.e., find a transaction out-point that is used as an input for a later transaction, and identify the output of the later transaction as a child out-point linked to the TXOUT. The indexer may be an independent or separate component accessible through a REST API or similar interface. The indexer may be connected to a blockchain node instance to listen for new blocks and obtain block data. The address indexer uses data from blocks on the current chain and unconfirmed transactions in the memory pool. In some other implementations, the address indexing operation may be implemented at the mining node level, meaning that the freeze management service may issue freeze request messages identifying addresses, and the blacklist manager / mining node may perform the function of tracking specific exit points mapped to those addresses.

[0176] In some cases, the address indexer can be configured to receive an address and a time, and will provide in reply a collection of TXOUTs, each of which can be specified as a pair formed by a transaction identifier (TXID) and an output index (vout). The collection will reference TXOUTs created in blocks no earlier than the specified time.

[0177] In some cases, the address indexer may be configured to provide child data related to a TXOUT. In this regard, the address indexer may provide a function or API in which it receives a TXOUT and provides an array or other data structure specifying the TXOUT and a collection of child TXOUTs. The address indexer may also provide information about the block in which the TXOUT was used to generate the child TXOUT. An array may be provided because a single TXOUT may be spent multiple times in the presence of a fork.

[0178] When a command specifies that child out-points are to be frozen in addition to any specific transaction out-points, an address indexer may be used to track the digital assets passed to the new transaction out-points when generating a freeze request command. In one example implementation, this may be performed as follows:

[0179] a) Scan all blocks from the TXOUT creation time to the latest time. This can be very time consuming.

[0180] Scanning the entire blockchain can take hours and a lot of resources;

[0181] b) Use an off-the-shelf graph database or a custom implementation and update relations immediately when new blocks arrive (requires more storage upfront);

[0182] c) perform a recursive lookup for each frozen asset using a series of calls to an existing address / output indexer (e.g., an ElectrumX server) and a fully indexed blockchain node. This can become slow due to address reuse; or

[0183] d) Build a custom indexer component that will index addresses and how outputs are spent (and new outputs are created).

[0184] Regardless of whether the command specifies an address or a specific transaction exit point, the freeze management service begins by identifying the transaction exit points affected. The freeze management service can then track any transactions that use these transaction exit points (i.e., child exit points), and the child exit points are added to the list of transaction exit points. Note that new addresses to which the child exit points allocate assets will not be added, as this may involve other unrelated assets held by the address.

[0185] In these examples, the responsibility for identifying the exit points of child transactions lies with the freeze management service. The benefits of this are that mining nodes can therefore run non-indexing or pruned nodes, mining nodes do not require an address indexer or child discovery tracking capability, and the list of exit points in the freeze request message digitally signed by the authority is static and public to all miners, thereby avoiding the risk of inconsistent freezes and chain forks. The disadvantage is that during the time from the generation and distribution of the freeze request message to the miner and the miner's acceptance of the request, subsequent movements of assets from the identified exit points will result in escaping the freeze. If additional child exit points are to be included in the freeze request after the signed freeze request message has been distributed, the freeze management service and authority may generate and send a second or subsequent freeze request message.

[0186] As described above, TXOUT may be affected by more than one freeze request and / or freeze command from the same authority or different authorities. The blacklist manager may be responsible for integrating the state and ensuring that the blockchain node instance has a unified view. In this regard, if the exit point appears in at least one freeze request message and there is no consensus freeze command that lists the exit point, the blacklist manager may consider the exit point to be pending freeze, i.e., belonging to the pending blacklist. Similarly, if the exit point is subject to at least one consensus freeze command and the freeze command has not been revoked / canceled due to a consensus thaw command that references the freeze command, the exit point is considered frozen, i.e., belongs to the consensus blacklist. In some implementations, if there are two consensus freeze commands from different authorities that affect the transaction exit point, and a subsequent consensus thaw command that references the transaction exit point is distributed, the blacklist manager will unfreeze the transaction exit point regardless of the fact that more than one freeze command has been applied to it. However, in many other implementations, the thaw command is only valid for unfreezing the exit point for a specific related freeze command. That is, if an exit point is subject to two consensus freeze commands, a consensus thaw command that references one of these freeze commands will not be sufficient to remove that exit point from the consensus blacklist until a consensus thaw command that references the other freeze command is also distributed.

[0187] As an example, Fig.10 A collection of interrelated transactions is shown in diagram form. The transactions include transaction A and transaction D, each of which has at least one out-point used in transaction A1, which has at least one out-point used in transaction A2 and one out-point used in transaction B2. Transaction C has at least one out-point used in transaction C1, which has at least one transaction out-point used in transaction B2 and at least one out-point used in transaction C2. Transaction B3 takes at least one transaction out-point from B2 as input. In some implementations, each transaction may have at least one unspent transaction out-point.

[0188] The first court order may identify the digital assets associated with transaction A and related transactions A1, A2, B2, and B3. A freezing request may be generated that identifies the transaction exit points in 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 freezing management services at different times. In addition, corresponding thawing orders may be generated later for any or all of the court orders, which may result in conflicting orders affecting the same exit point. To illustrate, the following chart maps the processing of freezing requests, freezing orders, and thawing orders for these three example court orders:

[0189]

[0190]

[0191]

[0192]

[0193] In some cases, different freeze or unfreeze commands that reference the same digital asset may specify different block heights at which the commands take effect. In this case, the following rules may apply in some implementations:

[0194] 1. If the same exit point is referenced by multiple consensus freeze commands with different enforceAtHeight values, the exit point is added to the consensus blacklist using the minimum value.

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

[0196] 3. If the same exit point is referenced by multiple consensus thaw commands with different enforceAtHeight values, and these thaw commands reference different freeze commands, then when the last consensus thaw command takes effect, if there are no other active consensus freeze commands affecting the exit point, the exit point can be removed from the consensus blacklist and pending blacklist.

[0197] In the example above, once the consensus threshold is reached, the freeze management service generates and distributes a freeze command (a consensus activation document). In response, the mining node adds the specified transaction out points to the consensus blacklist, and thereafter, blocks including transactions that spend any of these specified transaction out points will not be confirmed or propagated. This may be referred to as a "hard consensus freeze". However, in some implementations, the mining nodes may be configured to implement a "soft consensus freeze".

[0198] In a "soft consensus freeze", mining nodes still maintain a consensus blacklist identifying frozen transaction out-points. If a block containing a transaction that spends one of the frozen transaction out-points is received, the mining node still considers the block invalid. The mining node considers the block "frozen". Soft consensus freeze is implemented by a block count N, which can be specified in the freeze command or predetermined and set by the protocol. In operation, mining nodes consider "invalid" blocks to be frozen and will consider them invalid unless more than N blocks are added to the "invalid" block. In other words, despite the fact that the out-point is a consensus freeze, not every mining node may consider it frozen. Some mining nodes may continue to mine as if the transactions spending these out-points are valid, and if these mining nodes are successful enough, they may successfully build a chain of more than N blocks on top of the "invalid" block. In this case, the mining nodes that originally considered the block "invalid" will reverse this decision and now consider the block valid and the chain as the best tip candidate.

[0199] As described in the above illustrative embodiments, various documents or message types may be exchanged between the freeze management service and the blacklist manager, or between the blacklist manager and the mining node instance. Various documents are digitally signed by an authority, freeze management service, mining node, etc. When the original document is stored as a string in the payload field, an encapsulation signature may be used, for example, as described in the JSON Envelope spec BFRC 6a7a2dec8b17.

[0200] An illustrative example document structure is provided below, but it should be understood that variations may be made in some implementations. Any particular implementation may specify a document structure to achieve interoperability and standardize communications. In the examples below, not all fields are required fields for a valid document.

[0201] Freeze request message

[0202]

[0203]

[0204]

[0205]

[0206] Listing transaction outputs that have already been spent has no effect. Blocks that spend such outputs will not be invalidated when the command is executed. The validity of such outputs will not change even when new nodes download the blockchain or when existing nodes are reindexed, because they were created before enforceAtHeight. Such outputs appear on freeze request messages for integrity reasons; for example, so auditors can use them to trace unspent outputs back to root funds identified by an authority.

[0207] Thawing request message

[0208]

[0209]

[0210] The parameter freezeHash can be a hash value (e.g., SHA256) of the hash value of the signature function that is input to the freeze request document. In an example process:

[0211] 1. Get a digitally signed freeze request message (e.g., as specified by the JSON Envelope spec);

[0212] 2. Compute the hash value of the payload by converting the string value into stream bytes using the encoding specified in the Encoding field.

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

[0214] 4. Reverse the bytes and convert them into a hex-encoded string.

[0215] accept

[0216] When a miner (e.g., a blacklist manager) determines that a freeze request (or unfreeze request) is to be accepted, it generates an acceptance message, signs the acceptance message, and sends the acceptance message to the freeze management service. The acceptance will be signed by the private key of the mining node. If the protocol adopts a miner ID or equivalent miner identifier scheme, the digital signature can use this key pair. An example structure of an acceptance message is:

[0217]

[0218]

[0219] In this example, each entry in delegatingKeys will list the public key within the delegatingPublicKey array (which may allow for the listing of additional public keys) that corresponds to the private key used to sign the Acceptance document. In other words, an Acceptance document must not include a delegatedKeys document that does not grant signing authority to the key used to sign the Acceptance document.

[0220] The delegatedKeys document can be used in situations where a mining node does not want to use the private key associated with the public key used in the coin creation transaction. The coin creation transaction is associated with a valuable resource, and the mining node may not want to use the associated key for other purposes. The delegatedKeys document is a way to link the key used in the coin creation transaction to additional keys that can be used to sign Acceptance documents and 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 will be signed by the key used in the coin creation transaction (the delegation key). An example document can have the following structure:

[0221]

[0222]

[0223] Once the Freeze Management Service determines that the consensus threshold has been reached, it generates, signs, and sends a freeze command message or a thaw command message. In some cases, this may be referred to as a "consensus activation" document. The document is signed using the private key associated with the public key of the authority that issued the order to freeze / thaw the digital asset. This document may be in the form of:

[0224]

[0225]

[0226] It will be noted that a freeze command or thaw command (e.g., a consensusActivation document) includes all acceptances from miners regarding the command and details of blocks within the window associated with the miner that signed the acceptance. This enables each mining node to independently verify that consensus was reached. The enforceAtHeight field indicates the block height at which the transaction exit point will be added to the consensus blacklist in order to begin enforcing the freeze / thaw. The enforceAtHeight value of the thaw command must be greater than the enforceAtHeight value in the associated freeze command.

[0227] The above document structure is illustrative. It will be appreciated that various changes may be made to remove or add various fields or to change the encoding or requirements of the document.

[0228] The various embodiments presented above are merely examples and are by no means meant to limit the scope of the present application. It will be apparent to those of ordinary skill in the art for the changes to the innovations described herein, and such changes are within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments, which include sub-combinations of features that may not be explicitly described above. In addition, features from one or more of the above-described example embodiments may be selected and combined to create alternative example embodiments, which include combinations of features that may not be explicitly described above. For those skilled in the art, after reading the present application as a whole, features suitable for such combinations and sub-combinations will be apparent. The subject matter described herein and recited in the claims is intended to encompass and include all suitable technical changes.

Claims

1. A computer-implemented method for freezing digital assets at a mining node in a blockchain network, the method comprising: 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 new transactions received through the blockchain network that include identifiers on the pending blacklist are rejected by the mining node, but new blocks received through the blockchain network that include identifiers on the pending blacklist are accepted; receiving and validating a freeze command from the freeze management service, the freeze command identifying the freeze request message; and In response to the freeze command, the one or more digital asset identifiers are added to a consensus blacklist, wherein subsequent transactions including identifiers on the consensus blacklist and subsequent blocks including identifiers on the consensus blacklist are rejected by the mining node.

2. The method according to claim 1, wherein: The digital asset identifier includes a transaction exit point identifier.

3. The method according to claim 1, further comprising: In response to receiving and validating the freeze request message, generating an acceptance message regarding 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. The method according to claim 1, further comprising: After receiving and confirming the freeze request message and before receiving and confirming the freeze command: receiving new transactions via the blockchain network; determining that the new transaction has as input at least one of the one or more digital asset identifiers on the pending blacklist; and Responsive to the determination, the new transaction is rejected.

5. The method according to claim 3, further comprising: After receiving and confirming the freeze request message and before receiving and confirming the freeze command: Identifies a new block mined by another mining node; determining that at least one transaction in the new block has as input at least one of the one or more digital asset identifiers on the pending blacklist; as well as Despite the one or more digital asset identifiers being on the pending blacklist, the new block is still confirmed and propagated according to a blockchain protocol governing the blockchain network.

6. The method according to claim 1, further comprising: In response to the freeze request message, any transactions having at least one of the one or more digital asset identifiers as input are identified and removed from the memory pool of pending transactions.

7. The method according to claim 1, further comprising: Before receiving and confirming the freeze command, receiving and confirming a thawing request message from the freeze management service, the thawing request message identifying the freeze request message; And in response to receiving and confirming the unfreeze request message from the freeze management service, removing the one or more digital asset identifiers from the pending blacklist.

8. The method according to claim 1, further comprising: After receiving and confirming the freezing order, receiving and confirming a thawing request message from the freeze management service, the thawing request message identifying the freeze request message; Sending an acceptance message regarding the thawing request message to the freezing management service; later receiving and confirming a thaw command referencing the thaw request message; as well as In response to receiving and confirming the thaw command referencing the thaw request message, removing the one or more digital asset identifiers from the consensus blacklist and the pending blacklist.

9. A computer-implemented method for freezing digital assets at a mining node in a blockchain network, the method comprising: generating, at a freeze management service, a freeze request message, the freeze request message including one or more digital asset identifiers; transmitting the freeze request message to a plurality of mining nodes; receiving and confirming acceptance messages from the set of the plurality of mining nodes in reply to the freeze request message, each acceptance message being associated with a mining node from the set of the plurality of mining nodes; Determining that the set of the plurality of mining nodes represents an amount of hash power in the blockchain network that exceeds a consensus threshold; as well as In response, a freeze command is generated and sent to the plurality of mining nodes to cause new blocks containing transactions using any of the one or more digital asset identifiers to be rejected.

10. The method according to claim 9, wherein: The one or more digital asset identifiers include one or more transaction-out-point identifiers.

11. The method according to claim 10, further comprising: First, a command is received from a client device, the command including one or more addresses, and the one or more transaction exit point identifiers are identified based on the one or more addresses using a blockchain address indexer.

12. The method according to claim 9, wherein: Determining that the set of the plurality of mining nodes represents an amount of hash power in the blockchain network that exceeds the consensus threshold amount includes determining that a number of blocks in a window of recently mined blocks mined by one of the mining nodes in the set exceeds the consensus threshold amount.

13. The method according to claim 12, further comprising: identifying mining nodes in the set by identifying, for each acceptance message, a corresponding public key associated with a corresponding digital signature on the acceptance message; as well as An association between the block and one of the mining nodes in the set is detected by matching the corresponding public key with a public key in a coin creation transaction in a block in the window of the most recently mined block.

14. The method according to claim 9, wherein: Determining that the set of the plurality of mining nodes represents an amount of hash power in the blockchain network that exceeds the consensus threshold is triggered by receiving a new acceptance message.

15. The method according to claim 9, wherein: Determining that the set of the plurality of mining nodes represents an amount of hashing power in the blockchain network that exceeds the consensus threshold is triggered by identifying a newly mined block on the blockchain network.

16. A computing device, the computing device comprising: one or more processors; Memory; as well as Computer executable instructions stored in the memory, when executed by the one or more processors, cause the processor to perform the method according to any one of claims 1 to 15.

17. A computer readable medium storing processor executable instructions comprising instructions which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 15.

Images