Blockchain-based network addresses

Abstract

A computer-implemented method for generating a network address, comprising: generating a first blockchain transaction, the first blockchain transaction having a first data item based on a public key; and generating a first network address based on one or more second data items associated with the first blockchain transaction.

Description

[Technical Field]

[0001] The present disclosure relates to generating network addresses (e.g., IP addresses such as IPv6) based on information about a blockchain. [Background technology]

[0002] A blockchain is a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence that may span one or more blocks and extend back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and publication of a block may be achieved through publication of only the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes for data within transactions. Because there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this could be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes that are incentivized to act on behalf of the network and report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a valid transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored in the blockchain and constantly updated by multiple nodes separately. Summary of the Invention [Problem to be solved by the invention]

[0009] Network addresses, such as Internet Protocol (IP) addresses, are used to identify and / or locate nodes on a network. One type of network address is the Internet Protocol version 6 (IPv6) address. A key feature of IPv6 is its plug-and-play capability, which allows newly set-up systems to be seamlessly integrated into a network. One technique for achieving this is called a cryptographically generated address (CGA). CGA was introduced as part of the SEcure Neighbor Discovery (SEND) protocol, which allows nodes to join a subnet and generate their own IPv6 address locally. The address is bound to the node's public key using a cryptographic one-way hash function. Ultimately, CGA provides a secure way for a node to prove control of an advertised IPv6 address without relying on a security infrastructure. Its purpose is to prevent spoofing and denial-of-service (DoS) attacks that are inherent in protocols such as the Neighbor Discovery Protocol (NDP).

[0010] Despite these advantages, the practical deployment of CGA is very limited. This is because the complex cryptographic algorithms used during address generation have a significant impact on performance. This issue is particularly problematic in Mobile IPv6 (MIPv6) networks, which typically involve low-end nodes with limited computing power. To maintain the quality of real-time, interactive applications, latency must be kept to a minimum. In practice, this means that operations such as handovers must be completed within a few hundred milliseconds.

[0011] Therefore, there is a need to be able to generate network addresses (eg, IPv6 addresses) quickly, efficiently, and with good security, especially for low-end devices.

[0012] According to one aspect disclosed herein, a computer-implemented method for generating a network address is provided, the method comprising: generating a first blockchain transaction, the first blockchain transaction having a first data item based on a public key; and generating a first network address based on one or more second data items associated with the first blockchain transaction.

[0013] According to one aspect disclosed herein, a computer-implemented method for validating a network address is provided, the method comprising: obtaining a first blockchain transaction having a target public key, a target network address, and a first data item; verifying that the first data item is based on the target public key; obtaining one or more second data items associated with the first blockchain transaction; generating a candidate network address based on the one or more second data items; and verifying that the target network matches the candidate network address.

[0014] Embodiments provide blockchain-based (or "blockchain-authenticated") network addresses that are easy to generate and inherit the security of the blockchain itself. For example, embodiments can be used to generate so-called blockchain-authenticated IPv6 addresses (BCAs). Similar to CGAs, BCAs define a decentralized mechanism for securely binding public keys to IPv6 addresses. The binding is secured by leveraging operations performed by the blockchain. This means that nodes can generate IPv6 addresses without complex cryptographic operations, making BCAs much more practical for lightweight nodes than CGAs. Because blockchain networks consist of a large pool of processing units, the binding of addresses and public keys is highly secure. Spoofing attacks possible in CGAs by a well-equipped attacker are completely out of reach in BCAs. Ultimately, BCAs can provide a more secure and efficient alternative to CGAs.

[0015] Although the embodiments are primarily described with respect to IPv6 addresses as examples, the embodiments may generally be used to generate any type of network address.

[0016] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a diagram illustrating an IPv6 address format. [Figure 4] FIG. 1 is a diagram illustrating the flow of a CGA generation algorithm. [Figure 5]FIG. 1 is a schematic block diagram of a system for generating blockchain-based network addresses. DETAILED DESCRIPTION OF THE INVENTION

[0018] 1. System Overview Example 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be adapted to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0019] Each blockchain node 104 comprises a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0020] A blockchain 150 comprises a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

[0021] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0022] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0023] For a given current transaction 152j, the (or each) input comprises a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily mean the transfer of a financial asset, although this is certainly a common usage. More generally, consumption can be described as consuming an output or allocating it to one or more outputs in another, subsequent transaction. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. The previous transaction 152i does not necessarily exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence connected by pointers, and not necessarily to a time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0024] The input of the current transaction 152j also comprises the input's authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide change). In some cases, the transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0025] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process utilized by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (i.e., "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by 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 tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0026] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "spent") is whether it has not already been validly redeemed by the input of another, earlier transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is no defined order to transactions, an account balance has a single defined state at any given time.

[0027] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. Blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a defined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0028] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0029] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0030] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node constructing the new block's willingness to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction is published. This fee is typically called a "transaction fee" and is discussed below.

[0031] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0032] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0033] Also connected to the network 101 are computer devices 102 of multiple parties 103 each acting as a consuming user. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

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

[0035] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may comprise one or more memory units utilizing 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 of the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 adapted to run on the processing unit. It will be understood that any action attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0036] The client application 105 is initially provided to the computing equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may, for example, be downloaded from a server and provided on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0037] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, the second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0038] Note: 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 instead be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer, at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0039] An instance of client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 for dissemination throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement 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.

[0040] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable per transaction via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0041] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0042] Once admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0043] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0044] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's transaction execution record (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0045] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0046] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0047] Suppose Alice 103a wishes to create transaction 152j that transfers an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0048] By the time Alice creates new transaction Tx1, or at least by the time she submits it to network 106, the currently preceding transaction Tx0 may already have been validated and included in block 151 of blockchain 150. It may already be included in one of the blocks 151 at that time, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “successor” as used herein in the context of a sequence of transactions refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equivalently substituted with “predecessor” and “successor,” or “ancestor” 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. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0049] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the recipient of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0050] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to meet the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0051] So, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlock script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or a combination of these.

[0052] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock script (where the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' is the functionality the lock script contains (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, these scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, a separate element specifying the signed portion of data in plaintext need not be included, as it is essentially already present).

[0053] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

[0054] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of outstanding transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is fraudulent, even if all other conditions are met. Therefore, blockchain node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

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

[0056] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined in the UTXO is "left behind" as unspent, while another part is not. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or pay another party the change in the second output of Tx1.

[0057] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and therefore may not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require a unique, separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that issues the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0058] 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 103's 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 a given party's 103's entire balance. It is the role of the wallet function of the client application 105 to reconcile together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, forward transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0059] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0060] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portions of the outputs that the digital signature signs depend on the SIGHASH flag. The SIGHASH flag is typically a four-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

[0061] A lock script may be referred to as a "scriptPubKey," which refers to the fact that the lock script typically includes the public key of the party to which the respective transaction is locked. An unlock script may be referred to as a "scriptSig," which refers to the fact that the unlock script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0062] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of the first party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0063] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as 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 device 102a and Bob's device 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links may collectively be referred to as the side channel 107. Thus, it should be noted that when Alice and Bob are said to exchange certain information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even the same type of network.

[0064] 4. Cryptographically Generated Address (CGA) An IPv6 address is a 128-bit address, with the leftmost 64 bits forming a subnet prefix and the rightmost 64 bits forming an interface identifier. The subnet prefix is ​​used to determine the node's location in the Internet topology, and the interface identifier is used as the node's identifier.

[0065] A Cryptographically Generated Address (CGA) is an IPv6 address in which the interface identifier is generated by applying a cryptographic hash function to a public key and additional auxiliary parameters. The binding of a public key to an address can be verified by recomputing the hash value and comparing it with the address's interface identifier. CGA allows nodes to generate their own addresses and to verify the addresses of other nodes without relying on a security infrastructure.

[0066] CGA is used in the SEND protocol to prevent spoofing and DoS attacks. A spoofing attack occurs when an attacker in a local network forges Router Advertisement messages and redirects packets destined for a legitimate node to a different link-layer address. In a DoS attack, the attacker disrupts the Duplicate Address Detection (DAD) protocol by responding to all DAD attempts by the initiating node, preventing new, legitimate nodes from obtaining addresses. CGA is designed to mitigate these attacks by providing a way for nodes to prove they control the addresses they advertise.

[0067] Advances in technology quickly made it clear that 64 bits for the interface identifier was insufficient to protect CGA from brute-force attacks. A brute-force attack occurs when an attacker is able to discover another valid public / private key from a given address. To mitigate this attack, CGA added a hash extension technique to new address generation. This technique requires nodes to solve a PoW-like puzzle, the difficulty of which depends on a parameterizable security parameter. This approach increases the cost of both address generation and brute-force attacks by the same factor, while keeping the cost of using and verifying an address constant. The security parameter can be chosen depending on the computational power of the address generator, the perceived risk of attack, and the expected lifetime of the address.

