Method and system for distributing and validating alarms in distributed computing system

Abstract

Systems and computer-implemented methods for generating, propagating, and processing alert messages over a blockchain network. Alarm messages may be generated and sent by an alarm management service to instruct a mining node to take certain actions including freezing a transaction exit point, inhibiting peer nodes, invalidating a block, or implementing no transaction to move an asset from the transaction exit point to another address. An alarm processor within node software at the mining node manages the parsing and processing of the alarm. The alert may be sent in a P2P message that includes a serialized alert transaction that itself includes an alert message in an output field. The processed alert message causes an alert transaction to be included in a memory pool, and ultimately in a blockchain.

Description

Technical Field

[0001] The present disclosure relates to blockchain networks, and in particular to methods and apparatus for distributing and validating commands in a distributed computing system such as a blockchain network. Background Art

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

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

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

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

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

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

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

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

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

[0011] Figure 5 An example system for generating, disseminating, and processing alert messages is shown;

[0012] Figure 6 An example implementation of node software configured to process alert messages is shown in block diagram form;

[0013] Figure 7 A simplified example method for implementing generating and sending an alert message is shown in flowchart form; and

[0014] Figure 8 A simplified example method of receiving and processing an alert message is shown in flowchart form;

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

[0016] In one aspect, the present application describes a computer-implemented method that may include: identifying a transaction as an alert transaction at a mining node in a blockchain network; extracting an alert message from an output field of the alert transaction; confirming one or more signatures within the alert message using one or more alert manager public keys; and processing instructions within the alert message based on the one or more signatures being confirmed, wherein the processing includes one of the following: invalidating a block, banning a peer node, freezing a transaction exit point, or confirming and propagating a confiscation transaction.

[0017] In some implementations, identifying the transaction as an alert transaction is based at least in part on an alert code in an identification output field.

[0018] In some implementations, the alert message includes an alert type field indicating one of a set of predefined alert types. The set of predefined alert types may include informational alert, inhibit peer alert, uninhibit peer alert, freeze alert, unfreeze alert, invalidate block alert, reconsider block alert, and forfeit alert.

[0019] In some implementations, the alert message is a signed serialized alert message, and wherein verifying the one or more signatures includes extracting the one or more signatures from the signed serialized alert message, leaving an empty signature field to produce a modified serialized alert message, hashing the modified serialized alert message to obtain a hash result, and verifying the one or more signatures using the hash result and corresponding one or more public keys associated with the alert management service.

[0020] In some implementations, the method may include receiving an alert P2P message over a blockchain network and extracting an alert transaction from the alert P2P message.

[0021] In some implementations, freezing the transaction output includes obtaining the transaction exit point from the instructions in the alert message and recording the transaction output as frozen in a command database.

[0022] In some implementations, validating and propagating the forfeited transaction includes extracting the forfeited transaction from within the alert message and whitelisting the forfeited transaction within a command database, and wherein validating and propagating the forfeited transaction includes validating based on inclusion of the forfeited transaction in the whitelist.

[0023] In another aspect, the present application describes a computer-implemented method that may include: generating an alert message at an alert management service, the alert message including an empty 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 empty signature field to produce 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.

[0024] In some implementations, the blockchain transaction is an alert transaction, and wherein propagating includes wrapping the alert transaction in an alert P2P message and transmitting the alert P2P message to the plurality of mining nodes on the blockchain network.

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

[0026] 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 wherein the set of predefined alert types includes at least an information alert, an inhibit peer alert, an uninhibit peer alert, a freeze alert, a thaw alert, an invalidate block alert, a reconsider block alert, and a forfeiture alert.

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

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

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

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

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

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

[0033] Example System Overview

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

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

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

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

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

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

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

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

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

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

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

