Method and system for distributing and validating alerts in a distributed computing system

Abstract

A system and a computer-implemented method for generating, propagating, and processing alert messages on a blockchain network. The alert messages are generated and sent by an alert management service and may instruct mining nodes to take specific actions, including freezing transaction outpoints, banning peer nodes, invalidating blocks, or conducting confiscation transactions to move assets from a transaction outpoint to another address. An alert handler within the node software in the mining node manages the parsing and processing of the alert. The alert may be sent in a P2P message that includes a serialized alert transaction that itself contains the alert message in an output field. The processed alert message causes the alert transaction to be included in the mempool and ultimately in the blockchain.

Description

Technical Field

[0001] The present disclosure relates to blockchain networks, and more particularly, to methods and devices for distributing and validating instructions in a distributed computing system such as a blockchain network.

Background Art

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

[0003] In an "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies an amount of digital assets derivable from a previous sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs") or "outpoints". In some cases, the protocol may refer to sender and receiver addresses rather than "outputs" or "outpoints". An output may further include a lock script that specifies the conditions for future redemption of the output. A lock script is a predicate that defines the conditions necessary to validate and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction and may further include an unlocking script for unlocking the lock script of the indicated output.

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

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

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

DETAILED DESCRIPTION OF THE INVENTION

[0007] In one aspect, the present application describes a computer-implemented method that may include, at a mining node within a blockchain network, identifying that a transaction is an alert transaction; extracting an alert message from an output field of the alert transaction; validating one or more signatures within the alert message using one or more alert administrator public keys; and processing an instruction within the alert message based on the validation of the one or more signatures, the processing including one of invalidating a block, banning a peer node, freezing a transaction outpoint, or validating and propagating a confiscation transaction.

[0008] In some implementations, the step of identifying that a transaction is an alert transaction is at least partially based on identifying an alert code within an output field.

[0009] In some implementations, an alert message includes an alert type field signaling one of a set of predefined alert types. The set of predefined alert types can include information alerts, peer ban alerts, peer unban alerts, freeze alerts, thaw alerts, block invalidation alerts, block reconsideration alerts, and seizure alerts.

[0010] In some implementations, an alert message is a signed serialized alert message, and the step of validating one or more signatures includes extracting one or more signatures from the signed serialized alert message leaving a null signature field, obtaining a modified serialized alert message, hashing the modified serialized alert message to obtain a hash result, and using the hash result and the corresponding one or more public keys associated with an alert management service to verify the one or more signatures.

[0011] In some implementations, the method can include receiving an alert P2P message via a blockchain network and extracting an alert transaction from the alert P2P message.

[0012] In some implementations, freezing a transaction output includes obtaining a transaction outpoint from an instruction within an alert message and recording the transaction output as frozen in an instruction database.

[0013] In some implementations, validating and propagating a seizure transaction includes extracting the seizure transaction from within an alert message and adding the seizure transaction to a whitelist in an instruction database, and validating the seizure transaction based on inclusion in the whitelist.

[0014] In another aspect, the present application describes a computer-implemented method that may include generating an alert message in an alert management service, the alert message including a null signature field; serializing and hashing the alert message to generate a hash result; signing the hash result using one or more private keys to generate one or more digital signatures; inserting the one or more digital signatures into the null signature field to generate a signed serialized alert message; inserting the signed serialized alert message into an output field of a blockchain transaction; and propagating the blockchain transaction on a blockchain network.

[0015] In some implementations, the blockchain transaction is an alert transaction, and the propagating step includes wrapping the alert transaction in an alert P2P message and sending the alert P2P message to a plurality of mining nodes on the blockchain network.

[0016] In some implementations, the blockchain transaction is an alert transaction, and the output field includes an alert code and a signed serialized alert message.

[0017] In some implementations, the alert message includes an alert type and an instruction. In some cases, the alert type is one of a set of predefined alert types, and the set of predefined alert types includes at least an information alert, a peer prohibition alert, a peer prohibition cancellation alert, a freezing alert, a thawing alert, a block invalidation alert, a block reconsideration alert, and a seizure alert.

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

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

[0020] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art by considering the following detailed description in conjunction with the drawings.

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

[0022] In this application, the expression "… or at least one of …" is intended to cover any one of the listed elements, any sub - combination, or all of the elements, without necessarily excluding any additional elements and without necessarily requiring all of the elements, and to encompass any one or more of the listed elements.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0039] Each computing device 102 of a plurality of parties 103 that assume the role of consuming users is also connected to the network 101. These users can interact with the blockchain network, but do not participate in transaction and block validation, construction, or propagation. Some of these users or agents 103 may act as senders and receivers of transactions. Other users can interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., obtained a copy of the blockchain from the blockchain node 104).

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

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

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

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

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

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

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

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

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

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

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

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