[0068] 4.1 Details 4.1.1 CGA format Each CGA is associated with a set of auxiliary parameters called the CGA parameters data structure, which consists of the following values: modifier: A random 128-bit unsigned integer. This modifier is used to implement hash extension techniques during CGA generation, as well as to enhance privacy by adding randomness to the address. · subnetPrefix: The 64-bit subnet prefix to which the CGA belongs. collisionCount: An 8-bit unsigned integer with the value 0, 1, or 2. The collision count is incremented during CGA generation to recover from address collisions detected by the DAD. · pubKey: The public key as a DER-encoded ASN.1 structure of type SubjectPublicKeyInfo as defined in the Internet X.509 Certificate Profile. extensionFields: optional variable length fields that can be used for additional data items. By default, the length is 0.

[0069] The CGA also has a 3-bit security parameter, sec, encoded in the leftmost 3 bits of the interface identifier, which determines the strength of the CGA against brute-force attacks.

[0070] 4.1.2 CGA generation The CGA generation algorithm takes four values ​​as input: a subnet prefix, the address owner's public key, a security parameter sec, and an optional extension field. The algorithm is shown in Figure 4 and works as follows: 1. Set the modifier to a random 128-bit value. 2. Compute Hash2 by hashing the concatenation of the modifier, 9 zero bytes, the pubKey, and the extensionFields (if any) and taking the leftmost 112 bits of the resulting hash value. 3. Check whether the leftmost 16×sec bits of Hash2 are 0. If so, go to step 4. If not, increment modifier by 1 and go back to step 2. 4. Set the 8-bit collisionCount to 0. 5. Calculate Hash1 by hashing the concatenation of modifier, subnetPrefix, collisionCount, pubKey, and extensionFields (if any) and taking the leftmost 64 bits of the resulting hash value. 6. Construct the interface identifier from Hash1 by encoding the value of sec into the leftmost 3 bits and setting the u and g bits (or bits 6 and 7 if starting from the left with 0) to zero. When using CGA, the u and g bits are ignored; setting them to zero is just an arbitrary convention. 7. Concatenate the 64-bit subnet prefix with the 64-bit interface identifier to form a 128-bit IPv6 address. 8. Perform DAD if necessary. If an address collision is detected, increment collisionCount by 1 and go back to step 5. Stop and report an error after 3 collisions.

[0071] The CGA parameters data structure is formed by concatenating the final modifier value, the subnet prefix, the final collision count value, the encoded public key, and any optional extension fields. The cost of generating a new CGA depends exponentially on the parameter sec, which can have values ​​from 0 (least secure) to 7 (most secure).

[0072] 4.1.3 CGA Validation The CGA verification algorithm takes as input a CGA and a CGA parameter data structure. The CGA verification algorithm works as follows: 1. Check that collisionCount is equal to 0, 1, or 2. 2. Check that the subnetPrefix is ​​equal to the subnet prefix of the CGA. 3. Calculate Hash1 and check that it is equal to the interface identifier of the CGA. Differences between the leftmost 3 bits and the u and g bits are ignored. 4. Calculate Hash2 and check that the leftmost 16×sec bits of the resulting hash value are zero.

[0073] If the verification is successful, the binding between the public key and the address in the CGA parameters data structure is verified. The verification algorithm is relatively fast and always requires at most two hash calculations. If sec=0, step 4 can be skipped and verification requires only one hash calculation.

[0074] 4.1.4 Design Rationale The collisionCount value is used to modify the input to Hash1 if there is an address collision. It is important to verify that the collisionCount is between 0 and 2. First, the probability of three collisions occurring is extremely low, and the reason is undoubtedly either a configuration or implementation error, or a denial of service attack. But more importantly, if an attacker performs a brute-force search to match a given CGA, they can try various values ​​of collisionCount without having to search for new modifiers. Therefore, allowing higher values ​​for collisionCount reduces the effectiveness of the hash extension technique in preventing brute-force attacks.

[0075] Including the subnet prefix as input for Hash1 means that the same public key will generate different interface identifiers in different subnets, so an attacker cannot brute-force all CGAs with the same interface identifier and different subnet prefixes at once.

[0076] The benefit of not including the subnet prefix as an input to Hash2 is that a mobile node that moves between subnets can reuse old qualifier values ​​to generate new addresses. However, reusing qualifier values ​​can make it easier for an observer to link two addresses together. As discussed in Section 4.2, this allows an attacker to construct a time-memory trade-off attack to spoof the address of a random node in the network for any subnet prefix.

[0077] 4.1.5 Spoofing Attacks The purpose of CGA is to prevent the spoofing of existing IPv6 addresses by binding the IPv6 address to the address owner's public key. In CGA, a spoofing attack occurs when an attacker successfully finds a valid set of CGA parameters that binds their public key to a specific address. This allows the attacker to masquerade as another node by presenting a public key that is correctly bound to the target address.

[0078] The property of hash functions used by Hash1 and Hash2 to prevent spoofing attacks is called second-preimage resistance. Second-preimage resistance of a hash function H means that, given a message M, it is difficult to find another message M' such that H(M) = H(M'). If a hash function has this property, the only way an attacker can spoof a CGA is with a brute-force attack.

[0079] The cost of spoofing an address by brute-forcing a CGA can be calculated as follows: Of the 64 bits of Hash1, 5 bits corresponding to the sec bit and the u and g bits are ignored during CGA verification. If sec=0, finding a set of CGA parameters that produces the desired CGA takes O(2 59 ) hash function evaluations are required. The hash extension technique requires that the leftmost 16 × sec bits of the Hash2 value be zero, which increases the address generation cost by approximately 2 16×sec The cost of brute force attacks also increases by the same factor. That is, spoofing an address via brute force attacks takes O(2 (59+16×sec) ) hash function evaluations are required.

[0080] 4.2 Restrictions This section discusses the drawbacks and limitations of CGA.

[0081] 4.2.1 Trade-off between efficiency and security The choice of the security parameter sec affects both the cost to a node of generating a new address and the cost to an attacker of brute-forcing an address. CGAs therefore introduce a trade-off between security and performance. Choosing a large value for sec can introduce unreasonable delays in address generation, while a small value of sec reduces the security of the algorithm. Hash values ​​of 128 bits or more are considered secure for the reasonable future, but a minimum of 80 bits is required for the near future. This suggests using a minimum of sec=2 during CGA generation, which provides 91 bits of security. Generating a new address with sec=2 has been shown to take several minutes on modern CPU processors. Only a value of sec of 0 has been shown to be practical on low-end devices. From these results, we can conclude that secure CGAs cannot be generated on the fly on standard machines.

[0082] For these reasons, it is advisable to delegate the costly part of address generation to more powerful computers. This work can be done in advance or offline, rather than in real time when new addresses are needed. However, this perspective reverts to a centralized model that would fail if the external computer were compromised.

[0083] 4.2.2 Time-Memory Trade-Off Attack To allow mobile nodes to efficiently generate new addresses when they change location, the subnet prefix is ​​not included as an input to Hash2. This weakness can be exploited to construct a time-memory trade-off attack in which the address of a random node in the network is spoofed to any subnet prefix.

[0084] To launch this attack, an attacker must first generate a valid public / private key pair, which only needs to be done once. n In this case, the attacker can set 2 so that the leftmost 16×sec bits of Hash2 are zero. (59-n) Generate a database of modifier values. Creating such a database takes O(2 (59+16×sec-n) ) hash function evaluations. Using this database, an attacker can run the hash function in O(2 (59-n) ) calls to compare the hash values. Because the subnet prefix is ​​not included as an input to Hash2, the database can be reused for any subnet prefix. In the long run, this attack eliminates the effectiveness of the hash extension technique, as the cost of the attack does not depend on the sec parameter once the database is created.

[0085] For example, if an attacker uses sec=1 and 16 If we want to spoof the address of a random node in the network, the database will take O(2 59) hash function evaluations, consuming approximately 128TB of space, which is large but not unrealistic. Then, the attacker can 43 ) hash function evaluations and comparisons are required to find the appropriate modifier value.

[0086] 4.2.3 Replay Attacks The purpose of CGA is to cryptographically bind a public key to an IPv6 address. However, the CGA verification process does not provide a mechanism for a node to actually prove that it controls the public key. This leaves many replay attacks open, as we will see later. These replay attacks can be prevented by adding authentication outside of the CGA, which means an additional round of communication to set up the channel.

[0087] An attacker could generate a CGA from a valid public key belonging to another node, creating another valid address (for example, by changing the qualifier value or subnet prefix). Although the attacker cannot sign new messages, they could mislead other nodes by replaying messages signed by your node and making them believe they control that address.