[0045] Note that different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the ordered set 154 of transactions yet to be published at any given time, depending on when they began searching for a solution or the order in which the transactions were received. Whoever solves their respective puzzle first defines which transactions 152 are included in the next new block 151n and in what order, and the current set 154 of unpublished transactions is updated. The blockchain nodes 104 then continue to compete to create blocks based on the newly defined unfinished ordered set 154 of unpublished transactions, and so on. There is also a protocol for resolving any "forks" that may occur, where two blockchain nodes 104 solve their puzzles within a very short time of each other, causing conflicting views of the blockchain to propagate between the nodes 104. In short, whichever branch of the fork grows the longest becomes the final blockchain 150. Note that this should not affect users or agents of the network, as the same transaction will appear in both forks.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] Different blockchain nodes 104 may first receive different instances of a given transaction and therefore may have conflicting views about which instance is “valid” until one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance that it had originally accepted (i.e., the instance that has not yet been published in block 151).

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

[0061] UTXO-based model

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

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

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

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

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

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

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

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

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

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

[0072] The details of authentication by public-private cryptography are familiar to those skilled in the art. Basically, if Alice has signed a message using her private key, then given Alice's public key and the plaintext message, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and marking it as a signature onto the message, so that any holder of the public key can authenticate the signature. Therefore, please note that in embodiments, any reference herein to signing a portion of a particular data segment or transaction, etc., may mean signing a hash of that portion of the data segment or transaction.

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

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

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

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

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

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

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

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

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

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

[0083] Client Software

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

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

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

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

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

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

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

[0091] Alternatively or additionally, the UI element may include one or more information elements 503 that are output to output information to the user. For example, the information may be presented on a screen or in an audible manner.

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

[0093] Node software

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

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

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

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

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

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

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

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

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

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

[0104] Alert generation and processing

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

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

[0107] Attempts to respond to real-world theft, bankruptcy, and fraud affecting blockchain-based digital assets may result in courts or other legal or governmental entities issuing orders to blockchain organizations, blockchain miners, or individual blockchain code programmers. These orders may instruct the recipient to freeze or prevent further transactions in identifiable digital assets and / or to place such assets into custody or escrow. Some blockchain software may lack the ability to implement these measures, making implementation require changes to the software of the nodes operating the blockchain network. This may result in chain forks, as some nodes may adopt the updated software and some may not.

[0108] One possible option for managing commands of this nature or dealing with fraud within a blockchain network is to instruct mining nodes to execute certain commands. Instructions can be sent to the blockchain network from the outside. The downside of this approach is that it compromises the records and integrity of the blockchain.

[0109] The present application provides methods and systems for implementing commands (e.g., freeze commands, prohibition commands, invalidation commands, or confiscation commands) within a blockchain network using P2P messaging. An alarm management service may be responsible for reviewing and issuing alarms, instructing mining nodes to execute specific instructions or commands. As described below, advantageously, the service may encapsulate alarm messages in alarm transactions, which themselves may be processed using normal transaction confirmation operations so that they are added to the memory pool and ultimately incorporated into the blockchain. This ensures that alarms are recorded on-chain during normal operation. Existing transaction confirmation and memory pool operations are also utilized. The alarm processor within the mining node manages the confirmation of alarm messages (including the signature of the alarm management service application) extracted from the alarm transaction.

[0110] In some example implementations, the instructions in the alert message may include: instructions to freeze or unfreeze a particular UTXO; instructions to confiscate certain UTXOs via a confiscation transaction that transfers assets associated with the UTXO to another UTXO; instructions to ban a peer node or unban a peer node; instructions to invalidate a block or reconsider a block; or simply informational content.

[0111] First reference Figure 5 , which shows a simplified illustration of an example system 550 for generating instructions and propagating instructions to mining nodes in 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 network service. One or more user devices 580 may connect to the alert management service 552, for example, using a web browser or a dedicated application, in order to instruct or cause the alert management service 55 to generate and propagate instructions intended to cause mining nodes to take specific actions. The user device 580 provides user credentials authenticated by the alert management service 552. In some implementations, different levels of permissions may be assigned to different user types.