[0052] In the UTXO-based model, each transaction ("Tx") 152 is a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies the amount of digital assets. This represents the set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201 that may contain indicators showing the sizes of the input field(s) 202 and the output field(s) 203. The header 201 may also contain the ID of the transaction. In some embodiments, the transaction ID is the hash of the transaction data (excluding the transaction ID itself).

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

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

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

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

[0057] Therefore, in the illustrated example, the UTXO0 in the output 203 of Tx0 has a lock script [Checksig P A that requires Alice's signature Sig P A for the UTXO0 to be redeemed (strictly speaking, for the subsequent transaction attempting to redeem UTXO0 to be valid). [Checksig P A is the public key P of Alice's public-private key pairA includes the expression (i.e., hash) of . The input 202 of Tx1 includes a pointer indicating Tx0 (e.g., in some embodiments, its transaction ID, TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index for identifying UTXO0 within Tx0 to identify UTXO0 from among any other possible outputs of Tx0. The input 202 of Tx1 has an unlock script <Sig P A > with Alice's cryptographic signature created by Alice applying the secret key of the key pair to a predetermined portion of the data (which may also be referred to as the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

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

[0059] Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function executed by the lock script (in this example, a stack-based language). Equally, the scripts can be executed one after another using a common stack instead of concatenating the scripts. In any case, when executed together, the scripts result in Alice's public key P as included in the lock script within the output of Tx0 A ​Use to authenticate that the unlock script within the input of Tx1 contains Alice's signature that signs the expected part of the data. To perform this authentication, the expected part of the data itself (the "message") must also be included. In some embodiments, the data being signed includes the entirety of Tx1 (i.e., since a separate element specifying the signed part of the plaintext data already essentially exists, it need not be included).

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

[0061] If the unlock script within Tx1 meets one or more of the conditions specified within the lock script of Tx0 (i.e., in the illustrated example, if Alice's signature is provided and authenticated within Tx1), the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the ordered set of transactions 154. The blockchain node 104 also forwards the transaction Tx1 to one or more other blockchain nodes 104 within the network 106 so that the transaction Tx1 is propagated throughout the network 106. When Tx1 is verified for validity and included in the blockchain 150, this defines UTXO0 of Tx0 as spent. Note that Tx1 can only become valid if it uses an unspent transaction output 203. If an output already used by another transaction 152 is attempted to be used, Tx1 will be invalid even if all other conditions are met. Thus, the blockchain node 104 also needs to check whether the referenced UTXO within the preceding transaction Tx0 has already been spent (i.e., whether it has already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose the order defined in the transaction 152. In practice, a given blockchain node 104 may maintain a separate database marking which UTXO203 within which transaction 152 has been used, but ultimately, what defines whether a UTXO has been used is whether it has already formed a valid input to another valid transaction within the blockchain 150.

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

[0063] Note that in a UTXO-based transaction model, a given UTXO must be used in its entirety. It is not possible to "leave" a portion of the amount defined as used in the UTXO and use another portion. However, the amount from a UTXO can be split among multiple outputs of the next transaction. For example, the amount defined in UTXO0 within Tx0 can be split among multiple UTXOs within Tx1. Thus, if Alice does not want to give all of the amount defined in UTXO0 to Bob, Alice can use a remainder to give the rest to herself in the second output of Tx1 or pay another party.

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

[0065] The digital assets of Alice and Bob are composed of UTXOs locked to them in any transaction 152 somewhere within the blockchain 150. Thus, typically, the assets of a given party 103 are scattered throughout the UTXOs of various transactions 152 across the entire blockchain 150. Nowhere within the blockchain 150 is the number defining the total balance of a given party 103 stored. The role of the wallet function in the client application 105 is to collate together all the values of the various UTXOs locked to each party and not yet used in a subsequent transaction. This can be done by querying a copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

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

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

[0068] The lock script may sometimes be referred to as "scriptPubKey," typically referring to the fact that each transaction is locked with the public key of the party. The unlock script may sometimes be referred to as "scriptSig," typically referring to the fact that it supplies the corresponding signature. However, more generally, in all applications of the blockchain 150, it is not essential that the condition for redeeming the UTXO includes authenticating the signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

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

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

[0071] Client software FIG. 3A shows an exemplary implementation of a client application 105 for implementing an embodiment of the method of the present disclosure. The client application 105 can include a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the basic transaction - related functions of the client 105 to formulate, for example, a transaction 152, receive and / or transmit transactions and / or other data on the side channel 301, and / or transmit a transaction to one or more nodes 104 for propagation throughout the blockchain network 106, according to the processes described above.

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

[0073] Although the various functions of this specification may be described as integrated into the same client application 105, this is not necessarily limited thereto. Instead, it should be noted that they may be implemented, for example, in a set of two or more separate applications where one is a plugin to the other or interfaces via an API (Application Programming Interface). For example, the functions of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functions of a given module such as the transaction engine 401 may be split between two or more applications. Nor is it excluded that some or all of the functions described may be implemented, for example, in the operating system layer. When referring herein to a single or given application 105, etc., this is merely an example, and more generally, it will be understood that the functions described may be implemented in any form of software.

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

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

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

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

[0078] 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 can be rendered on the screen or audibly.

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

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

[0081] Thus, the script engine 452 has the lock script of Tx i and the unlock script from the corresponding input of Tx j For example, FIG. 2 shows transactions labeled Tx0 and Tx1, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together, which includes placing data on the stack 453 and retrieving data therefrom according to the stack-based scripting language (e.g., Script) being used.

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

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

[0084] The terms "true" and "false" as used herein are not necessarily limited to returning results in the form of only a single binary digit (bit), although it should be noted that this is certainly one possible implementation. More generally, "true" can refer to any state indicating a successful or positive result, and "false" can refer to any state indicating an unsuccessful or non - positive result. For example, in an account - based model, a "true" result can be indicated by a combination of an implicit protocol - level validity check of 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).

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

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

[0087] In some embodiments of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing the 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 of these functions and not all. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered nodes of the preferred Bitcoin network 106).

[0088] 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 a node may perform at least one or some of the functions of creating, publishing, propagating, and storing the blocks 151 of the blockchain 150 and not all. For example, on those other blockchain networks, the term "node" may be used to refer to a network entity that is configured to create and publish the blocks 151 but not store and / or propagate those blocks 151 to other nodes.

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

[0090] Generation and processing of alerts One reason for the 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 the owners of digital assets to directly control the digital assets and the movement of digital assets to another wallet. However, this also poses challenges to existing regulatory or legal frameworks. Without a mechanism to seize, control, or otherwise enforce transfers, it can be difficult or impossible to apply court orders to digital assets, even when attempting to address demonstrable fraud or theft.

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

[0092] Attempts to address real-world theft, bankruptcy, and fraud that affect blockchain-based digital assets can lead to a situation where a court or other legal or government agency issues orders to blockchain organizations, blockchain miners, or individual blockchain code programmers. Those orders can instruct the recipient to freeze or block further transactions in identifiable digital assets and / or to hold or escrow those assets. Some blockchain software may lack the ability to implement those actions, and implementation may require changes to the software that runs the nodes of the blockchain network. Since some nodes may adopt the updated software and some may not, this can cause a fork in the chain.

[0093] One possible option for managing orders of this nature or for dealing with fraud within the blockchain network is to instruct mining nodes to execute specific orders. This instruction may be sent outside of the blockchain network. The drawback of this approach is that it undermines the record and integrity of the blockchain.

[0094] This application provides a method and system for implementing instructions such as freezing, banning, invalidating, or seizure orders within a blockchain network using P2P messaging. An alert management service may be tasked with reviewing and issuing alerts that direct mining nodes to execute specific instructions or orders. Advantageously, as described below, this service may encapsulate an alert message within an alert transaction that is processed using the normal transaction validation operation, such that the alert message is added to the mempool and ultimately incorporated into the blockchain. This ensures that alerts are recorded on the chain during the normal course of operation. It also leverages existing transaction validation and mempool operations. An alert handler within a mining node manages the validation of an alert message extracted from an alert transaction, including the signature applied by the alert management service.

[0095] In some exemplary implementations, the instructions within the alert message may include instructions to freeze or unfreeze a specific UTXO, instructions to seize a specific UTXO by a seizure transaction that transfers the assets associated with that UTXO to another UTXO, instructions to ban or unban a peer node, instructions to invalidate or reconsider a block, or simply informational content.

[0096] First, refer to FIG. 5, which shows a simplified diagram of an exemplary system 550 for generating and propagating instructions to mining nodes within a blockchain system. System 550 may include an alert management service 552. The alert management service 552 may be implemented using one or more computing devices. In some cases, the alert management service 552 is a web service. One or more user devices 580 may be connected to the alert management service 552 using, for example, a web browser or a dedicated application, to instruct or cause the alert management service 552 to generate and propagate instructions intended to cause the mining nodes to take specific actions. The user devices 580 provide user credentials that are authenticated by the alert management service 552. In some implementations, different levels of permission may be assigned to different user types.

[0097] The alert management service 552 is configured to communicate with mining nodes 556 that collectively form a blockchain network 554. Each mining node 556 is typically implemented using a dedicated special-purpose computing device designed for blockchain mining operations. In some cases, one or more of the mining nodes 556 may be a mining pool that may include several mining node instances.

[0098] Each mining node 556 may store and maintain a copy of the blockchain 562. When a new block is verified (i.e., validated) by the mining node 556, the mining node 556 adds the new block to its copy of the blockchain 562. If a mining node 556 goes offline for a period of time or is newly instantiated and added to the blockchain network 554, it may perform an initial blockchain download (IBD) or request a copy of the latest block missing from the chain to complete a picture of the current state of the blockchain 562. Each mining node 556 may further maintain a mempool 560 of data structures stored in memory, such as a database, that includes unconfirmed blockchain transactions.

[0099] Each mining node 556 implements at least one mining node instance based on mining node software 558 stored in memory and executed by one or more processors. The mining node software 558 may include a portion configured to implement an alert handler 564, which enables the mining node 556 to identify, validate, and act on alert messages sent by the alert management service 552.

[0100] Broadly speaking, the alert management service 552 receives an authenticated instruction from one of the user devices 580 to issue an alert message. The alert message may include an alert type. Different alert types may include, for example, information, an instruction to freeze / unfreeze a UTXO, an instruction to ban / unban a peer node, an instruction to invalidate or reconsider a block, and / or an instruction to confiscate assets by a confiscation transaction that moves assets from one UTXO to another.

[0101] The alert management service 552 may, in some cases, require that certain instructions, such as freeze or seizure instructions, be based on a verified court identifier or other credentials indicating that those instructions implement actions authorized by a legal authority. In some cases, the alert management service 552 may convert a court order received from one of the user devices 580 into a machine-readable representation of the court order. In some implementations, one or more digital signatures from an entity authorized to sign the court order may be verified by the alert management service 552. The court order may specify one or more digital assets. The digital asset identifier may precisely identify a specific address, such as a wallet address, that is frozen or seized as a result of the court order. In some cases, the court order may also or alternatively identify the digital asset by a transaction output point, such as a UTXO, although in many cases the court order may identify the funds by association with a wallet address or other public key representation.

[0102] The alert 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 output points. It will be understood that a single address may be associated with multiple digital assets, which (in the case of some blockchains) may be identified by the transaction output points that allocate the assets to that single address. For example, a single public key hash address may be the recipient address of many transactions that allocate digital assets such as cryptocurrencies or NFTs to that address. Each output point within a transaction that sends a digital asset to that address may be identified by the address indexer 553. The address indexer 553 or related services may be further configured to engage in tracking operations for child discovery, i.e., tracking assets that have moved from an identified address to one or more other addresses and the related output points from the transactions that executed those moves. In some implementations, the address indexer 553 is implemented as part of a general blockchain indexer configured to obtain new block data, index transactions that link spent transaction output points to transaction inputs, and enable tracking of digital assets through transactions. The blockchain indexer may connect to one or more blockchain nodes, listen for new blocks, and retrieve block data.

[0103] The alert management service 552 may store key data 578 that includes its own public key(s) and securely stored secret key(s). In some cases, the key data 578 may include public key data associated with a registered or authenticated mining node 556. In some cases, this may include a minerID registered on the chain and associated with a particular miner. In some cases, the key data 578 may include coinbase public key data. In some cases, the key data 578 may include delegated key data linked to the minerID or coinbase public key data. In some cases, the key data 578 may include multiple secret keys and may be used to sign alert messages. In some implementations, alert messages may be signed using multiple signatures. In some implementations, a threshold signature scheme that requires N out of M signatures may be used. The keys involved may change over time using a defined key rotation scheme.

[0104] Please refer to FIG. 6, which shows an example of node software 600 for operating a node of a blockchain network that can receive and process alert messages from an alert management service in block diagram form. Node software 600 is shown as conceptual operational or functional blocks that may be implemented as separate modules or applications, or in combination with or partially combined with each other in one or more modules or applications. The executable code implementing node software 600 may be implemented using any programming language suitable for the processing hardware and operating system on which it is executed. Node software 600 is generally stored in the memory within a blockchain node and executed by one or more processors or processing units. The blockchain node may be a mining node.

[0105] The node software 600 includes modules or components (not shown) for performing the functions of a blockchain node according to applicable blockchain protocols, such as normal transaction validation and propagation operations and / or mining operations. In this example, the node software 600 includes an alert handler 602 and several sub-handlers that can be called by the alert handler 602 to process specific alerts. The sub-handlers in this example include an information handler 604, an invalidation / reconsideration handler 606, a freeze / thaw handler 608, a seizure handler 610, and a prohibit / unprohibit handler 612. This example and the following description treat the sub-handlers as components separate from the alert handler 602, but in some implementations, some or all of the functionality of the sub-handlers may be implemented within the alert handler 602.

[0106] The alert handler 602 is configured to perform initial processing of new alerts. New alerts are typically received by the blockchain node via alert P2P messages through the P2P messaging interface 614. However, in some cases, alerts may be discovered within newly mined blocks, or within existing blocks on the chain that the node receives and validates to build an image of the blockchain state, such as during an initial block download (IBD), in the case of a newly joined blockchain node or a blockchain node returning to the network after a disconnection period. The node software 600 may include a block validation component 626 configured to obtain block data from peer nodes during the IBD process and may pass alert transactions to the alert handler 602.

[0107] As further described below, the alert message is embedded within an alert transaction. In the case of an alert P2P message, the alert transaction itself may be enveloped within the format of the alert P2P message, although in some implementations, the alert transaction may be received as a normal P2P transaction over the P2P network. The alert transaction includes the alert message within an output field. Optionally, the output field may include an alert code or other identifier to indicate that the remainder of the output field's content is typically an alert message in serialized form. The alert message itself may optionally be a JSON-formatted string.

[0108] In some implementations, each alert message may include a sequence number to enable nodes to determine the ordering of alerts and, optionally, to identify duplicate alert messages. Each alert message may further include an alert type that signals the type of instruction provided within the alert message from the alert management service and may include a message payload or field that provides the instruction. The content of the message payload or field may vary depending on the alert type. For example, an informational alert may permit an unstructured message field that allows for the inclusion of any ASCII string content. A freeze / thaw instruction may require that the message field include a reference to one or more transaction outpoints. The alert message also includes a signature field that includes one or more digital signatures from the alert management service to enable nodes to verify the validity of the alert message.

[0109] The alert handler 602 is configured to verify the validity of the alert message, confirm that the alert message has not been previously processed by the node, and if not processed, pass the alert to an appropriate sub - handler for processing. When an alert is processed by the node, the alert handler 602 is configured to add the alert transaction to its mempool 620. In this way, when the node mines the next block, the alert transaction is included in the block as a digital record of the fact that it has been verified and processed by the node. If another node mines the next block and it contains the alert transaction, the node can verify the block and remove the alert transaction from its mempool 620.

[0110] The alert handler 602 may propagate the validated alert P2P message to other nodes via the P2P network. In some cases, the alert handler 602 propagates the alert P2P message only after the processing of the alert instruction is complete, but in some other cases, the processing may be asynchronous, and the node software 600 may be configured to propagate the alert P2P message before the processing is complete and before the alert transaction is added to its mempool 620.

[0111] In some cases, if the alert transaction is not encapsulated within the alert P2P message, the node software 600 may be configured to propagate the alert transaction in the normal transaction propagation process when the alert transaction is verified.

[0112] The alert handler 602 maintains an alert database 622. The alert database 622 is a record of all received alert messages. This can be used to record both the alert content and the processing status of the alerts at the node. In some cases, it may have a format as follows:

Table 1

[0113] An example of a warning message could be that the alert instructed the node to freeze a UTXO that was already frozen. An example of an error message could be that the alert instructed the node to freeze a UTXO that appeared to not exist.

[0114] In another example, instead of a boolean flag, a 2-bit field could be used to signal whether an alert has been processed or not, or whether an error has been generated. A single message field could be defined to include any warning or error message.

[0115] The information handler 604 can be configured to extract and log any information string provided in an alert message of the information type. The information handler 604 can, in some cases, be configured to perform some notification or messaging function based on the information. In some cases, the information handler 604 may only need to log the information in the memory of the node.

[0116] The invalidation / reconsideration handler 606 is configured to process an instruction to invalidate a block or, if the block has been previously invalidated, to "reconsider" the block, e.g., to process an instruction to re-validate it. In response to an invalidation instruction in an alert message, the invalidation / reconsideration handler 606 can cause the invalidation and / or deletion of blocks on the blockchain maintained at the node. In most use cases, this could be the most recent block, but in some cases, the invalidation instruction may specify an older block, in which case that block and all subsequent blocks on its chain would be invalidated.

[0117] The freeze / thaw handler 608 is configured to process transaction outpoints, such as an instruction to freeze a UTXO, or an instruction to thaw a previously frozen transaction outpoint. The freeze / thaw handler 608 may maintain an instruction database 624 that tracks the frozen / thawed transaction outpoints.

[0118] The confiscation handler 610 is configured to process confiscation instructions. The confiscation instructions within the confiscation alert provide a confiscation transaction that moves digital assets from one or more specified transaction outpoints to one or more different transaction outpoints. The confiscation instructions may be used to force the transfer of digital assets to effect a seizure, such as for the enforcement of a court order. The confiscation handler 610 may be configured to white-list the confiscation transaction in the instruction database 624, signaling that it should be treated as a valid transaction. In some cases, the confiscation handler 610 may require that any input to the confiscation transaction be a previously frozen UTXO already recorded in the instruction database 624. The confiscation handler 610 may submit the confiscation transaction to the transaction validity verification process within the node software 600, and it can be added to the mempool 620.

[0119] Now, refer to FIG. 7 which shows in flowchart form one exemplary method 700 for generating and propagating alert messages. Method 700 can be implemented using a network-connected computing device. In some cases, the computing device may be a server or a group of servers that operate an online service such as the alert management service 552 (FIG. 5). The operations of method 700 can be executed by a computing device based on processor-executable software instructions stored in memory on the computing device. The computing device can be connected to one or more networks such as the Internet. The computing device may or may not be directly connected to the blockchain network as a node of the blockchain network. In many implementations, the computing device does not operate blockchain protocol software and does not form 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 nodes such as mining nodes on the blockchain network. The computing device can be configured to communicate with one or more modes using a P2P communication protocol.

[0120] In operation 702, the alert management service generates an alert message. As described above, the alert message can have a defined structure and can include a sequence number, an alert type, an instruction, and one or more digital signatures. An example of an alert message structure is shown below:

Number

[0121] The version field may signal the version of the adopted alert messaging protocol if there are two or more versions. The sequenceNumber field may function as a unique ID for the alert and as a sequence number to enable the node to know in which order to process the received alert messages. The blockHeight field may signal the block height at which the alert was generated. The timestamp field includes the time at which the alert was generated, for example in ISO-8601 format. The reference field may store an optional reference for the alert. The alertType field may signal which type of alert is included in the alert object field. The alert handler may route the alert for processing based on its alertType. The alert object field contains the details of the alert. This may include instructions and the format and content may vary depending on the alertType. The signature object contains the signature generated and inserted by the alert management service.

[0122] In some cases, the alert types may include "information", "invalidate_block", "reconsider_block", "ban_peer", "unban_peer", "freeze_order", "unfreeze_order", and "confiscate". The content of these various types of alert objects may vary. An Information type alert may simply include a string for the receiving node to log. The invalidate_block alert type and the reconsider_block alert type may have a string specifying the hash of the block to invalidate or reconsider. The ban_peer alert type or the unban_peer alert type may specify the IP address or subnet to ban or unban.

[0123] The freeze_order alert type and the unfreeze_order alert type may specify a transaction outpoint or a list of transaction outpoints to be frozen. This can take the following form:

Number

[0124] The confiscate type may include a string that is a confiscation transaction designed to move assets from one or more transaction outpoints to one or more other addresses. In some cases, it may include two or more confiscation transactions. Each confiscation transaction can be inserted as a transaction encoded in a hexadecimal string. The confiscation handler decrypts the transaction in the instruction database, puts it on the whitelist, and submits the transaction for validity checking and inclusion in the mempool.

[0125] The alert handler generates one or more digital signatures as indicated by the signature field and includes them in the alert message. In some cases, the signature scheme can be a multisig signature scheme where N out of M signatures, for example 3 out of 5 signatures, are included and are valid. In some cases, threshold signatures can be used.

[0126] Each signature should be on top of the content of the alert message. However, there is a problem with creating and validating the signature because the signature field is empty at the time of signing while it is filled at the time of validity checking. Therefore, this application provides that a valid signature in this example is based on an alert message with a null signature field. To simplify validity checking at the node, the alert message is serialized without whitespace before being signed.

[0127] As shown by operation 704, the alert management service serializes an alert message with a null signature field. This creates a string without extra formatting or whitespace. The serialized alert message is then hashed in operation 706, and the resulting hash is signed in operation 708 using a private key held by the alert management service. If multiple signatures are generated, the signing can be repeated using different private keys.

[0128] Once the digital signature is generated, in operation 710, the digital signature is inserted into the signature object within the serialized alert message, creating a signed serialized alert message. The signed serialized alert message is then inserted into the output field of the alert transaction. In a particular example, the signed serialized alert message is inserted into the OP_RETURN field of the alert transaction. In some implementations, in addition to including the signed serialized alert message, the OP_RETURN field may include an alert code signaling that the transaction is an alert transaction. An exemplary alert transaction with an OP_RETURN output script at index 0 is as follows: [Table 2]

[0129] In the above exemplary example, the code 0x616C7274 signals that it is an alert transaction. This is a 4-byte alert prefix that is represented as "alrt" in ASCII. Any other code can be used. The alert JSON then follows.

[0130] In some examples, the alert transactions generated in this way can be propagated on the blockchain P2P network in the same way as normal transactions. For example, on the Bitcoin network, alert transactions can be propagated using the tx P2P message, which may appear to peer nodes as a normal transaction message. However, in this example, the alert management service encapsulates or wraps the alert transaction within an alert P2P message. This can have the advantage that P2P messages are not ignored by nodes and network elements that do not normally process transactions. For example, some nodes may be configured to ignore or be excluded from tx P2P messaging, but they can be configured to receive and accept alert P2P messages. Operation 714 includes wrapping the alert transaction in an alert P2P message. The structure of the alert P2P message can, in one example, be as follows:

Table 3

[0131] In operation 716, the alert management service sends the alert P2P message to one or more peer nodes on the P2P network, and in this particular example, to one or more mining nodes on the blockchain network.

[0132] Now, refer to FIG. 8 which shows in flowchart form one exemplary method 800 for processing alert messages. Method 800 may be implemented using a network-connected computing device, particularly a mining node that is part of a blockchain network. In some cases, the mining node may be a server or a group of servers such as mining node 556 (FIG. 5). The operations of method 800 may be performed by the mining node based on processor-executable software instructions stored in memory on the computing device. In some cases, the operations are performed by node software 600 (FIG. 6), and in some cases, by alert handler 602 (FIG. 6) and / or its sub-handlers.

[0133] In operation 802, the node receives an alert P2P message. In this example, the alert message is embedded in an alert transaction communicated within the alert P2P message. In another example, the alert transaction may be communicated directly within a transaction P2P message rather than being wrapped in an alert P2P message. In another scenario, the alert transaction may be identified within a validated block either during block validation after another miner has found a proof of work or during the IBD process.

[0134] In operation 804, alert transactions are extracted and verified. Optionally, this may be performed by the P2P messaging interface. This may extract the alert transaction and call a normal transaction verification process such as ProcessTxMessage() as in the case of a newly received tx P2P message. Thus, the node verifies that the alert transaction meets the protocol requirements and is a valid transaction. This may include determining whether the alert transaction has already appeared in the node's mempool. If the alert transaction is already in the mempool, it indicates that the node has already received the alert transaction, verified it, and processed the alert message within the alert transaction. In this case, method 800 may end and duplicate alert transactions may be discarded.

[0135] The signed serialized alert message may be extracted from the alert transaction in operation 806. This may then be verified in operation 808 by the alert handler, which may include verifying one or more digital signatures within the signed serialized alert message using one or more public keys associated with the alert management service.

[0136] Signature verification may be based on first extracting the digital signature from the signature field of the signed serialized alert message. That is, the alert handler ensures that the modified alert message contains a null signature field. Next, the modified serialized alert message is hashed to obtain a hash result. Based on the hash result and one or more public keys of the alert management service, the alert handler can verify the validity of the digital signature. The alert handler may be configured to determine which key was used at the time of signing the alert message, for example based on a timestamp.

[0137] In operation 810, the node determines whether the alert message is already in the alert database. This may involve searching the alert database based on the sequence number. If the sequence number is found in the alert database, the node may, in operation 812, determine whether it is associated with the same alert message. If not, an error has occurred as two or more alerts are claimed to have the same sequence number, and in operation 814, the process is aborted and the error may be logged.

[0138] If the alert is the same as the one already logged in the alert database, the node has simply received another copy of it. In this case, the node, in operation 816, determines whether the processing of the previously recorded alert message has been completed. In this situation, depending on the result from the sub - handler, the status may indicate PROCESSED or ERROR. If the previously recorded alert message has not yet been processed, the status indicates UNPROCESSED. The alert may be unprocessed because asynchronous alert processing has not yet been completed, or the processing was interrupted and not completed, or due to an error when updating the alert database. In any case, if the processing is not complete, the method continues. However, if the processing is complete, since this alert message has already been processed, in operation 818, the processing is aborted.

[0139] In operation 810, if it is determined that the alert message is not yet in the database, in operation 811, the alert message is recorded in the alert database and an UNPROCESSED status is assigned.

[0140] In operation 820, the alert handler calls an appropriate sub - handler for processing the instructions in the alert message based on the alert type. If the sub - handler is already attempting to process the alert message, this may result in re - sending the same alert message to the sub - handler. Note that the sub - handler is configured to handle duplicate requests cleanly.

[0141] The processing of the alert continues in operation 822 until the sub - handler returns a result, which may include a message confirming that the alert was processed successfully or an error message. If the alert message is processed successfully, the alert handler, in operation 824, confirms that the alert transaction has been added to the local memory pool. It may update the alert database to change the alert status to PROCESSED. Optionally, in some cases, it may also record any additional data returned by the alert sub - handler, such as any warning message or error message. Optionally, in some cases, the alert handler may notify the P2P interface layer that the alert transaction or alert P2P message should be delivered to other peer nodes.

[0142] In some implementations, it will be understood that method 800 may be modified to execute one or more operations in parallel or to change the order in which some of the operations are executed, without necessarily affecting the overall operation of method 800. In the above process, alert message processing may be performed asynchronously so as not to interfere with or block further transaction validation. Alert transaction validation may be completed before the alert message is processed by the subhandler. Since the alert transaction is partially added to the mempool to signal that the alert has been successfully processed by the node, the alert transaction is not necessarily added to the mempool upon completion of the transaction validation process as occurs with normal transactions. When the status of the alert message becomes PROCESSED, the alert handler may add the alert transaction to the mempool. If the alert transaction is added to the mempool, the node may not need to announce it (INV) to other peers.

[0143] The processing of alerts found within a block during block validity verification can be a similar but slightly more complex process based on the possibility of having two or more alerts within the block. In some cases, alerts can cancel each other out, such as when there is an alert message imposing a freeze order on a TXOUT and then a subsequent alert message implementing a thaw order on the same TXOUT. Thus, during block validity verification, when alert transactions are identified, they can be added to a running list of potential new alerts. Alert transactions can undergo transaction validity verification just like normal transactions. Once block validity verification completes successfully, the alert handler can process the alerts in the order they appear in the block, as if the alerts were received via the P2P interface in that order. Even if alert transactions are verified and processed, they are not added to the mempool because they are already within the block. If alert processing returns an error from the alert handler, the block can be rejected as invalid since only the alerts that were processed successfully should appear in a valid block. Any alert found within a block for which the node does not yet have an entry in its alert database is treated as a new alert message and processed accordingly.

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

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

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

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

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

[0149] The responsibility for identifying child transaction outpoints can lie with the alert management service in these examples. This has the advantages that mining nodes can run unindexed or pruned nodes, they do not require an address indexer or child discovery tracking capabilities, and the list of outpoints in the digitally signed alert message by the alert management service is static and common to all miners, thereby avoiding the risk of inconsistent freezes and chain forks. The drawback is that assets can be moved from the identified outpoints between the generation and distribution of the alert message to miners and its implementation, thus avoiding the freeze. If additional child outpoints are included in the alert message after the first alert message has been distributed, the alert management service can generate and send a second or subsequent alert message.

[0150] The various embodiments presented above are merely examples and in no way are intended to limit the scope of this application. Modifications of the innovations described herein will be apparent to those skilled in the art, and such modifications are within the intended scope of this application. In particular, it is possible to create alternative exemplary embodiments that include a sub - combination of features selected from one or more of the above - mentioned exemplary embodiments and that may not be explicitly described above. Additionally, it is possible to select and combine features from one or more of the above - mentioned exemplary embodiments to create alternative exemplary embodiments that include combinations of features that may not be explicitly described above. Features suitable for such combinations and sub - combinations will readily become apparent to those skilled in the art upon consideration of the application as a whole. The subject matter described in this specification and the claims is intended to cover and embrace all suitable changes in the art.

Claims

1. A computer-implemented method, comprising: at a mining node in a blockchain network, identifying that a transaction is an alert transaction; extracting an alert message from an output field of the alert transaction; validating one or more signatures in the alert message using one or more alert administrator public keys; processing an instruction in the alert message based on the validation of the one or more signatures, the processing including one of invalidating a block, banning a peer node, freezing a transaction outpoint, or validating and propagating a seizure transaction; and a method including the above steps.

2. The method according to claim 1, wherein the step of identifying that a transaction is an alert transaction is at least partially based on identifying an alert code in the output field.

3. The method according to claim 1, wherein the alert message includes an alert type field signaling one of a set of predefined alert types.

4. The method according to claim 3, wherein the set of predefined alert types includes at least an information alert, a peer ban alert, a peer unban alert, a freeze alert, a thaw alert, a block invalidation alert, a block reconsideration alert, and a seizure alert.

5. The method according to claim 1, wherein the alert message is a signed serialized alert message, and the step of validating the one or more signatures includes extracting the one or more signatures from the signed serialized alert message leaving a null signature field, obtaining a modified serialized alert message, hashing the modified serialized alert message to obtain a hash result, and validating the one or more signatures using the hash result and corresponding one or more public keys associated with an alert management service.

6. The method according to claim 1, further comprising the step of receiving an alert P2P message via the blockchain network and the step of extracting the alert transaction from the alert P2P message.

7. Freezing the transaction output includes obtaining a transaction outpoint from the instruction in the alert message and recording the transaction output as frozen in an instruction database. The method according to claim 1.

8. Validating and propagating the confiscation transaction includes extracting the confiscation transaction from the alert message and adding the confiscation transaction to a whitelist in an instruction database. Validating and propagating the confiscation transaction includes validating based on inclusion in the whitelist. The method according to claim 1.

9. A computer-implemented method, The step of generating an alert message in an alert management service, wherein the alert message includes a null signature field, Serializing and hashing the alert message to generate a hash result, Signing the hash result using one or more private keys to generate one or more digital signatures, Inserting the one or more digital signatures into the null signature field to generate a signed serialized alert message, Inserting the signed serialized alert message into an output field of a blockchain transaction, Propagating the blockchain transaction on a blockchain network A method comprising.

10. The blockchain transaction is an alert transaction, and the step of propagating includes wrapping the alert transaction in an alert P2P message and sending the alert P2P message to a plurality of mining nodes on the blockchain network. The method according to claim 9.

11. The blockchain transaction is an alert transaction, and the output field includes an alert code and the signed serialized alert message, the method according to claim 9. **Claim 12** The alert message includes an alert type and instructions, the method according to claim 9. **Claim 13** The alert type is one of a set of predefined alert types, and the set of predefined alert types includes at least an information alert, a peer prohibition alert, a peer prohibition cancellation alert, a freezing alert, a thawing alert, a block invalidation alert, a block reconsideration alert, and a confiscation alert, the method according to claim 12. **Claim 14** A computing device, One or more processors, A memory, Computer-executable instructions stored in the memory And when the computer-executable instructions are executed by the one or more processors, cause the processor to execute the method according to any one of claims 1 to 13, A computing device. **Claim 15** A computer-readable medium storing processor-executable instructions, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to execute the method according to any one of claims 1 to 13, a computer-readable medium.

Images