[0088] This type of replay attack can also target addresses already present in the network. For a given security parameter, sec, an attacker can collect many valid qualifier values ​​and public keys, along with signed messages sent by these nodes. After selecting a subnet prefix, the attacker can use the collected qualifier value and public key to find a match for one of the existing addresses and begin replaying the message.

[0089] Another example of such a replay attack is searching for addresses with a non-zero collisionCount: an attacker can use a node's valid qualifier value and public key to generate an existing address in the network with a collisionCount equal to zero.

[0090] 4.2.4 Privacy Impact In CGA, a node can generate multiple (pseudo)random interface identifiers by running the CGA generation algorithm multiple times, each time using a different (pseudo)random initial modifier value. The (pseudo)random number generator used in the CGA generation algorithm must be strong enough to generate unpredictable and unlinkable values. However, due to the high cost of address generation in CGA, nodes using high sec values ​​may not be able to change their addresses frequently. This runs counter to the recommendations of Narten et al. (2007), "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC4941), which encourages nodes to change their interface identifiers periodically. As noted, using the same identifier for an extended period of time allows an attacker to correlate the activity of a node, even as the node moves topologically through the Internet. Correlation can be performed by an attacker on the path between the node and the peer with which it communicates, or by an attacker with access to the communication logs of the peers with which the node has communicated. Correlation can be based on the payload content of packets on the wire or packet characteristics such as packet size and timing.

[0091] 5. Blockchain-based Network Addresses 5 illustrates an example system 500 for generating network addresses (e.g., IP addresses) based on blockchain-related information. The example system 500 includes a generator 501 configured to generate blockchain-based network addresses, a verifier 502 configured to verify the blockchain-based network addresses, one or more blockchain nodes 104 of a blockchain network 106, and one or more users 503 of the network whose network addresses are used to identify the generator 501. Here, the users 503 of the network (“network users”) may refer to devices 503 connected to the network.

[0092] For simplicity, we will refer to the generator 501 as Alice 103a and the verifier 502 as Bob 103b. The generator 501 and the verifier 502 may be configured to perform some or all of the actions described above as being performed by Alice 103a and / or Bob 103b. Note that this is merely for convenience, and in general, the generator 501 and the verifier 502 (or their respective computing devices) may be configured to perform the actions described herein as being performed by the respective parties.

[0093] Alice 103a is associated with a public key (i.e., she controls the corresponding private key) and wishes to generate a network address for the network she is connected to. For example, Alice 103a wishes to generate an IP address for receiving data over the Internet 101. As a specific example, suppose Alice 103a wishes to generate an IPv6 address.

[0094] Alice 103a generates a first blockchain transaction including a first data item based on her public key. In some examples, the first data item includes the public key. In some examples, the first data item includes a hash of the public key. The first blockchain transaction is sent to the blockchain network 106 by Alice 103a or an intermediary.

[0095] Information about the first blockchain transaction is used to generate a network address associated with Alice's public key. The information about the first blockchain transaction may include information about the block 151 in which the first blockchain transaction is recorded (the "first block"). Thus, once the first blockchain transaction is recorded in the blockchain 150, Alice 103a generates a network address based on one or more second data items. Each second data item is associated with the first blockchain transaction and / or the first block. It is understood that "first" is used here only as a label to represent a particular transaction and block. Alice 103a may obtain a Merkle proof (e.g., from the blockchain node 104) to prove that the first blockchain transaction was recorded in the blockchain 150. Alice 103a may wait a certain amount of time (measured in blocks) before generating the address. For example, Alice 103a may wait until at least six additional blocks have been added to the blockchain 150 after the first block.

[0096] In some examples, the one or more second data items are associated with (e.g., define) the position of the first blockchain transaction in blockchain 150. For example, one of the second data items may be the block height of the first block (i.e., the block number in the blockchain). As another example, one of the second data items may be a transaction index. The transaction index indicates the position of the first blockchain transaction within the first block. That is, the transaction index i of the first transaction is the ith transaction in the first block. The combination of the block height and the transaction index uniquely identifies the position of the first blockchain transaction in blockchain 150.

[0097] In some examples, the one or more second data items are generated by hashing transaction-related data. For example, one of the second data items may be a transaction identifier for a first blockchain transaction generated by hashing the first blockchain transaction. As another example, one of the second data items may be a block header for a first block generated by hashing the first block.

[0098] In some examples, the network address may be generated before Alice 103a submits the first blockchain transaction to the blockchain network 106. This allows Alice 103a to generate the address quickly. For example, Alice 103a may generate the first blockchain transaction and then generate the network address based on information related to the first blockchain transaction, such as its transaction identifier. Recall that the transaction identifier is generated by hashing the transaction.

[0099] In some examples, Alice 103a may generate a first network address before sending a first blockchain transaction to blockchain network 106, and then, once the first blockchain transaction is recorded on blockchain 150, generate a second network address using information related to the location of the first blockchain transaction on blockchain 150, such as the block height of block 151 that contains the first blockchain transaction.

[0100] In some examples, the network address may be based on a qualifier value. Alice 103a may generate multiple qualifier values. Different qualifier values ​​may be used to generate different network addresses. For security reasons, Alice 103a may generate up to two qualifier values. 10 modifier values, i.e., 2 10 Up to three qualifier values ​​may be generated. Alice 103a may generate a third data item that encodes multiple different values. For example, the third data item may be the Merkle root of a Merkle tree generated based on the qualifier values. In general, any technique for encoding a value may be used, such as partial commitment. The third data item may be included in the first blockchain transaction.

[0101] The network address may include a network prefix that may be included in the first blockchain transaction.