[0112] 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 computing device designed specifically for blockchain mining operations. In some cases, one or more of the mining nodes 556 may be a mining pool, which may include multiple mining node instances.

[0113] Each mining node 556 may store and maintain a copy of the blockchain 562. When a new block is confirmed (i.e., validated) by a mining node 556, the mining node 556 adds the new block to its copy of the blockchain 562. If a mining node 556 has been 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 may request a copy of the latest block missing from its chain to complete its picture of the current state of the blockchain 562. Each mining node 556 may also maintain a memory pool 560, which is a data structure, such as a database, stored in memory and containing unconfirmed blockchain transactions.

[0114] The mining nodes 556 each implement 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 alarm processor 564, which enables the mining node 556 to identify, verify, and take action based on alarm messages sent by the alarm management service 552.

[0115] In general, 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. For example, different alert types may include information, instructions to freeze / thaw a UTXO, instructions to ban / unban a peer node, instructions to invalidate or reconsider a block, and / or instructions to confiscate an asset via a confiscation transaction that moves an asset from a UTXO to another UTXO.

[0116] In some cases, the alert management service 552 may require that certain instructions (e.g., freezing orders or forfeiture orders) be based on a verified court identifier or other credentials indicating that the order implements an action 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, the alert management service 552 may verify one or more digital signatures from an entity authorized to sign a court order. The court order may specify one or more digital assets. The digital asset identifier may specify a specific address, such as a wallet address, that will be frozen or confiscated due to the court order. In some cases, the court order may also or alternatively identify the digital asset by a transaction out point (e.g., UTXO); however, in many cases, the court order may identify the funds by the association of the funds with a wallet address or other public key representation.

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

[0118] The alert management service 552 may store key data 578, including its own (one or more) public keys and securely stored (one or more) private keys. In some cases, the key data 578 may include public key data associated with a registered or certified mining node 556. In some cases, this may include a miner ID (minerID) registered on the chain and associated with a specific miner. In some cases, the key data 578 includes coin creation public key data. In some cases, the key data 578 may include key data of a delegation linked to a miner ID or coin creation public key data. In some cases, the key data 578 may include multiple private keys and may be used to sign alert messages. In some implementations, multiple signatures may be used to sign alert messages. In some implementations, a threshold signature scheme requiring N signatures out of M signatures may be used. The keys involved may vary over time using a defined key rotation scheme.

[0119] Reference now Figure 6, which shows in block diagram form an example of node software 600 for operating a node of a blockchain network, which node is capable of receiving and processing alarm messages from an alarm management service. The node software 600 is shown in conceptual operation boxes or functional boxes, which can be actually implemented as separate modules or applications, or combined or sub-combined with each other in one or more modules or applications. The executable code that implements the node software 600 can be implemented using any programming language that is suitable for the processing hardware and operating system in which it is executed. The node software 600 is generally stored in a memory within a blockchain node and executed by one or more processors or processing units. The blockchain node can be a mining node.

[0120] The node software 600 includes modules or components (not shown) for performing the functions of a blockchain node according to the applicable blockchain protocol (e.g., such as normal transaction confirmation and propagation operations and / or mining operations, etc.). In this example, the node software 600 includes an alarm processor 602 and a plurality of sub-processors that can be called by the alarm processor 602 to handle specific alarms. The sub-processors in this example include an information processor 604, an invalidation / reconsideration processor 606, a freeze / thaw processor 608, a confiscation processor 610, and a prohibition / unbanning processor 612. Although this example and the following description treat the sub-processors as components separate from the alarm processor 602, in some implementations, some or all of the functions of the sub-processors may be implemented within the alarm processor 602.

[0121] The alarm processor 602 is configured to perform initial processing of new alarms. New alarms are typically received by blockchain nodes via the P2P messaging interface 614 in the form of alarm P2P messages. However, in some cases, alarms may be found in newly mined blocks, or in the case of new blockchain nodes or blockchain nodes returning to the network after being disconnected for a period of time, in existing blocks on the chain, which the node receives and confirms during the initial block download (IBD) to build its portrait of the blockchain state. The node software 600 may include a block confirmation component 626, which is configured to obtain block data from peer nodes during the IBD process and can pass alarm transactions to the alarm processor 602.

[0122] As will be discussed further below, the alert message is embedded in the alert transaction. In the case of an alert P2P message, the alert transaction itself can be encapsulated within the format of the alert P2P message; however, in some implementations, the alert transaction can be received over the P2P network as a normal P2P transaction. The alert transaction contains the alert message in the output field. In some cases, the output field can include an alert code or other marker to indicate that the rest of the contents of the output field is an alert message, typically in serialized form. In some cases, the alert message itself can be a JSON-formatted string.

[0123] In some implementations, each alarm message may include a sequence number to enable nodes to determine the order of alarms and, in some cases, to identify duplicate alarm messages. Each alarm message may also include an alarm type, which indicates the type of instructions provided in the alarm message from the alarm management service, and may include a message payload or field that provides the instructions. The contents of the message payload or field may vary depending on the alarm type. For example, an information alarm may allow an unstructured message field that enables any ASCII string content to be included. Freeze / thaw instructions may require that a message field contain a reference to one or more transaction exit points. The alarm message also contains a signature field that contains one or more digital signatures from the alarm management service to enable nodes to verify that the alarm message is legitimate.

[0124] The alarm processor 602 is configured to confirm the alarm message, confirm that the alarm message has not been previously processed by the node, and if not, hand the alarm off to the appropriate sub-processor for processing. Once the node processes the alarm, the alarm processor 602 is configured to add the alarm transaction to its memory pool 620. In this way, if the node mines the next block, the alarm transaction will be included in the block as a digital record of the fact that it has been confirmed and processed by the node. If another node mines the next block and it contains the alarm transaction, the node can confirm the block and remove the alarm transaction from its memory pool 620.

[0125] The alarm processor 602 can propagate the confirmed alarm P2P message to other nodes through the P2P network. In some cases, the alarm processor 602 only causes the alarm P2P message to be propagated after the processing of the alarm instruction has been completed; however, in some other cases, the processing may be asynchronous, and the node software 600 can be configured to propagate the alarm P2P message before the processing has been completed and the alarm transaction has been added to its memory pool 620.

[0126] In some cases, if the alert transaction is not encapsulated in an alert P2P message, the node software 600 may be configured to propagate the alert transaction in the normal transaction propagation process once the alert transaction has been validated.

[0127] The alarm processor 602 maintains an alarm database 622. The alarm database 622 is a record of all received alarm messages. The alarm database 622 can be used to record the alarm content and the processing status of the alarm at the node. In some cases, the alarm database 622 can have a scheme such as the following:

[0128]

[0129]

[0130] An example of a warning message could be an alert instructing a node to freeze a UTXO that is already frozen. An example of an error message could be an alert instructing a node to freeze a UTXO that does not appear to exist.

[0131] In another example, instead of a Boolean flag, a two-bit field may be used to indicate whether the alert was handled, unhandled, or if an error was generated. A single message field may be defined to contain any warning or error messages.

[0132] The information processor 604 may be configured to extract and record any information string provided in the information type alert message. In some cases, the information processor 604 may be configured to perform a notification or messaging function based on the information. In some cases, the information processor 604 may only record the information in a memory at the node.

[0133] The invalidation / reconsideration processor 606 is configured to process instructions to invalidate a block, or, if the block has been previously invalidated, to "reconsider" (e.g., revalidate) the block. In response to an invalidation instruction in an alert message, the invalidation / reconsideration processor 606 may invalidate and / or discard a block on the blockchain maintained at the node. In most use cases, this may be the latest block; however, in some cases, the invalidation instruction may specify an older block, which would cause that block and all subsequent blocks on its chain to be invalid.