[0102] As a specific example, the network address may be an IPv6 address used to identify Alice 103a (or Alice's device) on the Internet 101.

[0103] If the one or more second data items include the block height of the first block and the index of the first blockchain transaction within the first block, an IPv6 address can be generated by encoding the block height as a 23-bit unsigned integer and encoding the transaction index as a 39-bit unsigned integer. An interface identifier is then generated by concatenating the 23-bit unsigned integer and the 39-bit unsigned integer and inserting two additional bits (e.g., zero bits) in the sixth and seventh bit positions. An IPv6 address is then generated by concatenating the network prefix and the interface identifier. Note that the block height and transaction identifier may be encoded using different values ​​for their sizes, as long as their sum is 62.

[0104] In some examples, one of the second data items may include a collision count value.

[0105] In the case where the one or more second data items include a qualifier value, a block header of the first block, a collision count value, and a transaction identifier of the first blockchain transaction, an IPv6 address may be generated by hashing the concatenation of the first qualifier value, the block header, the collision count value, the transaction identifier, and the network prefix. Based on the resulting hash, an interface identifier is generated by extracting the leftmost 64 bits of the hash and inserting two additional bits (e.g., zero bits) in the sixth and seventh bit positions. The IPv6 address is then generated by concatenating the network prefix and the interface identifier.

[0106] In some examples, to improve security, the interface identifier can be based on a security parameter sec. For example, the security parameter can form the first three bits of the interface identifier. Using on-chain techniques, the security parameter can be calculated based on a difficulty value encoded in the block header of the block containing the first blockchain transaction. The difficulty value is determined by the blockchain protocol. The security parameter can be

number

[0107] As another example, when using off-chain technology, the security parameter may be used to determine the portion of the block header on which the interface identifier is based. As a specific example, the block header may be based on the Merkle root of the first blockchain transaction and one or more parameters. The value of the parameter may be iterated until the hash of the block header meets the requirement set by the security parameter. This requirement may be that the leftmost constant bits of the hash, e.g., 16×sec bits, are zero.

[0108] In some examples, the interface identifier may include a bit that indicates whether the first blockchain transaction was recorded in blockchain 150.

[0109] Alice 103a may share (e.g., advertise or transmit) her network address with one or more users of the network. Alice 103a may share her network address with Bob 103b for verification.

[0110] Optionally, Alice 103a may obtain proof that the first blockchain transaction was recorded in the blockchain 150. This proof may be a Merkle proof. The proof may be obtained from a blockchain node 104 or a different entity, or may be generated by Alice 103a. Alice 103a may send the proof to Bob 103b to verify that the first blockchain transaction was recorded in the blockchain 150 as part of validating the network address.

[0111] As another optional feature, in the example where the network address is based on a qualifier value, Alice 103a can obtain (e.g., generate) a proof that a third data item included in the first blockchain transaction includes the qualifier value. In general, any suitable proof may be used, such as a partial commitment. In the case where the third data item is the Merkle root of a Merkle tree generated based on multiple qualifier values, the proof may be a Merkle proof. Alice 103a can send the proof to Bob 103b to verify that the third data item encodes the qualifier value as part of validating the network address.

[0112] To prove that Alice 103a possesses the private key corresponding to the public key, Alice 103a can include a signature generated using the private key as part of the first blockchain transaction. Additionally, or alternatively, Alice 103a can include an output in the first blockchain transaction locked to the public key and submit a second blockchain transaction to the blockchain network 106 that includes an input that unlocks the output of the first blockchain transaction. The input of the second blockchain transaction includes the signature generated using the private key. In these examples, Alice 103a can obtain proof that the second blockchain transaction was recorded in the blockchain 150. This proof may be a Merkle proof. The proof may be obtained from the blockchain node 104 or a different entity, or it may be generated by Alice 103a. Alice 103a can submit this proof to Bob 103b to verify that the second blockchain transaction was recorded in the blockchain 150 as part of validating the network address.

[0113] As described above, Bob 103b is configured to verify that the network address is based on Alice's public key. To do so, Bob 103b obtains the network address and public key. These may be obtained in any suitable manner, for example, by receiving them from Alice 103a. Bob 103b also obtains a first blockchain transaction. The first blockchain transaction may be obtained from the blockchain 150, from Alice 103a, or from another party. Bob 103b verifies that a first data item included in the first blockchain transaction is based on Alice's public key. For example, Bob 103b may hash the public key and verify that it matches the first data item. Bob 103b obtains one or more second data items (e.g., the block height of the block containing the first blockchain transaction and the transaction index of the first transaction within that block) and constructs a candidate network address based on these second data items. If the candidate network address is the same as the obtained network address, the network address verification is successful.

[0114] Bob 103b can also use the proofs described above to verify network addresses. For example, Bob 103b can obtain and use proof that a first blockchain transaction is recorded in the blockchain 150. Bob 103b can also obtain and use proof that a third data item included in the first blockchain transaction contains the correct qualifier value. See sections 6.2.1.3, 6.3.1.3, and 6.4 below for specific examples of Bob 103b using various proofs to verify network addresses.

[0115] Bob 103b may include a predetermined maximum number (e.g., 2 32 103b may verify that the first blockchain transaction contains no more than a predetermined maximum number (e.g., 2 transactions). This can be verified using a proof (e.g., a Merkle proof) that the first blockchain transaction was recorded in the blockchain 150. Bob 103b may use a predefined maximum number (e.g., 2 10 ) It can be verified that the following modifier values ​​are used:

[0116] In the case where the first blockchain transaction has not yet been recorded in the blockchain 150, Bob 103b can verify that the first blockchain transaction is the only transaction included in the block containing the first blockchain transaction, from which the block header used to generate the network address is based. Additionally or alternatively, Bob 103b can verify that the first blockchain transaction commits to only a single qualifier value.

[0117] 6. Blockchain-Authenticated IPv6 Addresses (BCA) As mentioned above, CGA provides a decentralized mechanism for securely binding public keys to IPv6 addresses. This binding is strengthened using hash extension techniques. As stated in Aura, "Cryptographically Generated Addresses (CGA)," RFC3972, March 2005, "The effectiveness of hash extension depends on the assumption that the computational power of the attacker and the address generator grows simultaneously (possibly exponentially). However, this is not necessarily the case when addresses are generated on low-end mobile devices. Furthermore, the development of highly parallelized hardware for PoW-based blockchains further challenges this assumption. Secure use of CGA requires a high sec value, which can make address generation unreasonably expensive on low-end devices.

[0118] Embodiments of the present disclosure can be used to create Blockchain Authenticated IPv6 Addresses (BCA), a more secure and efficient version of CGA that addresses the obvious threats posed by the development of highly parallelized hardware in PoW-based blockchains. BCA completely eliminates the trade-off between binding security and address generation efficiency present in CGA. Furthermore, BCA offers enhanced security and improved efficiency compared to CGA.

[0119] The original CGA specification proposed delegating the expensive work done as part of the hash extension technique to more powerful computers. However, this has the counterproductive effect of jeopardizing the decentralization of the base CGA technique. BCA maintains the decentralization of the base CGA technique by delegating the expensive part of the work to the blockchain network.

[0120] 6.1 BCA - General Description Before generating a new BCA, a node must register its public key in the blockchain, which is done by sending a blockchain transaction tx containing the hash of the public key pubKey. pubKey This is achieved by creating and broadcasting a public key. Including the full public key is also an option, but lacks privacy. Nodes pubKey Each address must wait until it is added to a block, which takes an average of 10 minutes in Bitcoin. Therefore, it is recommended to register public keys in advance rather than registering them in real time when a new address is needed. Nodes can also register multiple public keys at once to avoid overly frequent registrations.

[0121] tx pubKey When a public key is registered on the blockchain, the node pubKey Generate a new BCA using relevant information related to tx. This information depends on the BCA implementation used. Section 6.2 describes tx pubKeyBlock height and transaction volume within the block pubKey Section 6.3 describes the process of using the tx pubKey The block header and tx pubKey We describe the process of generating addresses from identifiers. The security of BCA lies in the fact that the information used to generate addresses is calculated by the blockchain network and is therefore difficult to generate.

[0122] The process of generating and validating BCAs requires nodes to sync and store a chain of block headers. This means being connected to a blockchain P2P network or to a client that can provide the correct chain of block headers, such as Bitcoin SV's block header client. Because the chain of block headers grows very slowly and linearly (about 4MB per year in Bitcoin), this process is very lightweight even for low-end nodes.

[0123] 6.2 BCA - Use of Timestamp Information This BCA implementation leverages the blockchain's ability to timestamp information. In this implementation, a transaction tx that registers a pubKey to the blockchain is called. pubKey The location of the ,is used as the interface identifier for the address. The main difference between this BCA implementation and CGA is: In CGA, addresses are randomly generated by hashing a set of parameters with the pubKey. This randomness is necessary because the domain of the interface identifier is smaller than the public key. An attacker can iterate over the CGA parameters, allowing for the spoofing of addresses. Instead, the tx pubKey The location of the tx can be used to continuously generate new addresses. Therefore, the only way to disguise an address is to rewrite the blockchain history and pubKeyThe trick is to replace tx with a transaction containing the attacker's public key. As time goes by and blocks are added to the blockchain, it becomes increasingly likely that an attacker will pubKey This makes it more difficult to spoof addresses by rewriting tx pubKey It is enough to wait for the inclusion of a single block. In fact, this malicious behavior will be detected by the network and the invalid block will be discarded.

[0124] The process of validating an address requires a node to synchronously store a chain of block headers, which means being connected to a blockchain P2P network or to a client that can provide the correct chain of block headers, such as Bitcoin SV's block header client. Because the chain of block headers grows very slowly and linearly (about 4MB per year in Bitcoin), this process is very lightweight even for low-end nodes.

[0125] 6.2.1 Details This subsection describes the process by which nodes register their public keys, generate new addresses, and verify the addresses of other nodes.

[0126] 6.2.1.1 Public Key Registration When a node registers its public key, pubKey, it must also register the subnet prefix, subnetPrefix, for the addresses it wishes to generate. The public key registration process consists of the following steps: 1. Transaction tx with one OP_RETURN output containing: pubKey Create and broadcast. a hash of the pubKey, Subnet prefix subnetPrefix, · Other data items as required. 2. TX pubKeyis added to the block. Waiting until the next block is added provides additional security. 3. TX pubKey Merkle Proof Π of including Merkle (tx pubKey ), validate it, and store it in memory.

[0127] Once these steps are completed, the pubKey and subnetPrefix are successfully registered on the blockchain. Proof Π Merkle (tx pubKey ) may contain the following information (in addition to the usual Merkle Proof information): tx pubKey : The complete transaction to register the pubKey and subnetPrefix. txIndex pubKey : tx in a block pubKey Index of. blockHeader pubKey : tx pubKey The header of the block containing

[0128] blockHeight pubKey blockHeader pubKey represents the encoded block height.

[0129] 6.2.1.2 Address Generation The address generation algorithm takes as input the blockHeight pubKey , txIndex pubKey ,subnetPrefix. The algorithm works as follows: 1. blockHeight pubKey Encode as a 23-bit unsigned integer. 2. txIndex pubKey Encode as a 39-bit unsigned integer. 3. Construct the interface identifier by concatenating these two values ​​and inserting two 0 bits in the 6th and 7th positions (if starting from 0 on the left). These bits correspond to the u and g bits in an IPv6 address. 4. Concatenate the subnetPrefix and the interface identifier to form a 128-bit IPv6 address.

[0130] 6.2.1.3 Address Verification The address validation algorithm takes as input an IPv6 address, a public key pubKey, and a Merkle proof Π Merkle (tx pubKey ) The algorithm works as follows: 1. Pi Merkle (tx pubKey ) to tx pubKey Extract. 2. Hash the pubKey and the resulting value is tx pubKey It checks that the hashed public key matches the one in 3. TX pubKey Check that the subnetPrefix contained in matches the subnet prefix of the address. 4. Merkle Proof Π Merkle (tx pubKey ) and verify tx pubKey Verify that is included in the blockchain. 5. Pi Merkle (tx pubKey ) to blockHeight pubKey and txIndex pubKey Extract. 6. blockHeight pubKey Encode as a 23-bit unsigned integer. 7. txIndex pubKey Encode as a 39-bit unsigned integer. 8. Construct the interface identifier by concatenating these two values ​​and inserting two 0 bits in the 6th and 7th positions (if starting from 0 on the left). 9. Verify that the reconstructed interface identifier matches the interface identifier in the address.

[0131] If the verification is successful, the binding between the pubKey and the address is verified.

[0132] 6.2.1.4 Analysis In this implementation of BCA, to spoof an address, tx is created with a new transaction that contains the attacker's public key. pubKey It is necessary to rewrite the blockchain history at the position of tx pubKey This attack has been proven economically infeasible if the transaction receives at least six confirmations. In Bitcoin SV, the only way to prevent this attack is to pubKey It is sufficient to wait for the block to be included in the original block. Any fraudulent block that attempts to be added to the blockchain will be detected and discarded by the network.

[0133] In contrast to CGA, interface identifiers are generated sequentially and therefore cannot collide with each other, so there is no need to check for address collisions, and the collision count value in CGA is therefore removed.

[0134] blockHeight pubKey The value of blockHeight is a fixed size, so in the future pubKey However, it still takes 150 years (blockHeight pubKey If the value of is encoded in 23 bits and the Bitcoin block time is 10 minutes, it will take time for the address to expire, at which point all originally generated addresses are expected to have expired. pubKey It is safe to reuse and cycle values ​​of

[0135] txIndex pubKey The fixed domain is also limited in the maximum number of addresses that can be generated per second. However, the 39-bit txIndex pubKeyallows a node to generate 916 million addresses per second, which is more than enough for any reasonable future, so this is not a significant issue.

[0136] Address validation can be performed very efficiently by any lightweight node. The main computational overhead is in verifying the Merkle proof, which only requires performing hash calculations and comparisons that are logarithmic in the number of transactions in the block. The main computational overhead of address generation is also comparable to the cost of verifying the Merkle proof.

[0137] Although the computational requirements for address generation are lower than CGA, the latency remains very high. pubKey Since only one address can be generated from a single Ethereum network, this prevents nodes from changing their addresses too frequently, which creates privacy-related issues. This also means that in case of an address collision, a node must go through the process of generating and broadcasting a new transaction to generate a new address.

[0138] Furthermore, every time a node changes subnet, a new transaction containing the new subnet prefix must be broadcast and included in the blockchain, meaning that nodes changing subnets cannot immediately obtain new addresses, making this technique impractical for some mobile nodes.

[0139] 6.3 BCA - Block Header Usage This BCA implementation follows the original CGA specification more closely. The difference is in how the binding between public keys and addresses is protected. CGA protects the binding by making nodes solve a complex PoW-like puzzle during address generation. Here, the tx calculated by the blockchain network is pubKeyWe protect the binding by reusing the header of the block containing the . Thus, this implementation removes any computationally expensive operations present in CGA. Furthermore, the security of the binding is greatly enhanced because the operations are now performed by a highly distributed network of nodes (rather than on the machines of traditional users of CGA).

[0140] In this BCA implementation, the block header calculated by the blockchain network plays the role of the CGA modifier value m. However, the CGA modifier is used not only to protect the binding but also to enhance privacy by allowing a node to generate multiple random addresses bound to the same public key. To be able to generate multiple random BCAs bound by the same public key, multiple randomly generated modifier values ​​are used as tx. pubKey One way to achieve this is to build a Merkle tree of the generated modifier values ​​and root the Merkle tree at tx pubKey That is, tx pubKey When included in the blockchain, only a fixed number of addresses bound to a public key can be generated. Therefore, nodes must generate and commit a large number of modifier values. Because the Merkle root has a fixed size, the number of modifier values ​​generated is limited to tx pubKey It does not affect the size of

[0141] In contrast to the first BCA implementation, tx pubKey In BCA, subnet prefixes are not registered on the blockchain. The advantage is that a node moving from one subnet to another can reuse an already registered public key to generate a new address. This makes this BCA implementation much more practical for mobile nodes compared to its predecessor. Furthermore, in this implementation, nodes do not need to synchronize the chain of block headers to validate addresses, making the address validation process very lightweight.

[0142] Some implementations of this BCA also introduce an onchain bit, which corresponds to the fourth leftmost bit of the interface identifier. pubKey If generated from tx, this bit is set to 1. pubKey is set to 0 if it is not already included in blockchain 150, and vice versa (see off-chain example below).

[0143] 6.3.1 Details This subsection describes the process by which nodes register their public keys, generate new addresses, and verify the addresses of other nodes.

[0144] 6.3.1.1 Public Key Registration The process for registering a public key pubKey and a qualifier value is as follows: 1. N random 128-bit modifier values ​​(N ≤ 2 10 ) and build the associated Merkle tree. Keep the modifier values ​​and their associated Merkle trees in memory. 2. Transaction tx with one OP_RETURN output containing: pubKey Create and broadcast. Hash of pubKey The Merkle root of the previously computed Merkle tree Other data items, if required. 3. TX pubKey Wait for it to be added to the block. 4. Pi Merkle (tx pubKey ) and get it, tx pubKey Stores a Merkle proof that the token is included in the blockchain.

[0145] Once these steps are complete, the pubKey and N qualifier values ​​are successfully registered on the blockchain. Proof Π Merkle (tx pubKey) may contain the following information (in addition to the usual Merkle Proof information): tx pubKey : The complete transaction that registers the pubKey and modifier values. blockHeader pubKey : tx pubKey The header of the block containing tx pubKey The sec parameter of the address generated from is derived from the difficulty encoded in the block header.

number

[0146] 6.3.1.2 Address Generation The address generation algorithm takes as input the blockHeader pubKey , tx pubKey , modifier(i), and subnetPrefix. Index i is initialized to zero and incremented by one each time a new address is generated. The address generation algorithm works as follows: 1. Set the 8-bit collisionCount value to zero. 2. modifier(i), blockHeader pubKey , subnetPrefix, collisionCount and tx pubKey Hash the concatenation and take the leftmost 64 bits of the resulting hash value. 3. Construct the interface identifier from the resulting hash value by writing the sec value into the leftmost 3 bits, setting the u and g bits (bits 6 and 7 if starting from the left with 0) to 0, and setting the onchain bit (bit 3) to 1. 4. Concatenate the subnetPrefix and the interface identifier to form a 128-bit IPv6 address. 5. Perform DAD if necessary. If an address collision is detected, increment collisionCount by 1 and go back to step 3. Stop and report an error after 3 collisions.

[0147] Finally, modifier(i) is tx pubKey Merkle Proof Π Merkle (modifier(i)). The proof contains the complete modifier value modifier(i) and is stored in memory.

[0148] 6.3.1.3 Address Validation The address validation algorithm is IPv6 address, pubKey, Π Merkle (tx pubKey ), subnetPrefix, collisionCount, and Π Merkle It takes (modifier(i)) as input. The algorithm works as follows: 1. Check that collisionCount is equal to 0, 1, or 2. 2. Check that the subnetPrefix matches the subnet prefix of the address. 3. Pi Merkle (tx pubKey ) the height of the Merkle tree corresponding to it is less than or equal to 32 (there are 2 blocks in the block) 32 If the onchain bit is set to 0, check that the height is 1 (there is one transaction in the block). 4. Pi MerkleThe height of the Merkle tree corresponding to (modifier(i)) is less than or equal to 10 (the transaction committed 2 modifiers 10 If the onchain bit is set to 0, check that the height is 1 (the transaction has only one committed modifier). 5. Pi Merkle (tx pubKey ) to tx pubKey and blockHeader pubKey Extract. 6. Hash the pubKey and the resulting value is tx pubKey Check that the hashed public key matches the 7. Extract the sec value from the leftmost 3 bits of the interface identifier of the address. 8. blockHeader pubKey Check that the leftmost 16×sec bits of the hash (double SHA-256) of are zero. 9. Merkle Proof Π Merkle (tx pubKey ) and verify tx pubKey blockHeader pubKey Verify that it is included in the 10. Pi Merkle Extract modifier(i) from (modifier(i)). 11. Merkle Proof Π Merkle Verify (modifier(i)) and check if modifier(i) is tx pubKey Verify that it is included in the 12. modifier(i), blockHeader pubKey , subnetPrefix, collisionCount, and tx pubKey hash the concatenation of and check that the leftmost 64 bits of the resulting hash value match the interface identifier of the address, ignoring differences in the sec, onchain, u, and g bits.

[0149] If the verification is successful, the binding between the pubKey and the address is verified.

[0150] 6.3.1.4 Analysis In BCA, the maximum number of transactions that can be included in a block is 2. 32 (Assuming an average transaction size of 500 bytes, the maximum block size is 2.15TB.) In fact, the number of transactions in a block is 2 32 The validation process fails if the address exceeds this limit, to prevent an attacker from gaining a significant advantage in brute-forcing the address, as described below.

[0151] Assuming that the hash function used during address generation is second-preimage resistant, address forgery can only be achieved by a brute-force attack. This is the case for the transaction tx that registers the attacker's public key pubKey. pubKey’ This means finding and generating a block that contains 1. The leftmost 16×sec bits of the block header hash (double SHA-256) are zero. 2. The block header, one of the transactions in the block, and one of the modifiers generate an interface identifier for the target address.

[0152] To make the attack as efficient as possible, the attacker builds the maximum number of blocks possible, i.e., 2 32 Transactions, each containing a pubKey and 2 10 The total cost to build this block is approximately 2 34 Note that a block does not need to be published to the blockchain for the attack to be successful.

[0153] The first condition is an average of 2 16×sec+1 The second condition is then satisfied with probability (232 ×2 10 ) / 2 58 =2 -16 Since it is filled with 16 In total, 2 iterations are required before a hit with the target address's interface identifier is found (the second condition is met). 58 different inputs must be tested, which means that the number of hash function evaluations and comparisons required to spoof / impersonate a particular node is reduced to 2 58 +2 16×sec+17 This suggests that...

[0154] As of January 2023, the difficulty in the three major implementations of Bitcoin (BTC, BCH, and BSV) is such that sec equals 4, resulting in 81 bits of security. This is 6 bits more than what is achieved with CGA at sec=1. As the hardware speed of machines, especially Bitcoin miners, improves, the sec value is expected to improve as well.

[0155] Another advantage of BCA over CGA is that a node that wants to update its address does not need to perform costly work: in CGA, updating an address means restarting the search for valid qualifier values. pubKey Because multiple qualifier values ​​are committed in BCA, a node using BCA can update its address by simply selecting a different qualifier value to use in the address generation process.

[0156] Nodes must ensure that they generate enough modifier values ​​to avoid running out of values. For example, if 80% of the modifier values ​​are consumed, the node must generate a new transaction tx containing the pubKey. pubKey’ and may decide to broadcast the commit to a different set of qualifier values.

[0157] A node must keep the N modifier values ​​in memory, and also keep the corresponding Merkle tree to avoid recomputing them every time a new address is generated. 10 Assuming that 128-bit modifier values ​​are generated and the hash digest size is 256 bits, this requires approximately 81kB of extra storage.

[0158] The cost of verifying an address is equivalent to verifying two very lightweight Merkle proofs. Merkle (tx pubKey ) requires a logarithmic number of hash calculations and comparisons depending on the number of transactions in the block, up to a maximum of 13. Merkle Validating (modifier(i)) requires a logarithmic number of hash calculations and comparisons depending on the number of modifiers, up to a maximum of 11.

[0159] The first time a node generates an address, the latency of address generation is relatively high due to the public key registration process, which takes tx pubKey This is because, once registration is complete, it is necessary to wait for the address to be included in a block. However, once registration is complete, generating an address in any subnet is fast, requiring a single hash calculation. A node that wants to change its public key must anticipate that a new transaction will need to be broadcast and included in a block before it can generate a new address that will be bound to the node. However, this does not pose a practical problem, as nodes can still use addresses bound to previously registered public keys for some time.

[0160] 6.3.3 Generalization to non-PoW blockchains The validation process checks whether the node is a blockHeader pubKeyThe previous implementation is only applicable to PoW blockchains, as we need to verify that the hash of is less than 16 × sec (see step 8 of the address validation process). However, this implementation can be generalized to non-PoW blockchains (such as Proof-of-Stake (PoS) blockchains) in the following way: To validate an address, a node must first synchronize the chain of block headers. In step 7, the node instead checks that the block header exists in the synchronized chain. The public key registration and address generation process remain the same (except that the sec bit is not used).

[0161] 6.4 Off-chain fast address generation One limitation of previous implementations is the high latency of the public key registration process, which prevents newly set up nodes from quickly generating new addresses, which goes against the plug-and-play feature of IPv6. Furthermore, nodes may not be already connected to the blockchain network when generating a BCA.

[0162] To address this limitation, you can use tx to generate new addresses. pubKey Instead of waiting for the transaction to be included in the blockchain, the node pubKey You may immediately generate a new address using the transaction identifier for transaction tx. pubKey contains a hash of the pubKey and a hash of a randomly generated modifier value. The address generation algorithm takes as input tx pubKey , subnetPrefix, and the security parameter sec. The algorithm works as follows: 1. TX pubKey Create a block containing the block header. pubKey Set all parameters (except the Merkle root) of to zero. 2. Iterate over the block header parameters until the leftmost 16×sec bits of the block header hash are zero. 3. Set the 8-bit collisionCount value to 0. 4. modifier, subnetPrefix, collisionCount, and tx pubKey Hash the concatenation and take the leftmost 64 bits of the resulting hash value. 5. Construct the interface identifier from the resulting hash value by writing the sec value into the leftmost 3 bits, setting the u and g bits (bits 6 and 7 if starting from the left with 0) to 0, and setting the onchain bit (bit 3) to zero. 6. Concatenate the subnetPrefix and the interface identifier to form a 128-bit IPv6 address. 7. Perform DAD if necessary. If an address collision is detected, increment collisionCount by 1 and go back to step 3. Stop and report an error after 3 collisions.

[0163] The height of the modifier Merkle tree and the transaction Merkle tree are both 1. The validation procedure of off-chain BCA is the same as that of BCA, so both technologies are naturally compatible.

[0164] In off-chain BCA, the host performs the search for valid block headers itself, rather than delegating it to a blockchain node 104. This allows the host to quickly obtain a new address even if it has not registered its public key on the blockchain. As with CGA, the difficulty of the operation is selected according to the host's computational power. The higher the difficulty, the more secure the binding will be, but the more resources are required for address generation. Once a connection to the blockchain is found, the host must register its public key and efficiently generate a secure address using standard BCA techniques. Off-chain quick address generation techniques can be integrated with (on-chain) BCA, allowing nodes to quickly and efficiently generate secure IPv6 addresses. The process is as follows: 1. Transaction tx registers the pubKey and a randomly generated modifier value. pubKey Create a. 2. Generate an IPv6 address using quick address generation techniques. 3. Every time a connection is established with the blockchain network, a new transaction tx is created that registers the pubKey and N qualifier values. pubKey’ and broadcast it to the blockchain network. 4. TX pubKey If included in the block, (on-chain) BCA technology is used to generate IPv6 addresses with stronger security.

[0165] 6.5 BCA - Extensions 6.5.1 Public Key Revocation In the BCA extension, tx pubKey This involves adding another P2PKH output to , and using the state of this output (spent vs. unspent) as an indicator of the validity of the pubKey. An address becomes valid after tx pubKey If a P2PKH output in the pubKey is unspent, the node can consume the output, preventing the attacker from using the associated address. Note that making an output containing a pubKey consumable and consuming it to revoke the pubKey is optional.

[0166] 6.5.2 Authentication BCA provides the flexibility to include any additional data that is immutably stored on the blockchain, for example, a signature made with the private key corresponding to the pubKey. pubKey By including it in the address validation process, direct authentication can be added to the address validation process. In this case, the BCA not only ensures the binding of the public key to the address, but also ensures that the node actually controls the public key.

[0167] Optionally, the node can pubKey tx in OP_RETURN datapubKey To verify that a node controls the pubKey, the address verification algorithm uses the signature of the tx pubKey The user must include an additional step to verify the signature contained in

[0168] Another option is to leverage the signature verification process performed by the blockchain network as part of the transaction verification process. pubKey This can be done by locking to the pubKey using the P2PKH script in the tx during public key registration. pubKey In addition to broadcasting , the node must also broadcast tx to prove control of the pubKey. pubKey Another transaction, txUnlock, unlocks the pubKey During the address validation step, the node must broadcast txUnlock to prove that the transaction is included in the blockchain and therefore controls the pubKey. pubKey This approach means broadcasting two transactions instead of one during public key registration, but adds an additional trust check in BCA without expensive signature verification during address validation.

[0169] One limitation of this method is that the signature scheme is fixed by the blockchain protocol (ECDSA using the Secp256k1 curve in Bitcoin). To make the above method applicable to additional curves and signature schemes, the P2PKH script can be replaced with a P2APK (pay-to-any-public-key) script, as described in UK Patent Application No. GB2206040.4. The public key registration, address generation, and address validation processes are carried out in the same way as before.

[0170] 6.5.3 Alternate Address Update In Section 6.2, we introduce a new transaction, tx pubKey’Broadcast and tx pubKey’ The address can be updated by recording the location of the address in the blockchain. In Section 6.3, we will consider different modifiers in the list of generated modifiers. j Another option is to make the output containing the pubKey available for consumption and create a new transaction, tx pubKey’ You can also re-register and consume the pubKey with tx pubKey’ New blockchain information related to tx in the first implementation pubKey’ The second implementation uses the associated block header to update the location of the block. The advantage is that there is a chain of spent transactions, and therefore a provable link between IPv6 addresses generated from the same public key pubKey.

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

[0172] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of a blockchain 150, and the above description may apply generally to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The 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 nodes 104, as described above.

[0173] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating, and storing blocks 151 in 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, a network entity may perform the functions of disseminating and / or storing blocks without creating and publishing them (as noted above, these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

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

[0176] Some embodiments are described for blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a specific example, proof-of-stake uses a randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes can lock tokens for a certain period of time to earn the chance to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0177] It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0178] Statement 1. A computer-implemented method for generating a network address, comprising: generating a first blockchain transaction, the first blockchain transaction having a first data item based on the public key; generating a first network address based on one or more second data items associated with the first blockchain transaction; A method comprising:

[0179] The public key is associated with the first party. The method may be performed by the first party or a different party.

[0180] The first data item may comprise a public key and / or may be generated as a function of the public key.

[0181] Statement 2. The method of statement 1, wherein the first data item includes at least a hash of the public key.

[0182] Statement 3. The method of statement 1 or statement 2, wherein the one or more second data items include a transaction identifier of the first blockchain transaction.

[0183] Statement 4. The method of statement 3, wherein the first network address is generated before the first blockchain transaction is recorded on the blockchain.

[0184] Statement 5. The method of any of statements 1 to 3, comprising causing a first blockchain transaction to be submitted to a blockchain network for recording on the blockchain.

[0185] Statement 6. The method of statement 5, wherein one or more of the second data items relate to a location of the first blockchain transaction on the blockchain.

[0186] Statement 7. The method of statement 6, wherein the one or more second data items include a block height and a transaction index of the first block, the transaction index indicating a position of the first blockchain transaction in the first block.

[0187] Statement 8. The method of any of statements 5 to 7, wherein the one or more second data items include a block header of the first block and a transaction identifier of the first blockchain transaction.

[0188] Statement 9. The method of any of statements 1 to 8, wherein the first network address is further based on a first qualifier value.

[0189] Statement 10. Generating a plurality of qualifier values, the plurality of qualifier values ​​including a first qualifier value; generating a third data item encoding a plurality of qualifier values, wherein the first blockchain transaction includes the third data item; The method of statement 9, comprising:

[0190] Statement 11. The method of statement 10, wherein the sum of the qualifier values ​​is less than or equal to a predetermined maximum value. 10 It may be.

[0191] Statement 12. The method of any of statements 1 to 11, wherein the first network address includes a network prefix.

[0192] Statement 13. The method of statement 12, wherein the first blockchain transaction includes a network prefix.

[0193] Statement 14. The method of any of statements 1 to 13, wherein the network address is an Internet Protocol version 6 (IPv6) address.

[0194] Statement 15. The step of generating a first network address comprises: generating a hash of a concatenation of the first qualifier value, the block header, the transaction identifier, the network prefix, and the collision count value; constructing an interface identifier by extracting the left 64 bits of the hash and inserting two additional bits in the sixth and seventh bit positions; concatenating a network prefix and an interface identifier; The method described in statement 14, when related to statements 3 and 12, including:

[0195] Statement 16. The step of generating a first network address comprises: constructing a block including the first transaction and a block header for the block, the block header having a plurality of parameters, the plurality of parameters including a Merkle root generated based on the first transaction; setting each of the parameters in the block header to zero, except for the Merkle root; iterating the block header parameters until the leftmost 16*sec bits of the hash of the block header are zero, where sec is a security parameter; generating a hash of a concatenation of the first qualifier value, the block header, the transaction identifier, the network prefix, and the collision count value; constructing an interface identifier by extracting the left 64 bits of the hash, replacing the leftmost 3 bits of the hash with a security parameter, and inserting two additional bits into the 6th and 7th bit positions; concatenating a network prefix and an interface identifier; The method described in statement 14, when related to statements 3 and 12, including:

[0196] Statement 17. The step of generating a first network address comprises: encoding the block height as an n-bit unsigned integer; encoding the transaction index as an m-bit unsigned integer; constructing an interface identifier by concatenating an n-bit unsigned integer and an m-bit unsigned integer and inserting two additional bits in the sixth and seventh bit positions; concatenating a network prefix and an interface identifier; The method described in statement 14, when related to statements 7 and 12, including:

[0197] Statement 18. The method of any of statements 15 to 17, wherein two additional bits are set to 0.

[0198] Statement 19. The method of statement 18, wherein constructing the interface identifier includes replacing the leftmost 3 bits of the hash with a security parameter, the security parameter being based on a difficulty encoded in the block header.

[0199] Statement 20. The security value sec is

number

[0200] Statement 21. The method of any of statements 15 to 20, wherein the interface identifier includes a bit indicating whether the first network address is generated based on a transaction included in the blockchain.

[0201] Statement 22. The method of any of statements 1 to 21, comprising waiting until at least a predetermined number of subsequent blocks have been added to the blockchain after the first block before generating the first network address.

[0202] Statement 23. The method of any of statements 1 to 22, comprising making the first network address available to one or more parties.

[0203] Statement 24. Obtaining a first proof that a first blockchain transaction has been recorded on a blockchain; sending the first proof to a verifier to verify the first network address; 24. The method of any of statements 1 to 23, comprising:

[0204] Statement 25. Obtaining a second proof that the third data item encodes the first qualifier value; sending the second proof to a verifier to verify the first network address; The method according to statement 24 when related to statement 10, comprising:

[0205] Statement 26. The method of any of statements 1 to 25, wherein the first blockchain transaction includes a signature generated using a private key corresponding to the public key.

[0206] Statement 27. A method comprising: causing the second blockchain transaction to be submitted to a blockchain network; 27. The method of any of statements 1 to 26, wherein the second blockchain transaction includes an input that references the output of the first blockchain transaction and includes a signature generated using a private key that corresponds to the public key and configured to unlock the output.

[0207] Statement 28. Obtaining a third proof that the second blockchain transaction is recorded on the blockchain; sending the third proof to a verifier to verify the first network address; 28. The method of claim 27, comprising:

[0208] Statement 29. The method of statements 1 to 28 when related to statements 4 and 5, comprising generating a second network address based on one or more second data items associated with the first blockchain transaction after the first blockchain transaction is recorded in a first block of the blockchain, wherein at least one of the one or more second data items is associated with the location of the first blockchain transaction on the blockchain.

[0209] Statement 30. A computer-implemented method for validating a network address, comprising: Obtaining a first blockchain transaction having a target public key, a target network address, and a first data item; verifying that the first data item is based on the target public key; obtaining one or more second data items associated with the first blockchain transaction; generating candidate network addresses based on one or more second data items; verifying that the target network matches the candidate network address; A method comprising:

[0210] Statement 31. Obtaining a first proof that a first blockchain transaction has been recorded on a blockchain; using the first proof to verify that the first blockchain transaction is recorded on the blockchain; The method of statement 30, comprising:

[0211] Statement 32. Obtaining a candidate first qualifier value; generating a candidate network address based on the candidate first qualifier value; The method according to statement 30 or 31, comprising:

[0212] Statement 33. The first blockchain transaction includes a third data item encoding a plurality of qualifier values, and the method further comprises: obtaining a second proof that the third data item encodes the first qualifier value; verifying, using the second proof, that the third data item encodes the first qualifier value; The method of statement 32, comprising:

[0213] Statement 34. Verifying that the first blockchain transaction includes a signature corresponding to the public key. 34. The method of any of statements 30 to 33, comprising:

[0214] Statement 35. A method according to claim 1, wherein the first blockchain transaction includes an output locked to a public key, obtaining a second blockchain transaction having an input that references an output of the first blockchain transaction and having a signature configured to unlock the output; obtaining third proof that the second blockchain transaction was recorded on the blockchain; verifying that the second blockchain transaction is recorded on the blockchain using the third proof; 35. The method of any of statements 31 to 34, comprising:

[0215] Statement 36. Using the first proof, the block containing the first blockchain transaction is 32 A method according to statement 31 or any statement related to statement 31, comprising verifying that there are fewer than 10 transactions.

[0216] Statement 37. Using the second proof, we can see that multiple modifier values ​​are 2 10 33. A method according to claim 33 or any statement related to statement 33, comprising verifying that the statement contains fewer than three qualifier values.

[0217] Statement 38. The method of statement 31, wherein the first blockchain transaction is not recorded on the blockchain.

[0218] Statement 39. Obtaining a block having a first blockchain transaction; and verifying that the block has only a single blockchain transaction.

[0219] Statement 40. The method of statement 38 or statement 39, comprising verifying that the first blockchain transaction has a commitment to only a single qualifier value.

[0220] Statement 41. The target network address has a security value that includes a sec bit, and the method comprises: A method according to statement 38 or any statement related to statement 38, comprising verifying that the leftmost 16×sec bits of a hash of a block header of a block having a first blockchain transaction are zero.

[0221] Statement 42. A memory including one or more memory units; a processing unit including one or more processing units, 42. A computing device, the memory storing code configured to execute on a processing unit, the code configured, when executed on the processing unit, to perform the method of any of statements 1 to 41.

[0222] Statement 43. A computer program embodied on a computer-readable storage, the computer program being configured to perform the method of any of statements 1 to 41 when executed on one or more processors. [Explanation of symbols]

[0223] 101 Internet, packet-switched networks 102 Computer terminals and equipment 103 users 104 blockchain nodes 105 Client Applications 106 P2P networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output

Claims

1. 1. A computer-implemented method for generating a network address, comprising: generating a first blockchain transaction, the first blockchain transaction having a first data item based on a public key; generating a first network address based on one or more second data items associated with the first blockchain transaction; A method comprising:

2. The method of claim 1 , wherein the first data item includes at least a hash of the public key.

3. 3. The method of claim 1 or claim 2, wherein the one or more second data items include a transaction identifier for the first blockchain transaction.

4. 4. The method of claim 3, wherein the first network address is generated before the first blockchain transaction is recorded on a blockchain.

5. 4. The method of claim 1, further comprising the step of causing the first blockchain transaction to be submitted to a blockchain network for recording on the blockchain.

6. 6. The method of claim 5, wherein one or more of the second data items relate to a location of the first blockchain transaction on the blockchain.

7. 7. The method of claim 6, wherein the one or more second data items include a block height of a first block and a transaction index, the transaction index indicating a position of the first blockchain transaction in the first block.

8. 8. The method of claim 5, wherein the one or more second data items include a block header of a first block and a transaction identifier of the first blockchain transaction.

9. 9. The method of claim 1, wherein the first network address is further based on a first qualifier value.

10. generating a plurality of modifier values, the plurality of modifier values ​​including the first modifier value; generating a third data item encoding the plurality of qualifier values, wherein the first blockchain transaction includes the third data item; The method of claim 9, comprising:

11. 11. The method of claim 10, wherein the sum of the modifier values ​​is less than or equal to a predetermined maximum value. 10 It may be.

12. 12. The method of claim 1, wherein the first network address includes a network prefix.

13. 13. The method of claim 12, wherein the first blockchain transaction includes a network prefix.

14. 14. The method of claim 1, wherein the network address is an Internet Protocol version 6 (IPv6) address.

15. generating the first network address, generating a hash of the concatenation of the first qualifier value, the block header, the transaction identifier, the network prefix, and a collision count value; constructing an interface identifier by extracting the left 64 bits of said hash and inserting two additional bits in the sixth and seventh bit positions; concatenating the network prefix and the interface identifier; The method of claim 14 when dependent on claims 3 and 12, comprising:

16. generating the first network address, constructing a block containing the first transaction and a block header for the block, the block header having a plurality of parameters, the plurality of parameters including a Merkle root generated based on the first transaction; setting each of the block header parameters to zero, except for the Merkle root; repeating the parameters of the block header until the leftmost 16*sec bits of the hash of the block header are zero, where sec is a security parameter; generating a hash of the concatenation of the first qualifier value, the block header, the transaction identifier, the network prefix, and a collision count value; constructing an interface identifier by extracting the left 64 bits of said hash, replacing the leftmost 3 bits of the hash with a security parameter, and inserting two additional bits into the 6th and 7th bit positions; concatenating the network prefix and the interface identifier; The method of claim 14 when dependent on claims 3 and 12, comprising:

17. generating the first network address, encoding the block height as an n-bit unsigned integer; encoding the transaction index as an m-bit unsigned integer; constructing an interface identifier by concatenating the n-bit unsigned integer and the m-bit unsigned integer and inserting two additional bits in the sixth and seventh bit positions; concatenating the network prefix and the interface identifier; The method of claim 14 when dependent on claims 7 and 12, comprising:

18. 18. The method of claim 15, wherein the two additional bits are set to 0.

19. 20. The method of claim 18, wherein constructing the interface identifier comprises replacing the leftmost three bits of the hash with a security parameter, the security parameter being based on a difficulty level encoded in the block header.

20. The security value sec is [Equation 1] 20. The method of claim 19, wherein the calculated

21. 21. The method of claim 15, wherein the interface identifier includes a bit indicating whether the first network address is generated based on a transaction included in the blockchain.

22. 22. The method of claim 1, comprising waiting until at least a predetermined number of subsequent blocks have been added to the blockchain after the first block before generating the first network address.

23. 23. A method according to any preceding claim, comprising making the first network address available to one or more parties.

24. obtaining a first proof that the first blockchain transaction is recorded on the blockchain; sending the first proof to a verifier to verify the first network address; 24. The method of any one of claims 1 to 23, comprising:

25. obtaining a second proof that the third data item encodes the first qualifier value; sending the second proof to a verifier to verify the first network address; The method of claim 24 when dependent on claim 10, comprising:

26. 26. The method of any one of claims 1 to 25, wherein the first blockchain transaction includes a signature generated using a private key corresponding to the public key.

27. the first blockchain transaction includes an output locked to the public key, and the method comprises: causing a second blockchain transaction to be submitted to the blockchain network; 27. The method of any one of claims 1 to 26, wherein the second blockchain transaction includes an input that references an output of the first blockchain transaction and includes a signature generated using a private key that corresponds to the public key and configured to unlock the output.

28. obtaining a third proof that the second blockchain transaction is recorded on the blockchain; sending the third proof to a verifier to verify the first network address; 28. The method of claim 27, comprising:

29. 29. The method of claims 1 to 28 when dependent on claims 4 and 5, comprising generating a second network address based on one or more second data items associated with the first blockchain transaction after the first blockchain transaction is recorded in the first block of the blockchain, at least one of the one or more second data items being associated with a location of the first blockchain transaction on the blockchain.

30. 1. A computer-implemented method for validating a network address, comprising: Obtaining a first blockchain transaction having a target public key, a target network address, and a first data item; verifying that the first data item is based on the target public key; obtaining one or more second data items associated with the first blockchain transaction; generating candidate network addresses based on the one or more second data items; verifying that the target network matches the candidate network address; A method comprising:

31. obtaining a first proof that the first blockchain transaction is recorded on a blockchain; using the first proof to verify that the first blockchain transaction is recorded on the blockchain; 31. The method of claim 30, comprising:

32. obtaining a candidate first qualifier value; generating the candidate network address based on a first qualifier value of the candidate; 32. The method of claim 30 or claim 31, comprising:

33. the first blockchain transaction includes a third data item encoding a plurality of qualifier values, and the method further comprises: obtaining a second proof that the third data item encodes the first qualifier value; using the second proof to verify that the third data item encodes the first qualifier value; 33. The method of claim 32, comprising:

34. Verifying that the first blockchain transaction includes a signature corresponding to the public key.

34. The method of any one of claims 30 to 33, comprising:

35. the first blockchain transaction includes an output locked to a public key, and the method comprises: obtaining a second blockchain transaction having an input that references an output of the first blockchain transaction and having a signature configured to unlock the output; obtaining a third proof that the second blockchain transaction is recorded on the blockchain; using the third proof to verify that the second blockchain transaction is recorded on the blockchain; 35. The method of any one of claims 31 to 34, comprising:

36. Using the first proof, a block containing the first blockchain transaction is added to the block. 32 32. A method according to claim 31 or any claim dependent thereon, comprising verifying that there are fewer than 10 transactions.

37. Using the second proof, the plurality of qualifier values ​​are 10 34. A method according to claim 33 or any claim dependent thereon, comprising verifying that the number of qualifier values ​​in the list contains fewer than three qualifier values.

38. 32. The method of claim 31 , wherein the first blockchain transaction is not recorded in the blockchain.

39. obtaining a block having the first blockchain transaction; and verifying that the block has only a single blockchain transaction.

40. 40. The method of claim 38 or claim 39, comprising verifying that the first blockchain transaction has a commitment to only a single qualifier value.

41. the target network address has a security value including a sec bit, and the method comprises:

39. A method according to claim 38 or any claim dependent thereon, comprising verifying that the leftmost 16×sec bits of a hash of a block header of a block having the first blockchain transaction are zero.

42. a memory including one or more memory units; a processing unit including one or more processing units, 42. A computing device, wherein the memory stores code configured to execute on a processing unit, the code being configured, when executed on the processing unit, to perform the method of any one of claims 1 to 41.

43. 42. A computer program embodied on a computer readable storage, the computer program being configured to perform the method of any one of claims 1 to 41 when executed on one or more processors.

Images