[0134] The freeze / thaw processor 608 is configured to process instructions to freeze a transaction out point (e.g., UTXO) or to unfreeze a previously frozen transaction out point. The freeze / thaw processor 608 can maintain a command database 624 that tracks frozen / thawed transaction out points.

[0135] The confiscation processor 610 is configured to process confiscation instructions. The confiscation instructions in the confiscation alert provide a confiscation transaction that moves the digital asset from the specified one or more transaction out points to a different one or more transaction out points. The confiscation instruction can be used to force the transfer of digital assets to effect the seizure, for example, such as to implement a court order. The confiscation processor 610 can be configured to whitelist the confiscation transaction in the command database 624 to indicate that the transaction will be considered a valid transaction. In some cases, the confiscation processor 610 may require that any input to the confiscation transaction is a previously frozen UTXO that has been recorded in the command database 624. The confiscation processor 610 can submit the confiscation transaction to the transaction confirmation process within the node software 600 so that it can be added to the memory pool 620.

[0136] Now refer to Figure 7 , which shows in flowchart form an example method 700 for generating and disseminating an alert message. The example method 700 may be implemented using a network-connected computing device. In some cases, the computing device may be a computer that operates an online service (e.g., the alert management service 552 ( Figure 5 )) of a server or server group. The operations of method 700 may be performed by a computing device based on software instructions executed by a processor in a memory on the computing device. The computing device may be connected to one or more networks, such as the Internet. The computing device may or may not be directly connected to the blockchain network as a node of the blockchain network. In many implementations, the computing device does not operate the blockchain protocol software and does not constitute part of the blockchain network, but is configured to obtain data from one or more blockchain nodes and send and receive data with one or more nodes (e.g., mining nodes) on the blockchain network. The computing device may be configured to communicate with one or more nodes using a P2P communication protocol.

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

[0138]

[0139]

[0140] If there is more than one version, the version field can indicate the version of the alert messaging protocol being adopted. The sequence number field can be used as a unique ID and sequence number for the alert to enable nodes to know in what order to process received alert messages. The block height field can indicate the block height when the alert was generated. The timestamp field contains the time when the alert was generated, for example, in ISO-8601 format. The reference field can store an optional reference to the alert. The alert type field can indicate what type of alert is contained in the alert object field. The alert processor can route the alert for processing based on its alert type (alertType). The alert object field contains the alert details. This can include instructions, and the format and content can vary depending on the alert type. The signature object contains the signature generated and inserted by the alert management service.

[0141] In some cases, alert types may include "information", "invalidate_block", "reconsider_block", "ban_peer", "unban_peer", "freeze_order", "unfreeze_order", and "confiscate". The contents of these various types of alert objects may vary. Information type alerts may contain only a string for the receiving node to record. The invalidate_block alert type and the reconsider_block alert type may have a string that specifies the hash value of the block to be invalidated or reconsidered. The ban_peer or unban_peer alert types may specify an IP address or subnet to be banned or unbanned.

[0142] The freeze_order alert type and unfreeze_order alert type can specify a trade-out point or a list of trade-out points that should be frozen. Its form can be as follows:

[0143]

[0144] The confiscation alert type may contain a string that is a confiscation transaction designed to move assets from one or more trade-out points to one or more other addresses. In some cases, it may contain more than one confiscation transaction. Each confiscation transaction may be inserted as a hexadecimal string encoded transaction. The confiscation handler will decode and whitelist the transaction in the command database and submit the transaction for confirmation and inclusion in the memory pool.

[0145] The alarm processor will generate one or more digital signatures and include them in the alarm message, as indicated by the signature field. In some cases, the signature scheme can be a multi-signature scheme, where N signatures out of M signatures (e.g., 3 signatures out of 5 signatures) are included and valid. In some cases, threshold signatures can be used.

[0146] Each signature should cover the contents of the alert message; however, the creation and verification of the signatures poses a problem because when signing, the signature field is empty, but when verifying, the signature field is filled. Therefore, the application specifies that the valid signature in this example is based on an alert message with an empty signature field. To simplify verification at the node, the alert message is serialized and has no spaces before being signed.

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

[0148] Once the digital signatures are generated, they are inserted into the signature object in the serialized alert message to create a signed serialized alert message in operation 710. The signed serialized alert message is then inserted into the output field of the alert transaction. In a specific example, the signed serialized alert message is inserted into the OP_RETURN field of the alert transaction. In some implementations, the OP_RETURN field may include an alert code indicating that the transaction is an alert transaction in addition to the signed serialized alert message. An example alert transaction with an OP_RETURN output script at index 0 is:

[0149]

[0150]

[0151] In the illustrative example above, the code 0x616C7274 indicates that this is an alert transaction. It is the 4-byte alert prefix, spelled "alrt" in ASCII. Any other code may be used. It is followed by the alert JSON.

[0152] In some examples, alert transactions generated in this manner may be propagated on a blockchain P2P network in the same manner as normal transactions. For example, on a Bitcoin network, alert transactions may be propagated using a tx P2P message that appears to peer nodes like a normal transaction message. However, in this example, the alert management service encapsulates or wraps the alert transaction in an alert P2P message. This may have the advantage that nodes and network elements that do not normally process transactions will not ignore the P2P message. For example, certain nodes may be configured to ignore or be excluded from tx P2P messaging, whereas they may be configured to receive and accept alert P2P messages. Operation 714 includes wrapping the alert transaction in an alert P2P message. In one example, the structure of the alert P2P message may be:

[0153] Field size name Data Types describe variable alert_txn uint8_t[] The original serialized alert transaction

[0154] In operation 716, the alert management service transmits 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.

[0155] Reference now Figure 8 , which shows an example method 800 for processing an alert message in the form of a flowchart. The method 800 can be implemented using a network-connected computing device, in particular a mining node that is part of a blockchain network. In some cases, the mining node can be a server or a server group, such as mining node 556 ( Figure 5 The operations of method 800 may be performed by a mining node based on software instructions executed by a processor stored in a memory on a computing device. In some cases, the operations are performed by node software 600 ( Figure 6 ) and in some cases by the alarm processor 602 ( Figure 6 ) and / or its sub-processors for execution.

[0156] In operation 802, a node receives an alert P2P message. In this example, the alert message is embedded in an alert transaction, which is communicated in the alert P2P message. In another example, the alert transaction may be communicated directly in the transaction P2P message, rather than being wrapped in the alert P2P message. In another case, the alert transaction may be identified in a block being confirmed during block confirmation after another miner finds proof of work or during an IBD process.

[0157] In operation 804, the alarm transaction is extracted and confirmed. In some cases, this can be performed by the P2P messaging interface. The P2P messaging interface can extract the alarm transaction and call the normal transaction confirmation process, such as ProcessTxMessage(), etc., just as it might do for a newly received tx P2P message. Therefore, the node verifies that the alarm transaction meets the protocol requirements and is a valid transaction. This can include determining whether the alarm transaction has appeared in the memory pool at the node. If the alarm transaction is already in the memory pool, it indicates that the node has received the alarm transaction, confirmed it, and processed the alarm message in the alarm transaction. In this case, method 800 can end and the duplicate alarm transaction can be discarded.

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

[0159] Verifying the signature can be based on first extracting the digital signature from the signature field of the signed serialized alarm message. That is, the alarm processor ensures that the modified alarm message includes an empty signature field. The alarm processor then hashes the modified serialized alarm message to obtain a hash result. Based on the hash result and one or more public keys of the alarm management service, the alarm processor can verify the validity of the digital signature. The alarm processor can be configured to determine which keys were used when signing the alarm message, for example based on a timestamp.

[0160] In operation 810, the node determines whether the alarm message is already in the alarm database. This may include searching the alarm database based on the sequence number. If the sequence number is found in the alarm database, then in operation 812, the node may determine whether it is related to the same alarm message. If not, an error has occurred because more than one alarm claims to have the same sequence number, so processing may be aborted and an error logged in operation 814.

[0161] If it is the same alarm as the alarm already recorded in the alarm database, the node has simply received another copy of the alarm. In this case, in operation 816, the node determines whether it has completed processing the previously recorded alarm message. In this case, depending on the result from the subprocessor, the status may indicate PROCESSED or ERROR. If the previously recorded alarm message has not been processed, the status indicates UNPROCESSED. The alarm may be unprocessed because asynchronous alarm processing has not been completed, or because processing was interrupted and failed to complete, or because an error occurred when updating the alarm database. In any case, if processing is not completed, the method continues. However, if processing is completed, processing is terminated in operation 818 because the alarm message has been processed.

[0162] If it is determined in operation 810 that the alarm message is not already in the database, then in operation 811 the alarm message is recorded in the alarm database and assigned an UNPROCESSED status.

[0163] In operation 820, the alarm processor calls the appropriate sub-processor based on the alarm type to process the instructions in the alarm message. Note that if the sub-processor has already attempted to process the alarm message, this may result in the same alarm message being resent to the sub-processor, and the sub-processor will be configured to handle duplicate requests appropriately.

[0164] Processing of the alarm continues until the subprocessor returns a result in operation 822, which may include a message confirming that the alarm has been successfully processed or an error message. If the alarm message has been successfully processed, the alarm processor ensures that the alarm transaction is added to the local memory pool in operation 824. The alarm processor may update the alarm database to change the alarm status to PROCESSED. In some cases, the alarm processor may also record any additional data returned by the alarm subprocessor, such as any warning messages or error messages. In some cases, the alarm processor may notify the P2P interface layer that the alarm transaction or alarm P2P message will be distributed to other peer nodes.

[0165] It will be appreciated that in some implementations, method 800 may be modified to perform one or more operations in parallel, or to change the order in which certain operations are performed, without necessarily affecting the overall operation of method 800. In the above process, the alarm message processing may be performed asynchronously so as not to occupy or block further transaction confirmation. The alarm transaction confirmation may be completed before the subprocessor has processed the alarm message. The alarm transaction does not have to be added to the memory pool when the transaction confirmation process is completed, like a normal transaction, because the alarm transaction is added to the memory pool in part to indicate that the alarm has been successfully processed by the node. Once the status of the alarm message = PROCESSED, the alarm processor may cause the alarm transaction to be added to the memory pool. If the alarm transaction is added to the memory pool, the node may not announce it (INV) to other peer nodes.

[0166] The handling of alerts found in a block during block validation may be a similar but slightly more complex process based on the possibility of more than one alert being present in a block. In some cases, alerts may cancel each other out, for example, in the case where there is an alert message that imposes a freeze command on a TXOUT and then a subsequent alert message that imposes a thaw command on the same TXOUT. Therefore, during block validation, as alert transactions are identified, these alert transactions may be added to a running list of possible new alerts. Alert transactions may undergo transaction validation like normal transactions. Once block validation is completed successfully, the alert processor may process the alerts in the order in which they appear in the block, as if the alerts were received via the P2P interface in that order. Alert transactions, even if validated and processed, are not added to the memory pool because they are already in the block. If the alert processing returns an error from the alert processor, the block may be rejected as invalid because only successfully processed alerts will appear in a valid block. Any alerts found in a block that the node does not already have in its alert database will be treated as new alert messages and processed accordingly.

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

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

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

[0170] In some cases, the alert generation service may be configured or instructed to freeze or unfreeze child out-points in addition to any particular transaction out-point. In this case, an address indexer may be used to track the digital assets passed to the new transaction out-point when the alert message is generated. In one example implementation, this may be performed as follows:

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

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

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

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

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

[0176] Whether an alert message is generated to freeze an address or a specific transaction exit point, the alert management service can begin by identifying the affected transaction exit points. The alert management service can then track any transactions that use these transaction exit points (i.e., child exit points), and the child exit points can then be added to the list of transaction exit points. Note that new addresses to which the child exit points allocate assets will not be added, as this may involve other unrelated assets held by the address.

[0177] In these examples, the responsibility for identifying child transaction exit points may rest with the alert management service. The benefits of this are that mining nodes may therefore run non-indexing or pruned nodes, mining nodes do not require an address indexer or child discovery tracking capability, and the list of exit points in the alert message digitally signed by the alert management service is static and public to all miners, thereby avoiding the risk of inconsistent freezes and chain forks. The disadvantage is that during the time between the generation and distribution of the alert message to miners and its implementation, subsequent movement of assets from the identified exit points may result in evasion of the freeze. If, after the first alert message has been distributed, additional child exit points are to be included in the alert message, the alert management service may generate and send a second or subsequent alert message.

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

Claims

1. A computer-implemented method comprising: Identifying the transaction as an alert transaction at a mining node in the blockchain network; extracting an alert message from an output field of the alert transaction; verifying one or more signatures within the alert message using one or more alert manager public keys; as well as Based on the one or more signatures being verified, processing instructions within the alert message, wherein processing includes one of: invalidating a block, banning a peer node, freezing a transaction exit point, or verifying and propagating a forfeiture transaction.

2. The method according to claim 1, wherein: Identifying the transaction as an alert transaction is based at least in part on identifying an alert code in the output field.

3. The method according to claim 1, wherein: The alarm message includes an alarm type field indicating one of a set of predefined alarm types.

4. The method according to claim 3, wherein: The set of predefined alert types includes at least information alert, ban peer alert, unban peer alert, freeze alert, unfreeze alert, invalidate block alert, reconsider block alert, and forfeit alert.

5. The method according to claim 1, wherein: The alert message is a signed serialized alert message, and wherein verifying the one or more signatures comprises extracting the one or more signatures from the signed serialized alert message, leaving an empty signature field to produce a modified serialized alert message, hashing the modified serialized alert message to obtain a hash result, and verifying the one or more signatures using the hash result and corresponding one or more public keys associated with the alert management service.

6. The method according to claim 1, further comprising: An alert P2P message is received through the blockchain network and the alert transaction is extracted from the alert P2P message.

7. The method according to claim 1, wherein: Freezing the transaction output includes: obtaining a transaction exit point from the instruction in the alarm message, and recording the transaction output as frozen in a command database.

8. The method according to claim 1, wherein: Validating and propagating the confiscated transaction includes extracting the confiscated transaction from within the alert message and whitelisting the confiscated transaction within a command database, and wherein validating and propagating the confiscated transaction includes validating based on the confiscated transaction being included in the whitelist.

9. A computer-implemented method comprising: generating, at an alert management service, an alert message, the alert message including an empty 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 empty signature field to produce a signed serialized alert message; Inserting the signed serialized alert message into an output field of a blockchain transaction; as well as The blockchain transaction is propagated on the blockchain network.

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

11. The method according to claim 9, wherein: The blockchain transaction is an alert transaction, and wherein the output field includes an alert code and the signed serialized alert message.

12. The method according to claim 9, wherein: The alarm message includes an alarm type and an instruction.

13. The method according to claim 12, wherein: The alarm type is one of a set of predefined alarm types, and wherein the set of predefined alarm types includes at least an information alarm, an inhibit peer alarm, an uninhibit peer alarm, a freeze alarm, a thaw alarm, an invalidate block alarm, a reconsider block alarm, and a forfeiture alarm.

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

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

Images